ZTNA vs VPN: a decision guide

Who this is for: network and security leads deciding whether a remote-access VPN should stay, shrink, or go.

How do the standards define these terms?#

The term ZTNA does not appear in NIST SP 800-207, Zero Trust Architecture. The standard defines zero trust and zero trust architecture; the UK National Cyber Security Centre (NCSC) describes ZTNA as an architectural approach to controlling how users and devices access applications, and vendors also use the name for a product category.

Three NIST statements carry most of the weight:

• Zero trust is the term for an evolving set of paradigms that move defenses “from static, network-based perimeters to focus on users, assets, and resources” (abstract).
• No implicit trust from location. No trust is granted to assets or user accounts based solely on their physical or network location, or on who owns the asset (abstract). Tenet 2 adds that network location alone does not imply trust.
• Per-session access. Tenet 3: access to individual resources is granted per session, trust is evaluated before access is granted, and access to one resource does not grant access to another.

NIST also names the parts of the decision (section 3). The policy engine decides to grant, deny, or revoke access; the policy administrator establishes or shuts down the communication path; the policy enforcement point enables, monitors, and terminates connections. In the agent/gateway model (section 3.2.1), an agent on the device directs traffic to the enforcement point. On VPNs, section 3.4.1 says remote subjects should not be required to use a link back to the enterprise network to reach cloud-hosted services, and the introduction notes that once attackers breach a perimeter, further lateral movement is unhindered.

In this guide, “VPN” means a tunnel that gives a device a route into a private network, with access then governed mostly by network rules.

Which should you use? The ZTNA vs VPN decision table#

This is the ZTNA vs VPN decision table. The basis column says where each row comes from; rows marked “design judgment” are our reading of the trade-off.

What are the decision rules?#

Apply them in order. Each rule names a condition and a result.

1. Users need internal web, SSH, or remote-desktop applications. Use ZTNA, with an Access policy in front of each application, scoped to the groups that need it.
2. Managed devices need a private network range. Use ZTNA with Tunnel and the Cloudflare One Client (formerly WARP), which Cloudflare calls the device-to-network scenario, and add a catch-all block for the private IP space.
3. The application starts connections back to devices, or devices must reach each other. Tunnel does not carry server-initiated traffic; Cloudflare Mesh covers bidirectional connectivity and is in beta.
4. Offices or data centers must be connected. This is network-to-network: a VPN, SD-WAN, Mesh nodes, or Cloudflare WAN, which is Enterprise-only.
5. The application cannot be described by user, device, and protocol. Leave it on the VPN until it can be, and record the reason.
6. Nothing forces a decision for the whole estate. Run both, with responsibilities split as below.

How do you run both during the move?#

The Cloudflare One Client and a legacy VPN client both want to control routing, DNS, and firewall rules on the device. Cloudflare’s documentation divides the work:

Cloudflare also says the most stable path is to connect your private network or applications to Cloudflare instead of keeping the legacy VPN, and the NCSC advises against removing a VPN until the same security benefits exist in other ways. Coexistence is a migration state, not a target. A phased plan with rings and exit criteria is in Replace your VPN with Cloudflare Zero Trust, in phases.

Which policy mistakes undo the benefit?#

ZTNA does not help if the policy is as broad as the network was. Cloudflare’s Access documentation lists two common misconfigurations: an Allow policy that includes Everyone, and one that includes the One-time PIN login method, each of which lets anyone access the application. Bypass policies enforce no Access controls and their requests are not logged; Cloudflare recommends Tunnel with the Cloudflare One Client instead of Bypass for permanent internal access.

A short review list, as a starting point rather than a standard:

• Every Allow policy names a group or a posture requirement, not everyone with a valid email.
• A catch-all block covers the private IP space reached through tunnels.
• No permanent Bypass policy covers an internal application.
• Each application has an owner who approves its policy, and a break-glass path exists.