Virtual Private Networks have served as the default remote access solution for enterprise networks for over two decades. VPN technology is mature, widely understood, and deeply embedded in enterprise procurement cycles, vendor relationships, and IT operational muscle memory. But the security architecture underpinning most VPN deployments reflects assumptions about how organizations work that have not held for years — assumptions about network perimeters, trusted devices, and the relationship between network location and trustworthiness.
Zero Trust Network Access (ZTNA) has emerged as the credible architectural replacement. Understanding why requires an honest technical examination of what VPNs actually do, where they fail, and how ZTNA addresses those failures. This post is not a vendor marketing document — it is a practitioner's comparison written for network engineers and security architects who need to make a real decision.
How Traditional VPNs Work — and Where They Break
A traditional IPSec or SSL VPN establishes an encrypted tunnel between a remote endpoint and a VPN concentrator at the network edge. Once the tunnel is established, the user is granted network-level access — typically to a defined IP range or VLAN, sometimes to the entire internal network. The VPN authenticates the connection at establishment time, usually with credentials and optionally a second factor. After that initial authentication, trust is implicit and persistent for the duration of the session.
This model has four fundamental security problems:
- Lateral movement enablement: Once inside the VPN tunnel, a user or attacker has direct network-layer access to every host in the permitted range. There is no application-level policy, no continuous verification, and no segmentation between what the user needs and everything else that happens to be reachable from the same subnet. A compromised VPN credential grants an attacker the same lateral movement opportunities as a compromised internal workstation.
- Broad attack surface exposure: VPN concentrators must be publicly accessible. They are regularly discovered by attackers through Shodan queries and certificate transparency logs. Critical vulnerabilities in VPN concentrators — including CVEs in Pulse Secure, Fortinet FortiOS, Citrix ADC, and Cisco ASA — have been mass-exploited in recent years precisely because they represent high-value, publicly accessible targets.
- No device posture enforcement: Most VPN deployments authenticate the user but not the device. A contractor accessing the VPN from an unmanaged personal laptop with no endpoint protection and an operating system three years out of date presents an identical security posture to a fully managed corporate device. The VPN cannot distinguish between them.
- Implicit trust persistence: VPN sessions establish trust at connection time and maintain it. An attacker who compromises a valid session token — through credential theft, session hijacking, or exploitation of split-tunnel configurations — retains that trust for the duration of the session without re-authentication or posture re-evaluation.
ZTNA Architecture: Verify Everything, Trust Nothing
Zero Trust Network Access follows a fundamentally different model. Rather than granting network-level access through a tunnel, ZTNA mediates access at the application layer. The access decision considers four dimensions before permitting any connection:
Identity Verification
The user must authenticate against a modern identity provider — Microsoft Entra ID, Okta, Ping Identity — with strong MFA. Not just any MFA: ZTNA implementations increasingly require phishing-resistant MFA (FIDO2, passkeys) for high-sensitivity applications. The identity context is passed to the access policy engine as a trust signal.
Device Posture Assessment
The connecting device is evaluated against a defined security baseline before access is granted. Device posture checks typically include: OS patch level, endpoint detection and response (EDR) status, disk encryption state, firewall status, and whether the device is managed (enrolled in MDM). Devices that fail posture checks are denied access or routed to a remediation portal. This is fundamentally different from VPN, where device health is invisible to the access policy.
Context Evaluation
Access decisions incorporate contextual signals: time of day, geographic location, network type, behavioral risk score. A user authenticating from an expected location during business hours on a trusted network presents a different context than the same user authenticating at 3 AM from a country they have never accessed before.
Application-Scoped Access
The user is granted access to a specific application or set of applications — not to the network segment where that application lives. The ZTNA broker proxies the connection so the user never has direct IP-level access to the application server. This eliminates lateral movement entirely: even if a ZTNA session is compromised, the attacker cannot pivot to adjacent systems because there is no network access to pivot through.
Major ZTNA Vendors: Technical Differentiation
Zscaler Private Access (ZPA)
ZPA routes traffic through Zscaler's global cloud, connecting users to applications via app connectors deployed in the application environment. There is no inbound firewall rule required — app connectors initiate outbound-only connections to the Zscaler cloud. Applications are never directly exposed to the internet. ZPA integrates deeply with Okta and Entra ID for identity, and supports application segmentation down to individual application ports. The primary limitation is latency for applications where the Zscaler PoP nearest to the user is geographically distant from the app connector.
Cloudflare Access
Cloudflare Access operates on the same brokered model, leveraging Cloudflare's extensive PoP network (300+ locations globally) for latency minimization. Access uses Cloudflare Tunnel for application connectivity, eliminating exposed IP addresses. The policy engine supports rich context evaluation, browser isolation for unmanaged devices, and deep integration with the broader Cloudflare security stack. For NYC financial services firms already using Cloudflare for DDoS and WAF, the integration surface makes Access a natural extension.
Palo Alto Prisma Access
Prisma Access provides ZTNA within a broader SASE (Secure Access Service Edge) architecture. It combines ZTNA with cloud-delivered SWG, CASB, and FWaaS into a single platform. For organizations seeking to consolidate their security stack, Prisma Access offers compelling integration, but the full SASE deployment carries higher complexity and cost than point ZTNA solutions. Prisma integrates with the broader Palo Alto ecosystem including Cortex XDR for device posture evaluation.
Migration Path: VPN to ZTNA
A phased migration reduces operational risk. The recommended approach for a mid-size enterprise network:
- Phase 1 — Application inventory: Identify every application accessed via VPN. Classify by sensitivity, user population, and authentication method. This inventory drives the ZTNA policy design.
- Phase 2 — Pilot with new applications: Deploy ZTNA for newly onboarded applications or for a subset of remote users accessing a defined application set. This builds operational familiarity before touching production VPN users.
- Phase 3 — Migrate by application risk tier: Migrate internal SaaS applications first (lower complexity), then server-accessed business applications, then legacy applications requiring special handling.
- Phase 4 — VPN decommission: After all application access has migrated, remove VPN entitlements and eventually decommission the concentrator.
For NYC financial services firms subject to NY DFS 23 NYCRR 500, ZTNA implementation directly addresses Section 500.12 MFA requirements and aligns with the continuous verification philosophy that regulators increasingly expect. Fortress MSSP designs and deploys ZTNA architectures for financial services clients transitioning from legacy VPN environments.
Performance and Cost Considerations
VPN performance has improved significantly with SSL VPN implementations and hardware accelerators, but split-tunnel configurations introduce security tradeoffs. ZTNA imposes application-layer proxy overhead but eliminates the backhauling penalty of full-tunnel VPN for cloud-bound traffic. For organizations where the majority of application traffic is SaaS or cloud-hosted, ZTNA often delivers better performance than full-tunnel VPN at equivalent or lower cost.
Pricing for ZTNA is uniformly user-based, typically $5–$15 per user per month depending on vendor and feature tier. VPN concentrator costs are infrastructure-based (hardware, licenses, maintenance) and do not scale linearly with users. For organizations with highly variable remote user populations, the per-user ZTNA model may be more cost-efficient than maintaining VPN capacity for peak load.
The security architecture improvement justifies the transition independent of cost. VPNs built on implicit-trust, network-level-access assumptions are architectural liabilities in a threat environment where credential compromise and lateral movement are the dominant attack paths. Contact us to assess your current VPN posture and build a migration roadmap toward zero trust access.