ZTNA vs VPN: what actually changes

What is the difference between ZTNA and VPN?

A VPN places a device on a network segment and trusts what follows. ZTNA grants a verified user access to one specific application, keeps everything else invisible, and re-evaluates identity, device posture and risk continuously rather than once at connection time. The difference is not encryption — both encrypt. It is the size of what a valid credential unlocks.

Why does one stolen VPN credential become an incident?

Because a VPN grants reachability, and reachability is what an attacker needs. Once a session is established, the compromised device sits inside the trusted segment and can scan, enumerate and reach services that were never intended to be exposed to it. The credential did not just authenticate a user — it moved an attacker inside the perimeter.

The sequence is familiar to anyone who has run an incident:

1. A credential is phished, reused or bought. MFA is bypassed by fatigue, a push-approval or a session token.
2. The VPN session comes up. The attacker is now topologically an insider.
3. They scan the segment. Everything the firewall rules did not explicitly block is discoverable.
4. They move laterally to something valuable — usually a system whose owner assumed “internal only” was a security control.

ZTNA breaks the chain at step three. There is no segment to scan, because the user was never placed on one. A compromised session reaches whatever that user was authorised to open, and nothing else — which converts a breach into an incident with a boundary.

Trust no packet, verify everything. The engineering translation is that network position must stop being a credential.

Robin Johns, author of two books on SASE

What else improves — and what does not

Beyond lateral movement, ZTNA usually improves user experience, contractor and third-party access, merger integration and audit evidence. It does not replace every VPN use case: site-to-site connectivity, non-web legacy protocols, and full-tunnel requirements for regulatory egress control still need attention.

Genuine gains

• User experience. No concentrator to backhaul through, so latency drops — often the change users notice first and the reason adoption sticks.
• Third parties and contractors. Scoping a contractor to two named applications is a policy statement rather than a firewall-rule archaeology project.
• Mergers and acquisitions. You can grant access to specific applications without routing between two networks and inheriting the other side’s trust model.
• Audit. Per-application, per-user access logs answer “who could reach this?” directly, which VPN logs never really did.

Where ZTNA is not the answer

• Site-to-site connectivity. That is SD-WAN’s job, not ZTNA’s.
• Awkward legacy protocols. Most ZTNA products handle far more than HTTP now, but thick clients with dynamic port negotiation still need proving in a pilot rather than assuming.
• Full-tunnel egress requirements. If policy requires all traffic to leave via a controlled egress point for inspection or IP attribution, that is a separate requirement — usually met by the wider SASE platform rather than by ZTNA alone.
• Device-level access with no user. Headless systems and OT need their own model.

Being honest about this list is what keeps a migration credible. Teams that promise ZTNA replaces every VPN use case tend to lose the room the first time an engineer names one it does not.

How do you migrate from VPN to ZTNA?

Application by application, with the VPN still running. Start with the applications that are web-based, widely used and low-risk, prove the experience, then work outwards. Decommission the concentrator only when telemetry shows nothing is still traversing it.

1. Inventory what the VPN actually reaches. Not what the documentation says — what the flow logs show. This step alone usually finds services nobody knew were exposed.
2. Pick the first wave: web applications, high user count, low blast radius. You are buying credibility, not coverage.
3. Run in parallel. Both paths live. Users notice the faster one on their own.
4. Move third parties early. Highest risk reduction per application, and the scoping conversation is easier with an external party than an internal one.
5. Tackle the awkward protocols deliberately, with a named owner and a pilot. These are what stall migrations when left to the end.
6. Watch the concentrator logs until they flatline, then decommission.

ZTNA is normally the first stage of a broader SASE programme for exactly this reason: it delivers a visible improvement quickly, and it retires a well-understood risk without requiring the network team to change anything about branch connectivity yet.

Frequently asked questions