ZTNA vs VPN: Security Gains, Limits and Migration Steps

A remote access VPN authenticates a user once and then places their device on the network, so one stolen password or one unpatched gateway can become access to everything that network can reach. Zero trust network access (ZTNA) changes the unit of access from the network to the individual application, with a policy decision for each session. This guide compares the two as concepts, not products: how each works, where each still fits, what ZTNA does not fix, and how to move from one to the other without breaking the business. It is written for network, identity and security architects who own remote access, and it goes deeper on the comparison than the Secure Remote Access Beyond VPN Guide.

Key takeaways

• The core difference is the unit of access. A VPN grants a network path and relies on firewall rules behind it; ZTNA grants a session to one named application after checking identity, device and context, which is the per-session access tenet in NIST SP 800-207.
• ZTNA removes inbound exposure, not identity risk. Most ZTNA designs use outbound-only connectors, so there is no listening VPN concentrator to exploit, but a valid stolen session or weak MFA still gets in, just to fewer places.
• VPNs still have legitimate jobs. Site-to-site links, full-tunnel requirements, some legacy protocols and break-glass access can justify keeping a hardened VPN, ideally narrowed and behind phishing-resistant MFA.
• Migration is per application, not a switch. NIST SP 800-207 expects hybrid perimeter and zero trust operation for an extended period; move applications in waves, run the VPN in parallel, then shrink and retire it.
• Measure the shrink. Track VPN users and routes remaining, applications behind per-app policy, phishing-resistant MFA coverage and denied lateral connection attempts, not just ZTNA licences issued.

How each model works

Remote access VPN

A remote access VPN builds an encrypted tunnel, usually IPsec with IKEv2 or TLS based (often called SSL VPN), from the client to a concentrator at the network edge. After authentication the client receives an internal IP address and routes. In full-tunnel mode all traffic goes through the corporate network; in split-tunnel mode only routes for internal ranges do. What the user can then reach is decided by firewall rules and network segmentation behind the concentrator, not by the VPN itself. If those rules are broad, the user, and anyone holding their session, sees a broad slice of the network. See How VPNs Work for the protocol detail.

Zero trust network access

ZTNA brokers access to individual applications. In NIST SP 800-207 terms, a policy engine decides whether to grant, deny or revoke a request, a policy administrator sets up or tears down the session, and a policy enforcement point (PEP) sits in the path. Common ZTNA products implement the device agent and gateway deployment model from SP 800-207 section 3.2 (an agent on the device, a gateway or connector in front of the resource), or the resource portal model (a browser based proxy with no client, useful for contractors and unmanaged devices but with less device visibility). Connectors typically make outbound connections to a broker, so the application has no inbound listener on the internet. The user never receives a routable address on the internal network: they get a session to the specific application the policy allows. Where the PEP is an HTTP proxy, see the Identity-Aware Proxy Guide.

Side-by-side comparison

What ZTNA fixes and what it does not

The security gain is real but specific. Being precise about it avoids buying ZTNA and keeping the same failures.

• Fixes, exposed edge: internet-facing VPN appliances are a repeated initial access route, mapped in ATT&CK as T1190 Exploit Public-Facing Application and T1133 External Remote Services. Outbound-only connectors remove the listening service in front of each application. See the Ivanti Connect Secure Hardening and Integrity Checking Guide for how a VPN edge is hardened while it remains.
• Fixes, flat reach: a VPN user lands on a network; a ZTNA user gets an application. This limits T1021 Remote Services lateral movement from the remote device.
• Fixes, one-time trust: posture and risk can be re-evaluated during the session, so a device that loses its EDR agent or changes location can be cut off.
• Does not fix, stolen identities: T1078 Valid Accounts still works if the attacker has the password and can pass MFA. ZTNA narrows the blast radius, phishing-resistant MFA closes the door. The Cisco 2022 breach began with a synced browser password and MFA push fatigue on VPN access; the same pattern defeats any access broker that accepts push approval.
• Does not fix, broad policies: a ZTNA policy of "all employees to 10.0.0.0/8" recreates the VPN with a new logo. The value comes from per-application rules.
• Does not fix, the broker itself: the ZTNA control plane and identity provider become the critical path. Their administrators, API tokens and connector credentials are high-value non-human and privileged identities.

When to use each

Small organisations with a handful of internal applications often get most of the benefit by moving those applications to SaaS or behind an identity-aware proxy and keeping a minimal VPN for admin work. Large organisations usually buy ZTNA as part of a security service edge (SSE) or SASE platform, because the same client then carries secure web gateway and CASB traffic; see the SASE and SSE Guide. CISA and its partners' guidance "Modern Approaches to Network Access Security" encourages organisations of all sizes to move from traditional VPN deployments towards zero trust, SSE and SASE.

Trade-offs to plan for

• Application inventory: ZTNA policies need named applications with owners. Organisations without a current inventory find the policy work, not the technology, is the long pole.
• Dependency on the identity provider: every access decision flows through the IdP and broker. Plan availability, break-glass accounts and what happens when the IdP is unreachable.
• Service-to-service traffic: ZTNA is built for user to application access. Workload to workload paths need workload identity and microsegmentation instead; see the NIST SP 800-207A Zero Trust for Cloud-Native Applications Guide.
• Traffic inspection and privacy: cloud-delivered brokers terminate or proxy traffic outside your network. Check where logs and decrypted traffic are processed and stored.
• Cost and licensing: per-user ZTNA licences replace appliance costs; the VPN must still be paid for during the parallel run.

Migration steps from VPN to ZTNA

NIST SP 800-207 section 7 describes migration as gradual: identify actors, assets and processes, write policy for one candidate workflow, deploy in observation mode, then expand. Applied to remote access:

1. Baseline the VPN. Export VPN group membership, assigned routes and a few weeks of flow logs. Identify which internal destinations and ports each group actually uses, and which accounts, including service and shared accounts, connect.
2. Harden what stays. While migrating, require phishing-resistant MFA on the VPN, remove dormant accounts, patch the concentrator against vendor advisories and remove any local accounts on it.
3. Build the application catalogue. Map each destination to a named application, an owner, its protocols and the user groups that need it. This becomes the ZTNA policy set.
4. Pilot with low-risk web applications. Start with HTTP(S) apps and a pilot ring of IT staff. Define policies with identity group plus device posture (managed, disk encrypted, EDR running). Log only or allow with alerting at first.
5. Move in waves. Web apps, then SSH and RDP targets (with PAM for administrators), then thick clients after protocol testing. For each wave remove the matching routes from the VPN profile so users cannot fall back silently.
6. Handle third parties early. Contractor VPN accounts are frequently the broadest and least reviewed. Move them to per-app access with an expiry date.
7. Shrink and retire. Reduce the VPN to remaining exceptions and break-glass. Close the public listener when the last wave is done, and keep a documented exception register for anything left.

Testing and rollback: keep the VPN profile available to each wave for an agreed period (for example two weeks), but monitor its use; rising VPN use from a migrated group signals a missing ZTNA policy. Rollback for a wave is re-adding its routes to the VPN profile, not reopening everything.

Each option in depth

For each option below: the threat it is built for, how it fails, the controls that make it work, when to choose it and a worked example.

VPN

Threat model. A VPN gives an authenticated device a network presence. Its threats are exploitation of the internet-facing appliance (T1190), stolen credentials used on an external remote service (T1133, T1078) and lateral movement once inside (T1021). Joint guidance led by CISA with the FBI and partners in New Zealand and Canada, Modern Approaches to Network Access Security, describes misconfigured remote access as an inherent business risk and urges organisations of all sizes towards zero trust, SSE and SASE.

Failure modes. Flat access once connected; unpatched appliances; appliance secrets such as LDAP and RADIUS bind credentials never rotated; and push-based MFA.

Controls. Patch the appliance on an emergency cadence, restrict post-connection reach with segmentation, enforce phishing-resistant MFA and rotate appliance secrets after any exposure.

Decision criteria. Keep a VPN for legacy protocols, site-to-site links and administrative paths not yet behind a broker, with reach limited per group.

Worked scenario. A manufacturer keeps a VPN only for an engineering group reaching plant historians, segmented to those hosts, while office staff move to ZTNA.

ZTNA

Threat model. ZTNA brokers access per application after checking user and device, so a stolen credential reaches one application rather than a network. Its threats move to the broker, its connectors and the identity provider.

Failure modes. Weak MFA on the broker; connectors with over-broad network reach; and policies copied from VPN groups.

Controls. Phishing-resistant MFA, per-application policy, connector credentials rotated and monitored, and broker logs in the SIEM.

Decision criteria. Choose ZTNA for user access to web and private applications where device posture can be checked.

Worked scenario. After migration, a contractor's stolen password reaches only the ticketing application, and the device check fails because the attacker's laptop is unmanaged.

Where identity fits

Both models depend on identity, but ZTNA makes it the whole control. Three identity points decide the outcome. First, user authentication: the Change Healthcare breach began at a remote access portal without MFA, and no access architecture compensates for a single factor at the front door. Second, machine identities in the access path: ZTNA connectors authenticate to the broker with certificates or enrolment tokens, and the broker has admin API keys; these are non-human identities to inventory, rotate and monitor. Third, device identity: posture checks only work if devices carry a trusted certificate or management attestation. The SonicWall SSL VPN account compromises in 2025 show why VPN appliance secrets such as LDAP and RADIUS bind credentials must be rotated after any configuration exposure; the same discipline applies to ZTNA connector credentials. See the Zero Trust for AI Agents Guide for agents that need remote access to internal tools.

Detection and measurement

• Log sources: VPN authentication and session logs, ZTNA broker decision logs (allow, deny, step-up, with reason), connector health, IdP sign-in logs and device management posture changes.
• Alerts worth having: VPN or ZTNA logins from new countries or hosting providers, many accounts from one source IP, MFA push denials followed by approval, connector enrolment from an unexpected host, and policy changes outside change windows.

Common failure patterns

• Network-wide ZTNA policies: broad CIDR rules copied from the VPN, so a compromised user still reaches whole subnets.
• VPN left running "just in case": the public concentrator stays exposed and unpatched after migration because a few users still depend on it and no one owns the exception list.
• Weak MFA on the new broker: push approval or SMS on ZTNA repeats the Cisco 2022 pattern; the architecture changed but the initial access route did not.
• Posture checks that only run at connect: a device that disables its agent mid-session keeps access for hours.
• Connector and API credentials ignored: enrolment tokens left in scripts and admin API keys with no owner turn the access layer into a soft target.
• No break-glass path: an IdP or broker outage locks out the people who need to fix it.

Framework mapping

Practitioner checklist

• Export VPN groups, routes and flow logs, and map each destination to a named application and owner.
• Require phishing-resistant MFA on the VPN now and on the ZTNA broker from day one.
• Write ZTNA policies per application with identity group and device posture; reject CIDR-wide rules.
• Pilot with web applications and an IT ring in observation mode before enforcing.
• Remove VPN routes for each migrated wave and watch for fallback use.
• Move third-party access to per-app policies with expiry dates early in the programme.
• Inventory and rotate ZTNA connector credentials and broker admin API keys.
• Keep a documented break-glass path and test it quarterly.
• Track the six metrics above and report VPN shrinkage to leadership.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• CISA: Modern Approaches to Network Access Security
• CISA: Zero Trust Maturity Model
• NCSC: Zero trust architecture design principles
• OMB: M-22-09 Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: External Remote Services

Related NHI Mgmt Group resources: Secure Remote Access Beyond VPN Guide · Zero Trust vs Perimeter Security · SASE Migration · NIST SP 800-207 Zero Trust Architecture Guide · Top 10 Zero Trust Mistakes