The Question
When a remote access VPN was first deployed in your organization, the security logic was straightforward: encrypt the connection between the remote user and the corporate network, authenticate the user, and grant them access to internal resources. The threat model assumed that the adversary was on the untrusted network between the user and the corporate perimeter — someone trying to intercept traffic or impersonate a user. The VPN addressed that threat.
The threat model has changed. Today, the adversary is frequently inside the VPN before the security team is aware of the breach. They entered not by intercepting traffic or defeating encryption, but by exploiting vulnerabilities in the VPN appliance itself — the internet-facing hardware that the enterprise has placed at the network edge, updated inconsistently, and left exposed to a global pool of adversaries running automated exploit tooling.
Once inside, the attacker finds something the original designers did not intend as a vulnerability: the full, trusted network access that VPN was designed to provide. The remote user who connects via VPN gets network-level access to all resources that the VPN pool is permitted to reach. The attacker who compromises that user's session — or the VPN appliance directly — gets the same access. There is no architectural boundary.
VPN's architectural flaw is not a configuration problem — it is a fundamental design issue that patches cannot fix.
Why This Matters Now
January 2024 changed the VPN vulnerability conversation permanently. Ivanti disclosed CVE-2024-21887 and CVE-2024-21893, two critical vulnerabilities in Ivanti Connect Secure (formerly Pulse Secure) that allowed unauthenticated remote code execution and authentication bypass, respectively. The vulnerabilities were actively exploited by UNC5221, a threat actor assessed by Mandiant to have nexus with China-sponsored espionage operations, before Ivanti had published patches or public guidance.
The timeline was the defining feature: exploitation was observed in the wild before the CVEs were publicly disclosed. Organizations were being breached through vulnerabilities they could not yet know about, against a vendor they had specifically selected for its remote access security capabilities. CISA issued Emergency Directive 24-01 ordering federal agencies to disconnect affected Ivanti devices and perform factory resets before reconnecting — an acknowledgment that once compromised, the devices could not be trusted even after patching.
The Ivanti incidents were not isolated. Fortinet's SSL-VPN product line saw multiple critical vulnerabilities exploited throughout 2024 and 2025, including CVE-2024-21762, which allowed unauthenticated remote code execution and was used in attacks against healthcare organizations and government agencies across North America and Europe. Palo Alto Networks' GlobalProtect gateway was similarly targeted in early 2024 via CVE-2024-3400, a command injection vulnerability exploited before patching was possible.
The thread connecting all of these incidents is the same: internet-facing VPN appliances are high-value targets because they sit at the edge of trusted networks and are notoriously difficult to patch rapidly in production environments. The weaponization-to-exploitation window for critical VPN vulnerabilities has collapsed to 48 hours or less in many documented cases — a timeline that organizations running mature patch management programs still cannot consistently meet.
The UnitedHealth Group / Change Healthcare breach — one of the most consequential healthcare sector incidents in US history — entered via a Citrix remote access environment with no multi-factor authentication enabled. The entry point was not a zero-day. It was a credentials-only remote access system with no secondary control. Ransomware operators spent weeks inside the network before deploying encryption payloads, moving laterally using the trusted access that remote access systems provide by design.
What the CURVE™ Data Shows
The 2026 Stackcurve SASE/SSE CURVE™ Report evaluated ZTNA platforms specifically on their ability to replace VPN-based remote access architectures, examining architectural characteristics, deployment flexibility, and security posture improvement relative to the VPN baseline.
Zscaler Private Access (ZPA) placed in the Leader tier on the strength of its proxy-based architecture — the user's device never joins the corporate network, and the application is never exposed to the internet. Cloudflare Access received strong marks for its performance characteristics and developer-friendly deployment model, with particular strength in organizations with a high proportion of web-based internal applications.
Netskope Private Access and Palo Alto Networks' Prisma Access ZTNA module both placed competitively, with Palo Alto's strength in integrated platform deployments where the same organization is already using Cortex XDR or Prisma Cloud. Cato Networks' ZTNA offering was recognized for its single-vendor SASE integration, reducing the architectural complexity of replacing VPN while simultaneously improving branch security.
The key differentiator across vendors in this category is support for legacy, non-web-based applications — the internal TCP/IP applications, RDP environments, and proprietary client-server software that pure web-proxy ZTNA architectures struggle with.
The full vendor rankings are in the 2026 Stackcurve SASE/SSE CURVE™ Report — free to download.
The Gap Most Buyers Miss
The architectural argument for ZTNA over VPN is well-understood at the conceptual level. The specific failure modes that prevent enterprises from realizing the security improvement are less often discussed.
1. Legacy application compatibility as a migration blocker
ZTNA platforms that operate as HTTP/HTTPS proxies work seamlessly with web-based internal applications. They do not natively support non-HTTP protocols — the SSH connections to internal Linux servers, the RDP sessions to Windows desktops, the proprietary TCP applications that represent a significant share of internal application access in most mature enterprises. Organizations that evaluate ZTNA for modern web apps and declare success have not replaced the VPN — they have covered a subset of access cases while leaving the high-risk legacy access use cases on the old architecture.
2. Credential-based ZTNA is not structurally safer than credential-based VPN
ZTNA limits the blast radius of a compromised credential: the attacker can reach only the apps the user is authorized for, not the whole network. That is a meaningful improvement. But it does not eliminate the risk. If the organization has not implemented phishing-resistant MFA (FIDO2/passkeys), enforced device health checks before granting ZTNA sessions, and implemented anomaly detection on ZTNA access patterns, a compromised credential still yields significant access. ZTNA is not a substitute for identity hygiene — it is an architectural complement to it.
3. The ZTNA connector as the new VPN concentrator
ZTNA architectures typically require a connector or broker deployed inside the corporate network to proxy application access. This connector is an internet-adjacent component that must be maintained, patched, and monitored. Organizations that deploy ZTNA and fail to treat the connectors as high-value infrastructure have simply moved the attack surface from the VPN appliance to the ZTNA connector — a smaller attack surface, yes, but not zero.
4. Split-tunneling assumptions that reintroduce risk
Many ZTNA deployments route only internal application traffic through the ZTNA platform, leaving general internet traffic to flow directly. This is architecturally correct — ZTNA replaces the internal access function of VPN, not the web security function. But organizations that migrate to ZTNA without simultaneously ensuring that internet-bound traffic is covered by SSE (SWG, CASB) have removed a control — the VPN's incidental coverage of internet traffic during full-tunnel VPN sessions — without replacing it.
Questions Your Buying Team Should Be Asking
1. How does your platform handle non-HTTP/TCP applications, and what is the client experience for legacy protocols?
Ask the vendor for a specific demonstration of RDP, SSH, and proprietary TCP application access. Understand whether the client agent provides transparent protocol handling or requires application-specific configuration. The answer determines whether the platform can actually replace VPN for your application portfolio or only for the modern subset of it.
2. What device health verification is enforced before granting application access?
ZTNA without device posture checking grants application access to any device that can authenticate as an authorized user — including personal devices, compromised endpoints, and attacker-controlled machines that have captured a valid credential. Verify that the platform checks device management enrollment, endpoint security tool presence, and OS patch level before allowing session establishment.
3. How does your platform handle service accounts and non-human identities that currently use VPN for backend application connectivity?
Enterprise VPN deployments often carry automated processes — backup jobs, monitoring agents, API integrations — that authenticate using service accounts and run over the VPN tunnel. These non-human identities need an equivalent access path in a ZTNA architecture. Vendors handle this differently, and the migration complexity for service account access is frequently underestimated.
4. What is your connector architecture, and how do you protect connectors from lateral movement if a connector host is compromised?
The connector is the component that bridges your ZTNA cloud platform to your internal applications. Understand where connectors run, what network access they require to function, and what the blast radius is if a connector is compromised. Connectors should run in isolated network segments with minimal lateral reach.
5. What monitoring and analytics do you provide for ZTNA session behavior, and how do you detect compromised credentials?
ZTNA reduces the blast radius of a compromised credential but does not eliminate the risk. Understand what behavioral analytics the platform applies to session data — impossible travel, access pattern anomalies, unusual application access sequences — and how those detections integrate with your SIEM or SOAR platform.
The Stackcurve Take
The VPN vulnerability problem is not going away. The attack surface economics are too attractive: internet-facing appliances with privileged network access, inconsistent patching cadences, and a global pool of adversaries with financial and nation-state resources to develop and weaponize exploits. The next Ivanti-scale incident is not a question of whether but when, and the organizations still running VPN-dependent remote access architectures in 2026 are making a risk acceptance decision whether they frame it that way or not.
ZTNA is the architecturally superior replacement. The blast radius reduction is structural — it is a property of the architecture, not a configuration that can be misconfigured away. An attacker who compromises a ZTNA credential reaches only the apps the credential is authorized to access. An attacker who compromises a VPN credential reaches the network.
The migration is not trivial. Legacy applications, service account access, and split-tunneling gaps are real operational challenges that require planning. But the direction is unambiguous, and the vendor market has matured to the point where capable platforms exist for enterprises of all sizes and application portfolio complexities.
The organizations that wait for the next critical VPN CVE to begin the migration conversation will find that the timeline from CVE publication to active exploitation is shorter than their change management process.
The 2026 Stackcurve SASE/SSE CURVE™ Report covers ZTNA platforms and VPN replacement architectures in detail. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.