For more than two decades, VPN was the default answer to a simple question: how do remote users access corporate resources securely? The answer involved encrypted tunnels, network-level access, and perimeter-based trust. It worked well enough when most employees sat in offices and applications lived in on-premise data centers.
That world no longer exists. Distributed workforces, multi-cloud environments, and an escalating threat landscape have exposed fundamental limitations in the VPN model. In response, the industry has converged on a replacement: ZTNA (Zero Trust Network Access) — sometimes marketed as “Zero Trust VPN,” although that term is technically a contradiction. ZTNA does not extend VPN; it replaces the architectural assumptions VPN was built on.
This article provides a thorough comparison of traditional VPN and ZTNA, covering architecture, security trade-offs, vendor landscape, and practical migration guidance.
What Is a Traditional VPN?
A Virtual Private Network (VPN) creates an encrypted tunnel between a client device and a VPN gateway (concentrator) at the network perimeter. Once the tunnel is established and the user authenticates — typically via username/password, certificate, or MFA — the client receives a virtual IP address on the corporate network. From that point, the device is treated as if it were physically connected to the LAN.
The two dominant VPN protocols in enterprise environments are:
- IPsec — operates at the network layer (Layer 3), commonly used for site-to-site connections and remote access via IKEv2. Provides strong encryption but requires dedicated client software and can struggle with NAT traversal.
- SSL/TLS VPN — operates at the transport layer, accessible via browser or lightweight agent. Products like Cisco AnyConnect, Fortinet FortiClient, and Palo Alto GlobalProtect use this model. Easier to deploy than IPsec but still grants broad network access by default.
Both approaches share the same fundamental design: authenticate once at the perimeter, then gain access to the internal network.
The Problems with Traditional VPN
VPN was designed for a world where the network perimeter was the security boundary. Several structural weaknesses have become critical in modern environments.
Excessive implicit trust
Once a user establishes a VPN tunnel, they typically have access to entire network segments — far more than the specific applications they need. If an attacker compromises VPN credentials (through phishing, credential stuffing, or social engineering), they inherit this broad access. Every major ransomware campaign in recent years — from Colonial Pipeline to Change Healthcare — exploited this implicit trust model.
Lateral movement
VPN places the authenticated device on the network. From there, an attacker can scan for open ports, enumerate services, and move laterally to high-value targets. Network segmentation (VLANs, ACLs) can limit this, but maintaining granular network-level policies across thousands of users and hundreds of applications becomes operationally unsustainable.
Split tunneling dilemmas
Organizations face an uncomfortable choice. Full-tunnel VPN routes all traffic through the corporate network, adding latency and consuming bandwidth — particularly painful when users access SaaS applications that never need to touch the corporate network. Split tunneling improves performance by routing only corporate traffic through the tunnel, but it leaves the device simultaneously connected to the public internet and the corporate network, creating an attack vector that bypasses perimeter defenses entirely.
Scalability constraints
VPN concentrators are physical or virtual appliances with finite capacity. Each concurrent session consumes CPU, memory, and bandwidth at the concentrator. During the 2020 pandemic, organizations worldwide discovered that their VPN infrastructure could not handle many times the normal concurrent connection count. Scaling requires purchasing additional hardware, provisioning more bandwidth, and managing increasingly complex high-availability clusters.
No device posture awareness
Traditional VPN authenticates the user but does not evaluate the device. A compromised laptop with disabled endpoint protection, outdated patches, and active malware receives the same network access as a fully hardened corporate device — as long as the credentials are valid.
Poor visibility
VPN logs capture connection metadata (timestamps, source IPs, duration) but provide limited insight into what users actually access once connected. Application-level visibility requires separate tools (SIEM, NDR, CASB), and correlating network-layer VPN events with application-layer activity is a persistent operational challenge.
What Is ZTNA (Zero Trust Network Access)?
ZTNA is a security framework that provides access to specific applications — never to the underlying network — based on continuous verification of identity, device posture, and contextual signals. It implements the core Zero Trust principle: never trust, always verify.
Gartner coined the term “ZTNA” (originally as “Software-Defined Perimeter”) to describe a category of solutions that:
- Hide applications from the internet — unlike VPN concentrators that must listen on public IP addresses, ZTNA makes applications invisible to unauthorized users. There is nothing to scan, nothing to probe, nothing to exploit.
- Authenticate before connecting — the user must prove their identity and the device must pass posture checks before any network connection to the application is established. This inverts the VPN model, where the connection is established first and authentication happens second.
- Grant per-application access — each application has its own access policy. A user authorized for the HR portal is not automatically authorized for the engineering CI/CD pipeline, even if both applications run on the same server.
- Continuously evaluate trust — authentication is not a one-time event. ZTNA solutions reassess risk throughout the session, checking for changes in device posture, anomalous behavior, geographic impossibility, and other signals.
How ZTNA differs from “Zero Trust VPN”
The marketing term “Zero Trust VPN” conflates two incompatible architectures. VPN grants network access; Zero Trust denies network access by design. Some vendors use “Zero Trust VPN” to describe a VPN product with added access controls, but this is a band-aid over a fundamentally flawed model. True ZTNA eliminates the network-level access that defines VPN.
ZTNA Architecture
ZTNA solutions share a common architectural pattern built on three core components, though vendor implementations vary in detail.
The broker (trust broker / cloud gateway)
The broker is the central decision and relay point. It sits between users and applications, typically delivered as a cloud service. The broker:
- Receives connection requests from authenticated users
- Evaluates access policies against identity, device posture, and context
- Proxies or tunnels authorized connections to the target application
- Terminates unauthorized requests before they reach the application
Because the broker mediates all connections, applications never need to be directly exposed to the internet.
The connector (application connector / app connector)
Connectors are lightweight software agents deployed in the same network as the protected applications — whether that is an on-premise data center, a private cloud VPC, or a public cloud environment. Connectors:
- Establish outbound-only tunnels to the broker (no inbound firewall rules required)
- Relay authorized traffic from the broker to the target application
- Support both web-based and non-web (TCP/UDP) applications
- Can be deployed as containers, virtual machines, or lightweight processes
The outbound-only model is a significant security improvement over VPN concentrators, which must accept inbound connections from the internet.
The policy engine
The policy engine defines and enforces access rules. Policies typically combine:
- Identity attributes — user, group membership, role (from IdP integration)
- Device posture — OS version, patch level, endpoint protection status, disk encryption, screen lock
- Context — source IP, geographic location, time of day, risk score
- Application sensitivity — different applications can require different assurance levels
Policies are expressed declaratively (e.g., “Allow access to the finance application for users in the Finance group, on managed devices with current patches, from approved countries”) and evaluated in real time for every access request.
ZTNA vs VPN: Detailed Comparison
The following table summarizes the key architectural and operational differences.
| Dimension | Traditional VPN | ZTNA |
|---|---|---|
| Access model | Network-level access to entire segments | Per-application access only |
| Trust model | Implicit trust after authentication | Continuous verification, zero implicit trust |
| Attack surface | VPN concentrator exposed on public IP | No public-facing infrastructure; applications hidden |
| Lateral movement | Possible across accessible network segments | Eliminated — no network access granted |
| Device posture | Not evaluated (or bolt-on integration) | Native, continuous device health checks |
| Scalability | Hardware-bound (concentrator capacity) | Cloud-native, elastic scaling |
| Performance | Backhaul through central concentrator | Direct-to-application via nearest PoP |
| Split tunneling | Binary choice (full or split) | Not applicable — only app traffic is routed |
| Deployment | Inbound firewall rules, public IPs | Outbound-only connectors, no inbound rules |
| Visibility | Connection metadata only | Per-application, per-session audit trail |
| User experience | VPN client connect/disconnect workflow | Transparent, always-on, per-app access |
| Legacy app support | Native (any IP-accessible app) | Requires connector; some protocols need agent |
Where VPN still has an edge
It is worth noting scenarios where VPN retains practical advantages:
- Full network access is actually needed — network administrators performing packet captures, SNMP polling, or managing infrastructure across entire subnets genuinely need Layer 3 access. ZTNA’s per-application model does not serve this use case well.
- Extremely latency-sensitive protocols — some real-time protocols (VoIP, video conferencing on internal platforms) may perform better over a direct IPsec tunnel than through a ZTNA broker, depending on the vendor’s architecture.
- Regulatory requirements — certain compliance frameworks still explicitly reference VPN as a required control. While most are updating to accept ZTNA, some legacy mandates persist.
ZTNA Vendor Landscape
The ZTNA market has matured rapidly. Below are the major platforms and their architectural approaches.
Zscaler Private Access (ZPA)
Zscaler’s ZPA is the market leader in standalone ZTNA. It uses a broker-connector model where application connectors establish outbound connections to the Zscaler cloud. ZPA does not create a virtual network — traffic is proxied at the application level. It integrates tightly with Zscaler Internet Access (ZIA) as part of the Zscaler Zero Trust Exchange platform.
Key differentiators: largest cloud footprint (150+ data centers), App Connector supports both web and non-web applications, integrated deception technology (honeypots for lateral movement detection).
Cloudflare Access (part of Cloudflare One)
Cloudflare Access leverages Cloudflare’s global edge network (300+ cities) to provide ZTNA with exceptionally low latency. It supports clientless access for web applications (via browser-based identity verification) and agent-based access for non-web applications via the Cloudflare WARP client. The Cloudflare Tunnel connector (formerly Argo Tunnel) creates encrypted outbound connections from application environments.
Key differentiators: free tier for up to 50 users, integrated with Cloudflare’s CDN and DDoS protection, strong developer experience, Gateway DNS/HTTP filtering included.
Palo Alto Prisma Access
Prisma Access provides ZTNA as part of a broader SASE platform. It supports both agent-based and agentless access modes. The platform leverages Palo Alto’s extensive security stack, including threat prevention, URL filtering, and WildFire sandboxing, applied to ZTNA sessions.
Key differentiators: deep integration with Palo Alto’s NGFW ecosystem, autonomous digital experience management (ADEM) for troubleshooting, strong compliance reporting for regulated industries.
Fortinet ZTNA (part of FortiSASE)
Fortinet’s approach is distinct in that ZTNA capabilities are built into FortiGate firewalls and FortiClient. Organizations already running FortiGate can enable ZTNA access proxies without deploying additional infrastructure. FortiSASE extends this to a cloud-delivered model.
Key differentiators: leverage existing FortiGate investment, ZTNA tags for dynamic policy enforcement, integrated SD-WAN, competitive pricing for Fortinet shops.
Other notable vendors
- Netskope Private Access — strong data loss prevention (DLP) integration, inline threat protection
- Cisco Secure Access (formerly Duo + Umbrella) — integration with Cisco’s broad networking portfolio
- Akamai Enterprise Application Access — leverages Akamai’s edge platform, strong for web applications
- Twingate — developer-friendly, peer-to-peer architecture that avoids cloud relay for performance
- Tailscale — WireGuard-based mesh networking with Zero Trust identity verification, popular with engineering teams
SASE and SSE: The Bigger Picture
ZTNA does not exist in isolation. It is a core component of two broader architectural frameworks.
SASE (Secure Access Service Edge)
Defined by Gartner in 2019, SASE converges networking and security into a unified, cloud-delivered service. The networking side includes SD-WAN and WAN optimization. The security side — called SSE (Security Service Edge) — includes:
- ZTNA — secure application access
- SWG (Secure Web Gateway) — web traffic filtering and threat protection
- CASB (Cloud Access Security Broker) — visibility and control over SaaS applications
- FWaaS (Firewall as a Service) — cloud-delivered firewall capabilities
SSE (Security Service Edge)
SSE is the security-only subset of SASE, without the SD-WAN component. Organizations that do not need to replace their WAN infrastructure can adopt SSE to gain ZTNA, SWG, and CASB in a unified platform.
The practical implication is that ZTNA procurement rarely happens in isolation. Most organizations evaluate ZTNA as part of a broader SSE or SASE initiative, selecting a platform that addresses multiple security requirements simultaneously.
Migrating from VPN to ZTNA
Replacing VPN with ZTNA is not a weekend project. It requires methodical planning, stakeholder alignment, and phased execution. The following framework applies to most organizations.
Phase 1: Discovery and assessment (4-6 weeks)
Before deploying anything, you need a complete inventory of what VPN currently protects.
Application inventory. Catalog every application accessed via VPN. For each, document the protocol (HTTPS, SSH, RDP, proprietary), port, user population, sensitivity classification, and current access policy. Many organizations are surprised to discover VPN is being used for applications they did not know existed.
User population analysis. Segment users by access patterns: employees, contractors, partners, M&A integrations. Each group will likely need different ZTNA policies.
Device landscape. Identify managed vs. unmanaged devices, operating systems, and existing endpoint protection coverage. This directly impacts whether you can deploy ZTNA agents or need clientless access.
Network dependencies. Some workflows may depend on network-level access (broadcast, multicast, Layer 2 adjacency). These need special handling or temporary VPN exceptions.
Phase 2: Pilot deployment (4-8 weeks)
Select a subset of applications and users for the initial ZTNA deployment. Good pilot candidates are:
- Web-based applications (simplest to proxy)
- A user group that is technically sophisticated and tolerant of change (e.g., IT staff)
- Applications that are well-documented and have clear access policies
Deploy connectors, configure policies, integrate with your identity provider, and run the pilot group through ZTNA while keeping VPN available as a fallback. Measure user experience, troubleshoot edge cases, and refine policies.
Phase 3: Phased rollout (8-16 weeks)
Expand ZTNA coverage application by application and user group by user group. Prioritize based on:
- Security risk — high-sensitivity applications benefit most from ZTNA’s granular controls
- User volume — migrating large user populations reduces VPN concentrator load, proving ROI
- Technical complexity — save legacy applications with unusual protocol requirements for later phases
During this phase, run VPN and ZTNA in parallel. Users who have been migrated use ZTNA; others continue with VPN.
Phase 4: VPN decommission
Once all applications and user groups are covered by ZTNA (or have approved exceptions), begin decommissioning VPN infrastructure. This means:
- Removing VPN client software from endpoints
- Decommissioning VPN concentrators
- Updating firewall rules to remove inbound VPN access
- Archiving VPN configurations and logs for compliance retention
- Updating documentation, runbooks, and incident response procedures
Maintain a documented exception process for the rare cases where VPN is still required (e.g., network administration tasks).
Use Cases
ZTNA’s advantages are most pronounced in specific scenarios that have become increasingly common.
Remote and hybrid work
The most obvious use case. ZTNA provides consistent, secure access regardless of where users work — home, office, airport, or co-working space. Unlike VPN, there is no performance penalty for remote users, because traffic goes through the nearest ZTNA point of presence rather than backhauling through a central concentrator. The always-on, transparent nature of ZTNA eliminates the “connect to VPN before working” friction that users routinely circumvent.
Mergers and acquisitions
M&A integration historically required months of network integration: extending VPN access, establishing site-to-site tunnels, merging Active Directory forests. ZTNA simplifies this dramatically. Deploy connectors in the acquired company’s environment, configure application-specific policies, and grant access to the acquiring company’s users — all without any network-level integration. This can reduce Day 1 access timelines from months to days.
Third-party and contractor access
Contractors and partners need access to specific applications, not the corporate network. ZTNA’s per-application model is a natural fit. Clientless ZTNA (browser-based access) is particularly valuable here, as it avoids installing agents on devices the organization does not manage. Access can be time-bounded, logged at the application level, and revoked instantly when the engagement ends.
Multi-cloud and hybrid environments
Organizations with applications spread across on-premise data centers, AWS, Azure, GCP, and SaaS platforms cannot draw a meaningful network perimeter. ZTNA connectors deploy wherever the applications are, providing a consistent access and policy layer across all environments. Users do not need to know (or care) where an application is hosted.
Compliance-driven environments
Regulations like PCI DSS 4.0, HIPAA, and NIS2 increasingly require least-privilege access, continuous monitoring, and granular audit trails — all of which ZTNA delivers natively. The per-application access model maps cleanly to compliance requirements, and ZTNA audit logs provide the granularity that auditors expect.
Best Practices for ZTNA Deployment
Drawing from real-world deployments, the following practices consistently improve outcomes.
Start with identity. ZTNA is only as strong as your identity infrastructure. Before deploying ZTNA, ensure your identity provider (IdP) is robust: enforce MFA for all users, maintain accurate group memberships, implement automated provisioning/deprovisioning (SCIM), and integrate with HR systems for timely offboarding.
Define policies before deploying technology. Write access policies in plain language before translating them into vendor-specific configurations. “Finance team members on managed Windows devices with current patches can access the ERP system during business hours from approved countries” is clearer than starting with firewall-style rules.
Integrate device posture checks from day one. ZTNA without device posture is only half the equation. Require minimum OS versions, active endpoint protection, disk encryption, and screen lock. Gradually tighten posture requirements as your fleet matures.
Use the principle of least privilege aggressively. Grant access to the minimum set of applications each user or group needs. Resist the temptation to create broad policies that replicate VPN-style access. Review and prune access quarterly.
Monitor and log everything. ZTNA provides rich per-session, per-application telemetry. Feed this data into your SIEM, establish baselines, and alert on anomalies. The visibility improvement over VPN is substantial — use it.
Plan for exceptions. Some applications will not work with ZTNA initially. Thick client applications with unusual port usage, protocols that require broadcast, or legacy systems that cannot tolerate proxy-based access may need temporary VPN exceptions. Document these exceptions with remediation timelines.
Test failure modes. What happens when the ZTNA broker is unreachable? When a connector goes offline? When the IdP is down? Test these scenarios before they occur in production and ensure your architecture provides adequate redundancy and graceful degradation.
Communicate with users. ZTNA changes the user experience — usually for the better, but change still requires communication. Explain what is changing, why, and what users should expect. Provide clear support channels for the transition period.
The Road Ahead
The trajectory is clear: ZTNA is replacing VPN as the standard for secure remote access, and the transition is accelerating. A growing share of new remote access deployments uses ZTNA rather than VPN.
The technology continues to evolve. ZTNA 2.0 — a term popularized by Palo Alto Networks — adds inline threat inspection, DLP, and continuous trust verification to the ZTNA model. Universal ZTNA extends the same per-application access controls to users inside the office, not just remote workers, eliminating the architectural inconsistency of applying Zero Trust only to remote access.
VPN will not disappear overnight. Legacy applications, specific regulatory requirements, and network administration use cases will sustain VPN deployments for years. But for the vast majority of remote access scenarios — users accessing applications — ZTNA provides a fundamentally more secure, more scalable, and more user-friendly architecture.
The question is no longer whether to migrate from VPN to ZTNA, but when and how. Organizations that begin planning now will be better positioned to reduce their attack surface, improve user experience, and meet the security demands of a workforce that is never going back to the office full-time.
