ZTNA vs VPN: Zero Trust Replaces VPN

ZTNA brokers per-app connections through identity verification — users see the app, never the network. VPN drops users onto a flat network segment where compromised credentials give attackers everything. ZTNA delivers sub-second connections vs 10-15 second VPN handshakes. Start by migrating 3-5 high-visibility internal web apps, then expand to critical systems over 6-12 months.

Zero Trust Network AccessZero Trust Network Access (ZTNA) is a security architecture that brokers authenticated, per-application connections between users and specific applications based on verified identity and real-time device posture, without ever placing the user on the corporate network. VPN (Virtual Private Network) is a legacy remote access technology that creates an encrypted tunnel granting authenticated users broad Layer 3 network access to an entire subnet or network segment. The fundamental difference is access scope: ZTNA gives users access to specific applications they are authorized for, while VPN gives users access to the network where applications reside. This distinction is why VPN is the number one initial access vector for ransomware in enterprise environments and why ZTNA is replacing it across every industry.

Head-to-head comparison

Why VPN is a security liability

The architectural flaw in VPN is not the encryption — IPsec and SSL tunnels are cryptographically sound. The flaw is what happens after authentication. A VPN places the authenticated user onto the corporate network as if they were physically in the office. From there, the user's device can reach any system on the accessible subnet: file servers, domain controllers, database servers, print servers, IoT devices, and every other system that was never designed to be accessed remotely. Ransomware operators know this and specifically target VPN credentials through phishing, credential stuffing, and brute force attacks against exposed VPN portals.

The attack chain is consistent: compromise VPN credentials (often purchased on initial access broker marketplaces for $50 to $500), establish a VPN session, scan the internal network using tools like Nmap or Advanced IP Scanner, move laterally to a domain controller using pass-the-hash or Kerberos delegation attacks, deploy ransomware to every reachable system, and exfiltrate data for double-extortion leverage. Every step after the initial VPN connection relies on the broad network access that VPN inherently provides. ZTNA breaks this chain at step two — there is no network to scan because the user only has a micro-tunnel to a specific application.

Beyond ransomware, VPN concentrators themselves are high-value targets. Ivanti Pulse Secure, Fortinet FortiGate SSL-VPN, Cisco AnyConnect, and Palo Alto GlobalProtect have all had critical CVEs exploited in the wild in the past three years. VPN concentrators must have public-facing IP addresses and open ports by design, creating a permanent attack surface. ZTNA connectors, by contrast, initiate outbound-only connections to the broker — there are no inbound ports, no public IP, and no attack surface to exploit.

The migration path from VPN to ZTNA

Phase 1: Inventory and classify applications (Weeks 1-4)

Before touching any technology, catalog every application currently accessed through VPN. Classify each application by protocol (HTTP/HTTPS, SSH, RDP, thick-client proprietary protocols), user population (how many users access it and how frequently), criticality (what breaks if access is interrupted), and ZTNA compatibility (can it work through a reverse proxy or does it require Layer 3 network access). This inventory is the foundation of your migration plan. In every VPN-to-ZTNA migration I have managed, 70-80% of applications are web-based and migrate trivially to ZTNA. The remaining 20-30% are thick-client or proprietary-protocol applications that require more planning.

Phase 2: Deploy ZTNA for web applications (Weeks 4-8)

Start with 3 to 5 internal web applications that have broad user bases and low risk: intranet portals, HR self-service, internal wikis, ticketing systems. Deploy ZTNA connectors in the same network segment as these applications, configure identity provider integration (Okta, Microsoft Entra ID, Ping), define posture policies (require EDR running, OS patched within 30 days), and onboard a pilot group of 50 to 100 users. The goal of this phase is not to replace VPN — it is to demonstrate that ZTNA works, that the user experience is superior, and that the security posture is stronger. When users see sub-second access without launching a VPN client, you build the political capital needed for later phases.

Phase 3: Expand to business-critical applications (Weeks 8-16)

Onboard ERP systems, source code repositories, CI/CD pipelines, database management interfaces, and production admin consoles. This phase is where you define tiered posture policies: production admin access requires EDR active, disk encryption enabled, OS patched within 14 days, and MFA completed within the last hour. General business app access can be more permissive. Document your posture tiers, get sign-off from application owners, and expand the user base department by department. Run VPN and ZTNA in parallel during this phase — users access ZTNA-enabled applications through ZTNA and continue using VPN for everything else.

Phase 4: Address legacy applications (Weeks 16-24)

This is the hard phase. Legacy thick-client applications — proprietary ERP clients, CAD tools accessing license servers, mainframe terminal emulators, and applications with hardcoded IP-based authentication — may not work through ZTNA reverse proxy. You have three options for each: modernize the application to use web-based access (preferred but expensive), use a ZTNA vendor that supports TCP/UDP tunneling for non-HTTP protocols (Cisco, Palo Alto, and Zscaler all offer this), or maintain a restricted VPN as a fallback for the small number of applications that genuinely cannot be proxied. The key is to make VPN the exception, not the rule. Track exactly which applications still require VPN and set modernization timelines for each.

Phase 5: VPN decommission (Weeks 24-36)

Restrict VPN access to only the legacy applications identified in Phase 4. Remove all other applications from VPN split-tunnel ACLs so that users cannot bypass ZTNA by connecting to VPN. Set a decommission date for the VPN concentrator and communicate it broadly. Monitor VPN connection logs weekly — if usage drops to near zero, you are ready to decommission. If usage remains, investigate which applications or users are still dependent and address them individually. Some organizations maintain a minimal VPN capability for break-glass disaster recovery access — this is reasonable as long as it is tightly restricted, heavily monitored, and requires elevated authentication.

What breaks during migration

Routing conflicts between VPN and ZTNA agents are the number one source of helpdesk tickets during migration. Both agents want to control the routing table, DNS resolution, and proxy settings. Running both simultaneously creates intermittent connectivity issues that are nearly impossible to reproduce or debug. The cleanest approach is to deploy a vendor that offers a unified client handling both VPN and ZTNA (Cisco Secure Client does this well), or to sequence the uninstall of the VPN client immediately before the install of the ZTNA agent using your endpoint management platform.

ZTNA 1.0 vs ZTNA 2.0

Not all ZTNA is equal. ZTNA 1.0 implementations perform a single identity and posture check at connection time, then create an allow-all tunnel to the application for the session duration. This is better than VPN but still leaves gaps: a device that becomes compromised after connection will not be detected, and data exfiltration through the authorized tunnel is invisible. ZTNA 2.0, pioneered by Palo Alto Networks, adds continuous trust verification (posture re-checked every 5 to 10 seconds), post-connect threat prevention (IPS and malware scanning on tunnel traffic), and inline DLP (detecting and blocking data exfiltration through authorized connections). When evaluating ZTNA vendors, ask explicitly: do you perform post-connect inspection? The answer immediately separates mature implementations from VPN-rebranding exercises.

Cost and ROI

ZTNA typically costs $3 to $8 per user per month as part of an SSE bundle, compared to VPN concentrator hardware ($20,000 to $100,000 per appliance), VPN client licensing ($2 to $5 per user per month), and the operational cost of managing concentrator capacity, patching VPN software against CVEs, and troubleshooting connectivity issues. The hard ROI comes from eliminating VPN hardware refresh cycles, reducing remote access helpdesk tickets by 40 to 60%, and avoiding the breach cost associated with VPN credential compromise. The soft ROI comes from user experience improvement — sub-second, always-on access versus multi-second VPN handshakes and manual connect/disconnect.

Sources & further reading

• NIST SP 800-207, "Zero Trust Architecture" — nist.gov/publications/zero-trust-architecture
• CISA, "Zero Trust Maturity Model" — cisa.gov/zero-trust-maturity-model
• Gartner, "Market Guide for Zero Trust Network AccessZero Trust Network Access" — gartner.com/reviews/market/zero-trust-network-access
• Palo Alto Networks, "What Is ZTNA 2.0?" — paloaltonetworks.com/cyberpedia/what-is-ztna-2-0
• SANS Institute, "VPN-Less Remote Access with Zero Trust" — sans.org/white-papers/zero-trust-network-access
• Dark Reading, "The End of VPN: Why Enterprises Are Moving to ZTNA" — darkreading.com/endpoint-security

Related on sase.cloud

One email per publish. Unsubscribe anytime.