ZTNA vs VPN: How They Actually Differ — and When to Use Each
VPNs have been running enterprise remote access since the 1990s. They work. Nobody argues that. The problem is what they do beyond working — they put remote users on the network, trust them like insiders, and then leave it to other tools to figure out if something goes wrong. ZTNA is the opposite design: assume nothing, verify everything, grant access only to what the user needs. That difference sounds simple. The implications are not.
April 2026 | ⏱ 14 min read | Zero Trust • Network Security • Remote Access | ⚙ Enterprise & Mid-Market
In This Article
1. How VPNs Work
2. How ZTNA Works
3. The Core Differences
4. Head-to-Head Comparison Table
5. Security Posture: Where VPN Fails
6. Performance: What the Numbers Actually Show
7. Use Cases — Who Should Use What
8. Migrating from VPN to ZTNA
9. FAQ
1. How VPNs Work
A VPN creates an encrypted tunnel between the user’s device and a VPN gateway. Once that tunnel is up, the device is assigned an IP address on the corporate network. From that point, the user has network-level access — they can reach servers, shared drives, printers, internal tools, and anything else the network allows.
The authentication happens once: usually a username and password, sometimes with MFA. After that, the tunnel stays open. The VPN concentrator doesn’t care what the user does next. It doesn’t inspect sessions, doesn’t verify device posture continuously, and doesn’t limit access to specific applications. The network decides what the user can reach — which means firewall rules and VLAN segmentation do the actual access control work.
VPN Access Flow
| User Device | → | Encrypted Tunnel | → | VPN Gateway | → | Full Network Access |
Once authenticated, the device is on the network. Access control depends on downstream firewalls and ACLs.
This worked fine when the network perimeter was a physical thing — when servers were in a data center, employees were in an office, and the internet was mostly outside. That world doesn’t exist anymore for most organizations. Applications moved to SaaS. Employees work from anywhere. Contractors need access from unmanaged devices. VPN architecture wasn’t designed for any of that.
Common VPN Protocols in Use
| IPsec / IKEv2 | High-performance, widely supported, complex to configure |
| SSL/TLS (OpenVPN) | Firewall-friendly, slower than IPsec, flexible client support |
| WireGuard | Fast, modern, minimal attack surface — still network-level access |
| SSTP / L2TP | Older, Windows-native, largely being replaced |
2. How ZTNA Works
ZTNA — Zero Trust Network Access — starts from a different assumption: that being on the network doesn’t make you trustworthy. Access is granted per-application, not per-network. A user authenticates and the ZTNA controller checks identity, device posture, location, time, and risk score before deciding what that specific session can access.
There are two deployment models. In the agent-based model, a lightweight agent on the endpoint handles authentication and routes application traffic through a ZTNA broker. In the agentless model (also called browser-based or clientless), users access a proxy portal — no software on the endpoint. Agentless is useful for BYOD and contractor scenarios. Agent-based gives deeper device posture visibility.
ZTNA Access Flow
| User + Device | → | ZTNA Controller (identity + posture check) |
→ | Policy Engine (allow / deny per app) |
→ | App-Only Access (no network reach) |
User gets access to Salesforce or Jira. Not the network. Not the server subnet. Not anything else.
The key piece is that the application is never directly exposed to the internet. The ZTNA connector (deployed near the application) makes an outbound connection to the ZTNA broker in the cloud. User traffic flows through that broker. The app has no public IP address in DNS. Attackers can’t scan for it. They can’t find it.
Every session is evaluated continuously — not just at login. If a device’s posture changes mid-session (antivirus disabled, OS out of compliance), the session can be terminated automatically. VPN doesn’t do any of that.
3. The Core Differences
The gap between these two approaches comes down to where trust is placed, and at what granularity access is granted. Everything else follows from those two things.
|
VPN Trust Model Trust is granted at the network level. One successful authentication means network-wide access. The device is treated as an insider. |
ZTNA Trust Model No implicit trust. Every session is verified against identity, device posture, and context. Access is per-application, not per-network. |
|
VPN Exposure VPN concentrators need an IP address that resolves publicly. That surface is visible and has been the entry point for attacks on Pulse Secure, Fortinet, and Cisco ASA VPNs. |
ZTNA Exposure Applications are not exposed. The connector phones home. There’s no IP address for an attacker to scan. The attack surface reduction is genuine, not just conceptual. |
|
VPN Lateral Movement Compromised VPN credentials mean network access. Ransomware and APT groups use this constantly — VPN compromise is in the top five initial access vectors every year. |
ZTNA Lateral Movement Compromised credentials give access only to what that user was permitted to see. Lateral movement requires separately compromising each application’s access grant. |
4. Head-to-Head Comparison Table
| Factor | VPN | ZTNA |
| Access scope | Network-wide | Per-application only |
| Trust model | Authenticate once, trusted after | Continuous verification per session |
| Internet exposure | VPN gateway has public IP | Applications invisible to internet |
| Device posture | Checked at login (if at all) | Continuous, per-session enforcement |
| Lateral movement risk | High — network access enables it | Low — app-only access limits blast radius |
| Performance | Backhauling degrades SaaS speed | Direct-to-app or nearest PoP |
| BYOD / unmanaged devices | Risky; hard to restrict | Agentless option purpose-built for this |
| Complexity | Simple to deploy, complex ACLs to maintain | Complex identity/policy setup, simpler ACLs |
| Cost | Lower upfront; scales with bandwidth | Higher per-user licensing; lower incident cost |
| Non-IP protocols | Supported (full network tunnel) | Limited — mostly HTTP/HTTPS apps |
| OT / legacy systems | Works; can reach any IP-addressable device | Poor fit; limited non-HTTP support |
5. Security Posture: Where VPN Falls Apart
VPN vulnerabilities are not theoretical. Pulse Secure, Fortinet SSL VPN, Cisco ASA, and Palo Alto GlobalProtect have all had critical CVEs exploited in the wild over the past four years. In most cases, the attacker didn’t need credentials — they exploited a bug in the VPN gateway itself. That gateway has to be reachable to function. That reachability is the problem.
The other problem is credential theft. A user’s VPN credentials end up in a phishing attack or a breach dump. The attacker uses them. They’re now on the corporate network. Many organizations have spent years trying to solve this with additional controls on top of VPN — NAC, micro-segmentation, endpoint detection — which is expensive and operationally exhausting.
| Attack Vector | VPN Impact | ZTNA Impact |
| Stolen credentials | Full network access | App-only; posture check may block |
| CVE in remote access gateway | Exploitable (publicly reachable) | No public-facing surface to exploit |
| Compromised endpoint | Lateral movement to network | Session terminated if posture fails |
| Contractor on unmanaged device | Full tunnel, no posture check | Agentless; access limited to specific apps |
| Ransomware lateral movement | Network-wide blast radius | Contained to authorized apps only |
ZTNA is not immune to attacks. A user with legitimate ZTNA access who gets phished can still do damage within the apps they can reach. The difference is the blast radius. Instead of “attacker has network access and now owns everything”, it’s “attacker can access Salesforce and the time-tracking system.” That’s still bad. It’s not as bad.
The MFA caveat: Modern VPN deployments with MFA, device certificates, and continuous endpoint monitoring close a lot of the gap. VPN + EDR + NAC + microsegmentation can get you most of the way to ZTNA-level security. It’s just four products instead of one, with four sets of policies to maintain.
6. Performance: What the Numbers Actually Show
VPN performance complaints come from a specific architecture decision: split tunneling disabled. When all traffic goes through the VPN gateway, a user in London going to Salesforce.com sends traffic to a data center in Frankfurt, gets inspected, and then goes back out to Salesforce. That’s three hops instead of one.
Split tunneling fixes this for SaaS — but then corporate traffic and internet traffic share the same unmonitored device. That’s a security trade-off most security teams are uncomfortable making.
ZTNA solves this differently. Application traffic routes to the nearest ZTNA PoP. Internal applications route through the application connector. SaaS traffic can go direct, with ZTNA handling identity and session enforcement at the edge rather than backhauling to the data center.
Where Each Performs Better
| Scenario | VPN | ZTNA |
| SaaS apps (Salesforce, M365) | Backhaul penalty (no split tunnel) | Direct with PoP enforcement |
| Internal data center apps | Low latency (direct tunnel) | Connector adds minor overhead |
| Large file transfers | Full bandwidth at tunnel speed | May proxy traffic; depends on vendor |
| Remote work video calls | Congestion at gateway during peaks | PoP closer to user; consistent latency |
7. Use Cases — Who Should Use What
Neither is obviously wrong. The answer depends on what the access is for and who’s getting it.
Use VPN when…
You need access to non-HTTP protocols (RDP without a proxy, SFTP, custom TCP/UDP applications). OT environments. Legacy systems that weren’t built for identity-aware access. Situations where the full network is the thing being accessed and granular app control isn’t the goal. Small organizations where the overhead of ZTNA policy management doesn’t justify the security gain.
Use ZTNA when…
You have contractors or third parties who need access to specific applications but not the network. You’re primarily a SaaS shop. You’ve had VPN-related security incidents. You’re trying to comply with a Zero Trust framework (NIST 800-207, CISA ZTA). You have BYOD requirements and can’t install device certificates on personal machines.
Use both when…
This is actually the most common real-world scenario. ZTNA handles employees and contractors for web applications. VPN handles the infrastructure team that needs RDP access to Windows servers, the OT team that talks to PLCs, and the developers who need SSH to production. The two aren’t mutually exclusive.
| Scenario | Recommended | Why |
| Remote employees, SaaS-heavy org | ZTNA | Direct to app, no backhaul, per-app control |
| Third-party contractors, BYOD | ZTNA (agentless) | No agent install, limited app scope |
| Infrastructure team, SSH / RDP access | VPN | Non-HTTP protocols; full network needed |
| OT / ICS environments | VPN | Custom protocols; ZTNA rarely supports OT |
| Mixed workforce (employees + contractors) | Both | VPN for infra team; ZTNA for everyone else |
8. Migrating from VPN to ZTNA
Most organizations that migrate to ZTNA don’t do it all at once. They pick a group of users or a specific application category and start there. Contractors are usually the first group because they’re the easiest case: they have limited access needs, they often use unmanaged devices, and nobody complains when contractor access gets tightened.
| Phase | What Changes | What Stays |
| 1. Pilot | Contractors & BYOD users move to ZTNA (agentless) | Employees stay on VPN; no disruption |
| 2. SaaS lift | Employee SaaS access (M365, Salesforce) moves to ZTNA | VPN remains for internal apps |
| 3. Internal apps | HTTP internal apps onboarded to ZTNA with app connectors | VPN for non-HTTP and OT |
| 4. Residual | Evaluate remaining VPN use cases individually | VPN retained where ZTNA can’t cover it |
What usually slows migration down
Applications that use non-standard ports, custom TCP protocols, or require network broadcast/multicast. The ZTNA product catalog matters here — some vendors handle SSH and RDP through browser-based proxies; others don’t. Map your application inventory before choosing a ZTNA vendor, not after. The sales demo will look fine for web apps. The friction shows up when you try to onboard the application that’s been running since 2009 and has no documentation.
9. Frequently Asked Questions
Is ZTNA replacing VPN completely?
Not in most enterprises. ZTNA replaces VPN for web-based application access well. It does not replace VPN for OT environments, infrastructure access over non-HTTP protocols, or any system where network-level connectivity is the explicit requirement. Large organizations typically end up running both — ZTNA for the majority of users, VPN for the teams with legitimate network access needs.
Can ZTNA work without an identity provider?
Technically yes, but not well. ZTNA’s entire access model depends on knowing exactly who the user is. Without an IdP (Azure AD, Okta, Ping), you lose the identity layer that makes per-app access decisions meaningful. Most ZTNA deployments integrate with an existing IdP as step one. If you don’t have one, that’s the first project.
Is WireGuard a ZTNA solution?
No. WireGuard is a fast, modern VPN protocol. It creates a network tunnel, same as IPsec or OpenVPN — just with less overhead and a smaller codebase. Tailscale and similar tools build on WireGuard and add access control that starts to look like ZTNA, but native WireGuard is network-level access, not application-level. The protocol is different from the architecture.
What are the main ZTNA vendors?
Zscaler Private Access (ZPA), Palo Alto Prisma Access, Netskope Private Access, Cloudflare Access, Cisco Duo Network Gateway, and Microsoft Entra Private Access are the enterprise-grade options most commonly deployed. Smaller organizations sometimes use Tailscale or Twingate, which have simpler setup but fewer policy controls. The right choice depends heavily on what IdP you’re using and whether you need agentless access.
Does ZTNA require an agent on every device?
No. Most enterprise ZTNA platforms offer both agent-based and agentless (browser proxy) modes. Agent-based gives continuous device posture checks — antivirus status, OS patch level, disk encryption. Agentless skips posture and works through a browser portal, which is the right choice for contractors on personal machines. Many organizations use agent-based for employees and agentless for third parties.
How does ZTNA handle applications that aren’t web-based?
Unevenly, and this is the honest answer most ZTNA vendors won’t lead with. Most ZTNA platforms handle HTTP/HTTPS applications well. For SSH and RDP, several vendors offer browser-based proxies or native client routing. For custom TCP/UDP applications, ZTNA coverage varies significantly by vendor — some handle it, most have gaps. If you have a significant number of non-web applications, get specific answers from vendors during evaluation, not general assurances.
The Short Version
| VPN | Network-level access. One authentication, wide blast radius. Still the right tool for OT, infra teams, and non-HTTP protocols. |
| ZTNA | Application-level access. Continuous verification, no lateral movement, invisible attack surface. The right tool for SaaS, web apps, contractors, and BYOD. |
| Reality | Most enterprises will run both for years. ZTNA wins on security architecture. VPN wins on protocol breadth. Neither is going away. |
