ZTNA vs VPN: Which Should You Choose?

ZTNA vs VPN is a choice between two ways of giving people remote access. A VPN (virtual private network) builds an encrypted tunnel that puts a device onto a private network, while ZTNA (zero trust network access) checks the user, the device, and the context first and then connects the user only to the applications they are allowed to use. ZTNA is the network-access side of zero trust architecture and is not a single product, so its exact meaning varies by vendor. Most organizations do not switch overnight; the practical question is which applications move first and what to do with the VPN that remains.

What a VPN does well and where it struggles

NIST SP 800-215 describes a VPN as a way to extend perimeter-based security across a public network, using a secure tunnel built with protocols such as IPsec or TLS. Once the tunnel is up, the user is effectively on the internal network and can reach whatever the network and firewall rules allow. That model is simple and works with almost any application, which is why the UK NCSC lists real benefits: it lets legacy systems work remotely, adds a second layer of defence, and lets you force traffic through monitoring tools.

The same guidance points to these limits:

• Network-level access: a connected user can usually reach whatever the network allows, so one stolen account may expose more than the applications that person needs, depending on segmentation
• A gateway facing the internet: VPN servers are exposed and therefore targeted. A 2021 NSA and CISA information sheet warned of credential harvesting, remote code execution, and session hijacking, and NCSC stresses quick patching
• Hair-pinning: NIST SP 800-215 notes that VPN users' traffic to cloud services lands at the corporate edge and is routed back out to the internet, which adds distance and latency
• Scale and operations: hardware appliances cap the number of users, VPN clients are hard to roll out to many third parties (NIST SP 800-215), and NCSC warns that a VPN failure can cause an organisation-wide outage

What ZTNA does differently

In NIST SP 800-207 terms, a policy engine and a policy administrator decide each request, and a policy enforcement point (PEP) opens the connection only if the answer is yes. NIST SP 800-215 describes ZTNA as the paradigm for network communication flows under zero trust, built from a client or browser, a controller that evaluates policy, and a gateway that enforces it. The result is a connection to one application at a time instead of a connection to a network, and NIST SP 800-207 describes resources that cannot be reached without going through a PEP.

NIST SP 800-207 describes three main deployment models:

• Device agent/gateway: software on the device and a gateway in front of each resource, connected only after approval. NIST says it suits organizations with strong device management
• Resource portal: no agent is needed, so it is more flexible for BYOD and partners, but the organization sees little about the device and can check it only when it connects
• Enclave: one gateway guards a group of resources such as a data center, which suits legacy applications that cannot sit behind their own gateway, though it protects the group rather than each resource

ZTNA is not automatically narrower

The ZTNA label does not guarantee narrow access. Microsoft's documentation for its own ZTNA product, for example, includes a Quick Access mode that publishes broad IP ranges to give VPN-equivalent access, and calls it a migration bridge before high-value apps move to per-app access. The picture below is an illustrative ordering, not a measured result.

• A new critical dependency: the policy engine, administrator, and enforcement points become key to every workflow. NIST SP 800-207 warns about denial of service and suggests secured cloud hosting or replication across locations, which reduces the risk but does not remove it
• Some applications may not fit: check protocol support, including UDP and traffic that starts from the server side, before promising a migration date
• You must know your own apps: per-app policy needs an application inventory. Microsoft provides an application discovery report to help when the inventory is incomplete
• Endpoint risk remains: a compromised but authenticated device can still misuse an app it is allowed to reach. ZTNA limits the damage; it does not remove it
• Processing location and logs: ask where traffic is processed and where logs are stored

How to choose

• Mostly cloud and SaaS apps, many remote or third-party users: start with ZTNA. NIST SP 800-207 says processes that use cloud resources or serve remote workers are often good first candidates, and clients can request cloud services directly instead of coming in over a VPN
• Legacy systems, flat internal networks, site-to-site links, or protocols that per-app proxying cannot handle: keep a hardened VPN, or use an enclave gateway. NCSC notes a VPN lets legacy systems work remotely
• Contractors and unmanaged devices: use portal-style or agentless access limited to the web apps they need, and consider browser isolation, which NIST suggests as a compensating measure when device visibility is limited
• Small team, few applications: a hardened VPN with MFA and network segmentation may be enough. ZTNA pays off more as apps and users grow

A common pattern is to run both for a while: ZTNA for most users and applications, and a hardened VPN for the exceptions, which shrink over time. NCSC says there is little benefit in a VPN once zero trust is fully adopted, so the goal is to retire VPN access one exception at a time. For web and cloud security in the same service, see SASE and SSE Explained: When Each One Fits, which usually include ZTNA.

Moving from VPN to ZTNA in order

The order that reduces risk is: learn what is actually in use, fix identity and device basics, pilot with a small group, run alongside the VPN, then narrow access using real usage data. This matches NIST SP 800-207, which suggests starting with a low-risk business process and expanding from there. Which MFA Is Safer? helps you choose the sign-in method for step two.

If you keep a VPN, harden it

• Choose standards-based products: the 2021 NSA and CISA information sheet steers organizations toward standards-based rather than proprietary VPNs
• Patch quickly: NCSC stresses that VPN services are internet-exposed, and the 2025 joint edge-device guidance that CISA co-published covers VPN gateways
• Use IPsec and certificates: NCSC recommends IPsec, accepts TLS VPNs, and prefers certificates over pre-shared keys
• Full-device tunnel, no split tunnelling: use the native client, forced and automatic, as NCSC advises
• Add MFA, and choose a phishing-resistant type where you can
• Test failure: NCSC advises testing robustness and planning backup options

Start today

• List your VPN users: who uses it, in which groups, and what each group can reach through firewall rules after connecting
• Rank your top ten applications: by users and criticality, and mark which are web or SaaS, which are the easiest to move
• Check the VPN gateway: version, patch status, and MFA coverage
• Remove unused accounts and access: this shrinks what an attacker can use whether or not you migrate
• Choose a pilot: one application and one user group, such as contractors

To see where network access sits against your other zero trust gaps, try the self-assessment, and use network segmentation to shrink what a VPN user can reach while you migrate.

Common mistakes

• Treating ZTNA as a renamed VPN: publishing whole subnets and calling it ZTNA still gives flat access
• Moving everything at once: if the decision point or a gateway has a problem, everyone loses access at the same time
• Ignoring identity and device signals: policy is only as good as the signals feeding it, so you need MFA and device state
• Leaving the old VPN open: an unmaintained gateway is still an attack path, so close or restrict it as apps move
• Skipping availability: plan a fallback and break-glass accounts for the day the provider has an outage
• Forgetting third parties and unmanaged devices: they need a different path and tighter limits than employees

A VPN gateway is exposed to the internet, so patching should be ranked using evidence of real attacks; see CVSS vs EPSS vs KEV: Prioritizing Vulnerability Fixes.

References and further reading

• NIST SP 800-207: Zero Trust Architecture: definition, components, and deployment models
• NIST SP 800-215: Guide to a Secure Enterprise Network Landscape: limits of VPN-based access, plus ZTNA, SDP, and SASE
• NCSC: Zero trust architecture design principles: the UK's zero trust design principles
• NCSC: Virtual private networks (VPNs): benefits, risks, and recommended VPN configuration
• CISA and NSA: Guidance on Selecting and Hardening VPNs (2021): the alert announcing the information sheet on choosing and hardening VPNs
• CISA and partners: Modern Approaches to Network Access Security (2024): urges a move toward Zero Trust, SSE, and SASE
• CISA and partners: guidance on edge devices (2025): guidance on protecting edge devices, including VPN gateways
• Microsoft Learn: VPN replacement with Quick Access: vendor documentation example: VPN-equivalent first, then per-app
• Zscaler: What is ZTNA?: a vendor's view of ZTNA versus VPN, to be read as a seller's claims