VPNs were built for a world where your network had a perimeter. That world is gone.
Remote teams, cloud workloads, third-party contractors, and BYOD policies have turned the traditional network inside out. VPNs respond to this by doing what they've always done: punching a hole in your firewall and hoping for the best. Zero Trust Network Access (ZTNA) takes the opposite approach. No implicit trust. No network-level access. Every connection authenticated and authorized individually.
This isn't a philosophical difference. It's an architectural one, and it changes how traffic flows, how policies are enforced, and how breaches propagate or don't.
How VPNs Actually Work
A VPN creates an encrypted tunnel between a user's device and a VPN concentrator sitting at the edge of your network. Once that tunnel is established, the user is on your network. They can reach anything the network allows.
Traffic flow:
User device → encrypted tunnel → VPN concentrator → corporate network (full access)
The VPN authenticates the user once at connection time. After that, network-level access is granted broadly. Segmentation, if it exists at all, is handled by firewalls and ACLs downstream. Most organizations don't enforce granular segmentation behind the VPN because it's operationally painful.
This creates two problems that matter:
Lateral movement. A compromised device or stolen credential gives an attacker the same broad access the VPN grants the user. This is how most ransomware spreads. The attacker doesn't need to exploit anything else. The VPN already gave them the network.
Backhauling. Remote users connecting to cloud applications still route through the VPN concentrator at the data center. Traffic goes from the user to the data center, then back out to the cloud. This adds latency, burns bandwidth, and creates a bottleneck that degrades under load. Split tunneling helps, but it also routes some traffic outside your security stack entirely.
How ZTNA Works
ZTNA flips the model. Instead of putting users on the network, it connects them to specific applications. The network itself is never exposed.
Traffic flow:
User device → identity verification → policy check → authorized connection to specific application only
No tunnel to the network. No implicit trust. The user can reach exactly the applications they're authorized for, nothing else. If an attacker compromises a credential, they get access to one application, not the entire network.
ZTNA evaluates trust continuously. Device posture (is the OS patched? is the endpoint managed? is the disk encrypted?), user identity, location, time of day, and behavioral signals all factor into the access decision. Access can be revoked mid-session if conditions change.
The key architectural differences:
VPNZTNAAccess modelNetwork-level (connect to the network, access everything)Application-level (connect to specific apps only)AuthenticationOnce, at tunnel setupContinuous, per-session, per-applicationLateral movement riskHigh. Attacker inherits full network access.Minimal. No network access granted.Cloud trafficBackhauled through data center, or split-tunneled outside security controlsDirect-to-app. No backhaul.VisibilityLimited. VPN logs show tunnel up/down, not application-level activity.Granular. Every application access is logged individually.Third-party accessRequires VPN client on unmanaged devices (painful)Clientless options available. No network access needed.ScalabilityVPN concentrators have throughput limits. Scaling means more hardware.Cloud-native. Scales with demand.
When VPNs Fail
VPNs don't just underperform. They actively create the conditions for breaches.
The Colonial Pipeline attack (2021) started with a compromised VPN credential. The attackers used it to access the corporate network and deploy ransomware. A single stolen password was enough because the VPN granted broad network access with no additional verification.
This pattern repeats constantly. Fortinet, Pulse Secure, and Cisco VPN appliances have had critical vulnerabilities (CVE-2023-27997, CVE-2024-21887, CVE-2023-20269) that gave attackers unauthenticated remote access. VPN appliances are high-value targets specifically because they provide network-level access. Compromising one is equivalent to being inside the perimeter.
65% of enterprises are planning to replace their VPNs with ZTNA solutions, according to Gartner. The shift isn't theoretical. It's happening because VPNs are the attack surface.
What to Look for in a ZTNA Solution
Not all ZTNA implementations are the same. The market has converged around two architectures:
Cloud-proxied ZTNA routes all traffic through the vendor's cloud. Zscaler, Cloudflare Access, and Netskope work this way. Your data transits their infrastructure. This is fine for many organizations, but it introduces a dependency. Your security posture is now tied to a third party's infrastructure, availability, and data handling practices. For regulated industries (defense, aerospace, finance), this can be a compliance problem.
Direct-routed ZTNA connects users to applications without routing through a third-party cloud. The control plane may be cloud-hosted, but data stays on your infrastructure. This preserves data sovereignty and eliminates the performance penalty of proxying through an intermediary.
Real-World Cost Comparison
The financial argument for ZTNA often gets overshadowed by security discussion. But the numbers matter. VPN costs are deceptively high when you account for the full lifecycle.
VPN total cost of ownership. A typical enterprise VPN deployment includes Cisco ASA or Fortinet FortiGate appliances ($15,000 to $50,000 per concentrator, depending on throughput). Organizations deploying high availability setups need multiple units. Support and licensing run $3,000 to $8,000 per year per concentrator. VPN hardware has a 5-year refresh cycle, so that's $18,000 to $58,000 every five years per unit. A redundant pair across two data centers costs $36,000 to $116,000 for the refresh cycle alone.
Add operations overhead. VPN concentrators need dedicated staff to tune, troubleshoot, and maintain. That's 0.5 to 1 FTE per 1,000 users, at a fully loaded cost of $80,000 to $150,000 per person per year. Scaling to 5,000 remote users requires 2.5 to 5 FTE.
VPN client distribution and support also scales with headcount. IT departments spend time deploying, updating, and troubleshooting VPN clients. Every OS version change is a potential compatibility issue. BYOD devices require vendor-specific client support. This operational cost is real and rarely accounted for in budget decisions.
Total VPN cost for a mid-sized organization with 1,000 remote users: $250,000 to $400,000 per year when you include hardware, licensing, and labor.
ZTNA cost structure. Most ZTNA solutions use per-user, per-month pricing. Cloudflare Access charges roughly $3 to $7 per user per month, depending on feature tier and volume. Zscaler's pricing is similar for most enterprise tiers. A cloud-based ZTNA for 1,000 users costs $36,000 to $84,000 per year. No hardware refresh cycles. No concentrators to maintain.
Operational overhead drops significantly. ZTNA platforms provide cloud-based management, policy updates, and device posture checking. The vendor handles infrastructure scaling, redundancy, and monitoring. Your team manages policy, not appliances. For 1,000 users, you need 0.1 to 0.25 FTE instead of 0.5 to 1 FTE.
Client installation is simpler. Many ZTNA solutions offer agentless options (browser-based access) for non-critical applications. When agents are needed, they're lightweight and managed through existing MDM platforms.
Total ZTNA cost for the same 1,000 user deployment: $60,000 to $150,000 per year, including per-user licensing and reduced operational labor.
The break-even point. For organizations with more than 300 remote users, ZTNA is cheaper. For organizations with fewer than 300, a cloud-based ZTNA is still cheaper once you factor in the operational burden of VPN maintenance. The only scenario where traditional VPN costs less is a small organization with minimal growth expectations and highly automated infrastructure.
Additionally, ZTNA enables better resource allocation. Teams currently maintaining VPN appliances can shift to higher-value work. Security teams get better visibility into application usage instead of just tunnel metadata. These secondary cost benefits are harder to quantify but add up in practice.
Compliance and Audit Implications
VPN logging is tunnel-level. It shows when users connect and disconnect. It does not show what they accessed, what commands they ran, or what data they touched. This creates a massive audit gap.
For SOC 2, ISO 27001, and PCI DSS compliance, you must prove that access to sensitive systems was authorized and that access requests were reviewed. A VPN log that shows "user X connected at 2:30 PM" satisfies the technical requirement. It does not satisfy the control. You have to manually cross-reference user credentials, access requests, and timestamps to build an audit trail.
ZTNA inverts this. Every application access is logged individually. The audit trail shows: user identity, timestamp, resource accessed, policy decision (approved/denied), and device posture at time of access. For applications handling PII or financial data, you have a complete record.
Example scenario. A compliance auditor asks: "Show me who accessed the payroll database on March 5th, what they did, and whether their access was authorized."
With VPN: You provide a VPN log showing user@company.com connected at 9:15 AM. You then manually check access request records, approval emails, and application logs to prove authorization. The process takes 2 to 4 hours per user query.
With ZTNA: You provide a single log entry showing user@company.com accessed payroll.app at 9:15 AM, policy approved based on role and device posture requirements, device encryption verified, EDR status checked. The entire trail is in one place. The process takes 5 minutes per query.
This matters for breach investigation too. When a breach occurs, law enforcement or regulators will ask: "What could the compromised account access?" With a VPN, the answer is "our entire network." With ZTNA, the answer is specific: "Salesforce, Jira, and the finance portal based on assigned policies."
ZTNA also enables fine-grained audit controls. You can log every SSH session to a server, every database query, every file transfer. This is possible without ZTNA, but it requires application-level logging. ZTNA makes it the default, not an afterthought.
For regulated industries, ZTNA dramatically simplifies compliance. Audit teams don't have to reconstruct access trails from multiple sources. The policy enforcement and logging are inherently aligned. This reduces the risk of non-compliance and speeds up audit cycles.
The Migration Path
Replacing a VPN with ZTNA doesn't have to be a forklift upgrade. Most organizations run them in parallel during migration. The timeline varies from 6 to 18 months depending on complexity.
Phase 1: Identify high-risk applications. Start with applications that handle sensitive data, are accessed by third parties, or are frequent targets. These typically represent 10 to 20% of your application inventory but carry 60 to 80% of the risk. Examples: identity management systems, financial applications, customer databases, code repositories, infrastructure access tools. Move these to ZTNA first. The business case is strongest here because security and operational benefits are immediate.
Parallel approach: Leave the VPN running during this phase. Users can access non-critical applications through the VPN while using ZTNA for sensitive resources. This eliminates the need for a hard cutover date.
Phase 2: Onboard remote users. Remote and hybrid workers benefit most from ZTNA because it eliminates backhaul latency and provides better security posture verification. They're also the easiest to migrate because they're accustomed to agent-based access management. By this phase, you have experience deploying ZTNA clients and managing policy. Roll out to remote workers in batches based on geography or department.
Timeline: 2 to 3 months for this phase. Prioritize contractors and vendors first. They often have less restrictive security controls, making the case for application-level access stronger. Once contractors can access only what they need through ZTNA, the security improvement is obvious.
Phase 3: Extend to on-premises users. ZTNA isn't just for remote access. On-premises users benefit from the same application-level access controls and continuous verification. This phase is primarily about policy convergence. Your on-premises users may have historically had broader network access through physical connectivity. Migrating them to ZTNA means defining what applications they actually need and restricting access accordingly.
This is where operational discipline matters. Some teams will resist because they're accustomed to broad network access. Work with department heads to define baseline access policies. Start with read-only access to shared resources, then expand to applications where clear business cases exist.
Timeline: 3 to 6 months. This is the longest phase because it involves the most users and the most policy definition work.
Phase 4: Decommission VPN. Once all applications and user groups are migrated, shut down the VPN concentrators. Reduce your attack surface to zero exposed network entry points. Before decommissioning, run a parallel access mode for 2 to 4 weeks. Monitor failed access attempts and adjust ZTNA policies to catch any applications or workflows you missed.
When you decommission, turn off the VPN appliances completely. Don't leave them in standby. They represent risk. Sell the hardware (it has reasonable resale value), retire the licenses, and reallocate the server rack space and power.
Timeline: 1 month for this phase.
Operational checkpoints. Throughout migration, monitor these metrics to track progress and catch issues:
Common pitfalls to avoid. VPN migration projects often stumble on a few specific issues:
Underestimating application discovery. Many organizations don't have a complete inventory of applications and their dependencies. Someone always needs access to an app no one expected. Start application discovery 2 to 3 months before Phase 1 begins. Use network monitoring to identify all applications accessed through the VPN.
Policy definition by committee. Don't let every team negotiate their own access policy. Define baseline policies at the department level, then make exceptions case-by-case. This prevents policy sprawl and keeps migration moving.
Skipping device posture checks. Some organizations deploy ZTNA with minimal device posture requirements to simplify migration. This undermines the security benefit. Enforce encryption, patch levels, and EDR enrollment from the start. Users adapt quickly when they understand why requirements exist.
Not retiring the VPN. Many organizations leave legacy VPNs running indefinitely "just in case." Every day the VPN runs is a day the attack surface remains. Set a hard decommission date. Plan for it. Stick to it.
Bottom Line
VPNs solved a 1990s problem: connecting remote users to a corporate network. The problem has changed. Users are everywhere. Applications are everywhere. Putting anyone on the network is a liability.
ZTNA eliminates the concept of network-level access entirely. Every connection is verified. Every application is individually authorized. Lateral movement becomes structurally impossible, not just policy-dependent.
