ZTNA vs VPN: moving to zero trust access

What problem does zero trust access solve?

Perimeter security assumed that anything inside the corporate network could be trusted. NIST's zero trust architecture guidance, SP 800-207, explains why that assumption fails: there is no longer a single, easily identified perimeter, and once attackers breach it, "further lateral movement is unhindered".^[1]

A remote-access VPN extends that perimeter to each connected laptop. Once the tunnel is up, the device is on the network, and what it can reach depends on how finely the network is segmented. A stolen password, a hijacked session or an infected laptop can inherit the same reach.

What do NIST's zero trust tenets require?

SP 800-207 sets out tenets rather than products. Three matter most when comparing ZTNA with a VPN:^[1]

• Location is not trust. All communication is secured regardless of network location, and "Network location alone does not imply trust".
• Access is per session. Access to individual resources "is granted on a per-session basis", with the least privilege needed, and authenticating to one resource does not automatically grant access to another.
• Policy is dynamic. Decisions draw on the observable state of the user's identity, the application and the requesting device, and may include behavioral and environmental signals.

NIST protects resources, "not network segments".^[1] That is the core difference from a VPN.

How does ZTNA work in practice?

NIST describes three logical parts.^[1] A policy engine decides whether to grant, deny or revoke access to a resource for a given user. A policy administrator sets up or shuts down the communication path based on that decision. A policy enforcement point, often a client agent plus a gateway in front of the application, enables, monitors and ends the connection.

In a typical flow, the user signs in through single sign-on, the policy engine checks the user's role and the device's state, and the gateway opens a connection to one application. Other applications stay unreachable unless separately approved.

The sign-in step matters as much as the gateway. CISA warns that some forms of MFA are vulnerable to phishing, push bombing and SIM swaps, and calls phishing-resistant MFA, such as FIDO/WebAuthn, the gold standard.^[4] Our guide to passkeys and WebAuthn covers that layer.

Why are VPN gateways a concern?

A VPN concentrator has to accept connections from the internet before it knows who is connecting, which makes it a target in its own right. In January 2024, CISA issued Emergency Directive 24-01 after "widespread and active exploitation" of vulnerabilities in Ivanti Connect Secure and Ivanti Policy Secure, including an authentication bypass that let a remote attacker reach restricted resources.^[5]

ZTNA gateways are internet-facing too, so they need the same patching discipline. The difference is what a successful attacker gets: a narrower, per-application path rather than a foothold on the network.

Agent-based or portal-based access?

NIST describes both models.^[1]

• Agent-based. Software on the device works with a gateway in front of each resource. The agent can report device state, such as patch level and encryption, on every request, and can carry non-web traffic.
• Portal-based. A gateway portal sits in front of one resource or a group of resources. No software is needed on client devices, which suits personal devices and partner access. The trade-off, in NIST's words, is that the enterprise "can only see/scan" devices when they connect to the portal and may not monitor them continuously.^[1]

Many organizations use both: agents on managed laptops, portal access for contractors and web apps.

How do you plan the move?

NIST is direct about the pace: implementing zero trust "is a journey rather than a wholesale replacement", and most enterprises will run a hybrid of zero trust and perimeter-based security for an indefinite period, migrating one business process at a time.^[1] A practical sequence:

1. Survey first. NIST calls for a survey of assets, users, data flows and workflows before deployment; incomplete knowledge leads the policy engine to deny legitimate requests.^[1]
2. Fix identity. Single sign-on and phishing-resistant MFA for everyone who will use the new path.^[4]
3. Pick a first workflow. A web app with a clear user group, such as a finance tool, is easier than a legacy client-server system.
4. Move contractors early. Partner and vendor access is where network-wide VPN accounts carry the most risk.
5. Shrink the VPN. Remove routes and users from the VPN as each workflow moves, rather than switching it off in one step.

How do you measure progress?

CISA's Zero Trust Maturity Model gives a shared yardstick, though CISA now keeps its page among its archived content. Version 2.0 describes five pillars and three cross-cutting capabilities, with four maturity stages: traditional, initial, advanced and optimal.^[3] Scoring each pillar honestly shows where remote access sits against identity, devices and data.

For worked examples, NIST's National Cybersecurity Center of Excellence worked with 24 collaborators to build 19 example zero trust implementations, published as SP 1800-35 in June 2025.^[2] They show how commercial products fit the SP 800-207 model.

Where does this fit for a B2B company?

ZTNA is infrastructure work for your IT team or a network security provider; it is not a service we sell. It connects to the account risks we do cover. A session cookie stolen by malware can still ride a zero trust connection, as our guide to session hijacking and infostealers explains, and leaders' accounts need their own baseline, covered in our executive cybersecurity checklist. For the domain, email and impersonation side, see our digital asset security work.