ZTNA vs VPN: what is the difference and which fits your team?

A VPN joins a remote device to a network, so the user can often reach many systems. Zero trust network access (ZTNA) grants a verified user access to specific applications, after checking identity and device, without placing them on the network. ZTNA narrows access; a VPN can still be right for some uses.

How does a VPN work?

A VPN builds an encrypted tunnel from a device to a gateway. Once connected, the device usually gets an address on the internal network and is treated like a local machine. What it can reach depends on the firewall rules behind the gateway.

That is simple and works with almost any application. The cost is that the unit of trust is the network. A compromised device on the VPN is, from the network's point of view, inside.

How does ZTNA work?

NIST SP 800-215 lists ZTNA among the security frameworks that integrate network configurations, and SP 800-207 describes the idea behind it: authentication and authorisation of subject and device are performed before a session to a resource is established, and the focus is on resources, not network segments.

In ZTNA, a broker sits between the user and each application. The user signs in, the device is checked, and policy decides whether this person on this device may reach this application. If yes, the broker connects them to that application only. Other systems on the same network are not visible.

What are the real differences?

Unit of access. VPN: the network. ZTNA: the application.

Exposure. A VPN gateway is itself an internet-facing service. CISA and others have repeatedly warned about attacks on VPN gateways, so keep them patched and use multifactor authentication. ZTNA brokers also face the internet, so the same care applies.

Device awareness. VPNs can check device state, but many do not by default. ZTNA designs usually make device health part of each decision.

Lateral movement. A compromised VPN user can scan and move across the network. A compromised ZTNA user can reach only what policy lists.

Visibility. ZTNA logs record which user reached which application. A VPN log often records only that a tunnel existed.

Compatibility. A VPN works for nearly anything, including odd protocols and server to server flows. ZTNA works well for web apps and common protocols and may need extra work for others.

What does a constructed example look like?

A 200 person company has a VPN that gives all remote staff access to every internal subnet. The review finds that contractors on the VPN can reach the engineering build servers and the finance database. They move the finance system and the wiki to ZTNA first, where policy lists named groups and requires a managed device. The VPN stays for a legacy application that uses a custom protocol, but it is restricted to one subnet and one group.

How should you migrate?

Not with a cut-over weekend. NIST and CISA both describe a staged approach. Inventory applications, group users by what they need, move web applications first, and shrink the VPN's allowed range as each moves. Keep break-glass access documented and tested in case the broker is unavailable.

What are the costs people forget?

Policy design takes real time: someone must decide which groups reach which applications. Device checks require an inventory you can trust, and exceptions pile up if it is wrong. Users need clear instructions and a help route for blocked sessions. And the broker becomes a critical dependency, so plan for its failure with documented emergency access. None of these argue against ZTNA. They argue for a pilot with a small group before a company-wide move.

How to check or apply this

1. Export what a typical VPN user can reach, and compare it with what they need.
2. Confirm the VPN gateway is patched and requires multifactor authentication.
3. Pick two web applications with clear user groups for a ZTNA pilot.
4. Define device requirements: encryption, patch level, management status.
5. Log each access decision and review denials.
6. After each move, remove the matching VPN network rules.

Quick check

Sources

• NIST SP 800-207, Zero Trust Architecture
• NIST SP 800-215, Guide to a Secure Enterprise Network
• CISA, Zero Trust Maturity Model
• CISA AA21-131A

Last reviewed: 18 October 2026.