Remote Access VPN vs ZTNA: The Transition Playbook

By Taylor Thomas · 2026-08-31

Ask what a successful login buys the user and the two models separate — cleanly in their typical designs, less cleanly at the edges. A client-based remote access VPN authenticates a user and extends the network to their device: the client typically gets a tunnel address and a routable path to whatever destinations the tunnel policy exposes. ZTNA — zero trust network access — authenticates a user and connects them to explicitly authorized resources: the service evaluates identity and device posture through its policy decision function, an enforcement point applies the result, and resources without a grant stay unreachable through it. Both encrypt their access channel in transit — though on the ZTNA side, the connector-to-application leg inside the data center is only as encrypted as the application protocol itself. What differs is the shape of the grant, and nearly every operational difference follows from that shape.

What the VPN Model Gets Right and Wrong

The VPN’s network-shaped grant is also its virtue: it is largely protocol-agnostic. Most things that route over IP work through the tunnel — legacy thick clients, server-initiated callbacks, odd ports — with no per-application onboarding, subject to the usual caveats of MTU, NAT, and protocols that embed addresses. The cost is exposure. A compromised endpoint or stolen credential inherits the tunnel’s reachability, and in a broadly routed deployment — broad routes, permissive authorization, the “flat VPN” — a wide slice of the internal network becomes an attacker’s starting position. Traffic selectors, filters, and per-group policy can scope the grant tightly, and IPsec’s architecture treats policy as integral; the failure mode is operational, not architectural — narrowing erodes as exceptions accumulate, because every exception is easier to grant than to revoke. Split tunneling adds a routing question on top: sending only corporate destinations through the tunnel spares bandwidth, but traffic routed around the tunnel also bypasses whatever inspection the tunnel path provided. Transport choices within the VPN model — IPsec versus SSL — change how the tunnel is built, not what the login buys.

What ZTNA Changes

ZTNA inverts the default. Applications are published through the broker — commonly via connectors that dial outbound to it, removing the internet-exposed inbound listener, though the application’s own listener still exists and internal paths to it must be closed separately. Each user-to-application connection is granted individually, against identity and device posture, at connection time: resources without an explicit authorization are denied. That inversion is what shrinks the value of a stolen credential relative to a broadly routed VPN: the attacker gets brokered sessions to the resources that user could reach — assuming device and risk checks pass at all — not a routable network position to explore. The narrowing is real but should be stated precisely — lateral movement risk is reduced, not eliminated; a resource scoped as a broad subnet rebuilds the network-shaped grant under a new name; and the applications themselves remain targets through the front door. Posture is the other gain, one of emphasis: because an enforcement point mediates each access, ZTNA makes device trust a condition that can be re-evaluated during the session as a matter of course — how continuously depends on product and policy, and VPN platforms with posture integration can reassess too, though it arrives there as an add-on rather than the design center. Both trace to the broader zero trust model.

The Transition Playbook

Transitions fail when they start with technology selection instead of application inventory. A sequence that holds up: first, enumerate what remote users actually reach — the discovery pass almost always surfaces applications nobody documented. Second, migrate the low-friction tier: browser-based and standard client-to-server applications, where brokered access usually needs the least rework — validating DNS behavior, identity integration, and any source-IP assumptions as you go. Third, confront the remainder honestly. Server-initiated connections to endpoints, some VoIP flows, and legacy protocols that assume a network path are the common holdouts, though what falls in that bucket is product- and application-specific; client-based ZTNA extends coverage well past the clientless browser cases, but the last increment often is not worth forcing. The practical pattern is running both models side by side, shrinking the VPN’s user population and route scope release by release, until what remains on it is a named list of exceptions with owners — a deliberate end state, not a stalled project.

Measure the transition in exposure as well as headcount. Moving users off the VPN shrinks the population that can establish the broad grant — real risk reduction. But the numbers that complete the picture are the address space a remaining VPN login can still reach, the count of applications reachable only through the broker, and the tunnel-policy exceptions carried forward without an owner: per-session blast radius only falls when the route scope does.

Where the Exams Draw the Line

Cisco’s blueprints mirror the coexistence. SCOR 350-701 v2.0 objective 1.6 covers site-to-site and remote access VPN deployment types, with 2.9 and 2.10 on configuring and troubleshooting VPN on Cisco Secure Firewall. SCAZT 300-740 objective 4.6 covers secure private access for users, including zero-trust access — clientless and client-based — using Secure Access and Cisco Secure Client, with QUIC and MASQUE named in the blueprint text. The SCAZT course builds the brokered model hands-on; if your remote access roadmap has both columns, so should your study plan.

Frequently Asked Questions

Is ZTNA just a VPN with better marketing?

No — the access model differs at the network layer. A client-based remote access VPN authenticates a user and then gives their device a routable path into some portion of the internal address space; policy can narrow that path tightly, but the grant is network-shaped. ZTNA, as typically designed, authenticates a user and connects them to explicitly authorized resources through a broker, without a general route onto the network — though a resource scoped as a broad subnet can approximate one. The practical consequence is what an attacker gets from a stolen credential or compromised device: in the broadly routed VPN case a network foothold, in the application-scoped ZTNA case a set of brokered sessions.

Can ZTNA fully replace a remote access VPN?

For many user-initiated application-access cases, yes — once compatibility and operational requirements are validated — and that is where transitions start. The remainder is traffic that fits the brokered model poorly: server-initiated connections to the endpoint, some VoIP and legacy thick-client protocols, and administrative access to raw infrastructure, with the exact list depending on the product and the applications. Organizations commonly run VPN and ZTNA side by side for a period, shrinking the VPN's scope as applications migrate rather than declaring a cutover day.

Where do VPN and ZTNA appear on Cisco security exams?

Both, on different exams. SCOR 350-701 v2.0 objective 1.6 covers site-to-site and remote access VPN deployment types, and objectives 2.9 and 2.10 cover configuring and troubleshooting VPN on Cisco Secure Firewall. SCAZT 300-740 objective 4.6 covers secure private access for users, including zero-trust access — clientless and client-based — using Secure Access and Cisco Secure Client, with QUIC and MASQUE named in the blueprint text.