The Question
The security team wants to replace the VPN. The network team wants to keep it. The CISO is looking at a threat briefing that includes three separate nation-state campaigns exploiting VPN vulnerabilities in the last 18 months and is inclined to agree with the security team. The network team's counter-argument is not that VPN is secure — it's that seven critical manufacturing systems, two mainframe environments, and the ERP rollout currently in progress all have network-layer dependencies that ZTNA doesn't address.
Both sides are right. That is the VPN replacement problem in its most common form.
ZTNA provides per-application access control, eliminates implicit trust after authentication, and removes the network-layer foothold that makes VPN compromise so damaging. These are real and material improvements over legacy VPN architecture. But ZTNA also makes specific assumptions about application architecture, client capabilities, and traffic patterns that do not hold universally. Organizations that implement ZTNA without accounting for the exceptions routinely discover coverage gaps post-migration that are harder to remediate than the VPN they replaced.
VPN vulnerabilities are now reliably exploited before patches can be deployed — but ZTNA migration done wrong creates coverage gaps that are worse.
Why This Matters Now
In January 2024, CISA and the FBI published an advisory confirming that Ivanti Connect Secure VPN appliances had been actively exploited since December 2023 via CVE-2024-21887 and CVE-2024-21893. The threat actors — later attributed to Chinese state-affiliated groups including UNC5325 — used the vulnerabilities to deploy webshells, establish persistence, and move laterally across victim networks before patches were available. Ivanti's detection guidance required forensic examination of device memory, which most enterprise security teams are not equipped to perform at speed.
This was not an isolated event. In 2024 alone, Fortinet SSL-VPN (CVE-2024-21762) saw active exploitation within days of disclosure, with CISA adding it to the Known Exploited Vulnerabilities catalog in February 2024. Cisco ASA and FTD VPN saw exploitation of CVE-2024-20353 and CVE-2024-20359 by a threat group CISA designated UAT4356. Palo Alto Networks GlobalProtect was targeted via CVE-2024-3400, a critical authentication bypass that allowed unauthenticated remote code execution on the firewall.
The pattern is consistent: VPN appliances sit at the perimeter, are internet-facing by design, and run complex protocol stacks that generate a steady stream of critical vulnerabilities. Patch cycles for network appliances are measured in weeks, not hours. Nation-state actors and ransomware operators have explicitly prioritized VPN exploitation in their initial access playbooks because the target surface is large and the dwell time before detection is long.
The operational implication is that continuing to run legacy VPN as a primary remote access architecture is now a defined and well-documented risk posture, not simply a technical debt item. Every CISO who presents that risk to a board in 2026 without a documented migration plan is accepting personal accountability for the exposure.
What the CURVE™ Data Shows
The 2026 Stackcurve SASE/SSE CURVE™ Report evaluates ZTNA platforms across four dimensions most relevant to VPN replacement decisions: application coverage breadth, agent and agentless deployment flexibility, network-layer fallback capabilities, and migration tooling maturity.
Zscaler Private Access leads the evaluated set on application coverage and policy granularity, with strong scores on per-app access control depth and identity provider integration. Cloudflare Access scores highest on agentless deployment flexibility, which is a critical capability for contractor and BYOD use cases. Palo Alto Prisma Access and Netskope Private Access both score well on enterprise feature depth but show higher deployment complexity scores, particularly in environments with mixed on-premises and cloud application portfolios.
The dimension where the most variance appears is network-layer fallback — the ability to grant explicit broad-network access for specific legacy use cases while maintaining ZTNA policy enforcement for everything else. This capability is what makes phased migration possible without creating security gaps. Platforms that lack mature fallback controls force a binary choice between full ZTNA and continued full VPN exposure.
The full vendor rankings are in the 2026 Stackcurve SASE/SSE CURVE™ Report — free to download.
The Gap Most Buyers Miss
The most common ZTNA migration failure is not a technology problem — it's a scope definition problem. Teams planning a "VPN replacement" frequently discover mid-migration that a subset of their environment was never actually compatible with ZTNA's architectural assumptions.
ZTNA works by proxying specific application connections through a cloud or on-premises enforcement point. This model requires that the application being accessed is individually addressable — either as a web application, a defined TCP/UDP service, or a named private application configured in the ZTNA platform. Applications that require broad network-layer access, broadcast-dependent protocols, or dynamic port ranges fall outside this model.
Where VPN still wins — specific use cases:
Legacy OT and manufacturing environments. Operational technology networks frequently run proprietary protocols — Modbus, DNP3, PROFINET — that are not individually addressable at the application layer. SCADA systems often require the connecting machine to appear as a node on the same network segment. ZTNA cannot proxy this traffic without protocol-specific connectors that most platforms do not ship natively. In these environments, VPN (or network-layer microsegmentation) remains the only viable option until OT modernization is complete.
Mainframe connectivity. IBM z/OS environments accessed via TN3270 or FTP-based batch file transfer present similar challenges. While some ZTNA platforms support TN3270 proxying, the feature is not universally available and frequently requires custom connector configuration that creates significant ongoing operational overhead.
Network-scan-dependent tooling. Vulnerability scanners, network monitoring platforms, and some backup systems require the ability to initiate connections across IP ranges rather than to specific named applications. ZTNA's per-app model breaks these tools unless the platforms support explicit IP range access policies — a capability that varies significantly across vendors.
The correct migration sequence for everything else:
Start with contractors, vendors, and third-party users. This population typically has the cleanest use cases (specific cloud applications, no legacy dependencies), no on-premises client management overhead, and the highest risk profile per authenticated session. Migrating this population first builds operational experience with zero real operational risk to internal users.
Add remote employees accessing cloud SaaS applications next. These are the use cases ZTNA was designed for. The migration is clean, the user experience improves, and the security gain is immediate.
Address on-premises application access for remote employees. This is where ZTNA connector deployment and private application configuration complexity lives. Plan for this phase to take 2-3x longer than phases one and two.
Migrate on-premises users. This is counterintuitive — most organizations assume office workers don't need ZTNA — but routing office traffic through ZTNA eliminates implicit internal network trust, which is the architectural gain that matters for East-West lateral movement prevention.
Decommission VPN concentrators. Only after you have documented every remaining VPN use case, classified each as migratable or legacy-excepted, and provided an explicit alternative for each excepted case.
Organizations that skip the use case classification phase and attempt a full-fleet VPN cutover routinely find themselves reversing the migration under operational pressure within 60 days.
Questions Your Buying Team Should Be Asking
1. Can your platform provide explicit network-layer access for specific source/destination pairs while maintaining application-layer control for everything else? This is the legacy exception handling question. Phased VPN migration requires the ability to carve out specific traffic — mainframe connections, OT network access, scan ranges — for continued broad-network treatment while migrating everything else to ZTNA policy. Platforms that offer only binary ZTNA-or-nothing architectures make phased migration significantly harder.
2. How does your platform handle applications that require the client to appear on the same network segment as the server? Broadcast-dependent protocols, Windows file share discovery, some database connection managers, and many OT protocols require network adjacency that application proxying cannot simulate. Ask vendors for a specific technical answer, not a marketing response. If the answer involves "we support that use case through our network connector," ask for a reference customer running that configuration in production.
3. What is your platform's behavior when the ZTNA enforcement point is unavailable? Fail-open means users route around the enforcement point and access applications directly — a security failure. Fail-closed means all application access stops — an operational failure. Most enterprise environments want per-application fail behavior, with some applications failing closed and others having a backup access path. Ask vendors how this is configured and what the default behavior is during an enforcement plane outage.
4. How does your migration tooling help document existing VPN tunnel usage before cutover? ZTNA migration requires knowing what your current VPN is being used for. Surprisingly few enterprises have complete visibility into this. Ask vendors whether their platform includes VPN traffic analysis tooling — either as a standalone capability or in partnership with your current VPN vendor — that can map current tunnel usage to ZTNA-addressable applications before the migration begins.
5. What contractual terms govern the transition period during which both VPN and ZTNA run in parallel? Most enterprise migrations run in parallel for 6–18 months. During this period, you are paying for two remote access platforms simultaneously. Ask vendors how parallel operation is licensed — some meter ZTNA by concurrent user, which means your cost structure during migration is difficult to predict. Get explicit contract language on parallel operation licensing before signing.
The Stackcurve Take
The case for replacing legacy VPN is not a close call. The threat data from 2024 alone — four separate critical exploits across Ivanti, Fortinet, Cisco, and Palo Alto VPN platforms, all exploited by nation-state actors before patches were available — establishes VPN appliances as a reliably targeted attack surface with a structural vulnerability cycle that shows no sign of slowing down. The question is not whether to migrate, but how to do it without creating gaps that are worse than the risk being mitigated.
The answer is disciplined use case classification before migration begins. Every VPN use case should be explicitly categorized as ZTNA-migratable, legacy-excepted, or requiring architectural remediation before migration. Organizations that complete this exercise upfront routinely discover that 80–90% of their VPN use cases migrate cleanly and the remaining 10–20% have a defined path. Organizations that skip it discover exceptions mid-migration, under operational pressure, with no plan.
The 2026 Stackcurve SASE/SSE CURVE™ Report covers ZTNA platforms, including migration tooling maturity and legacy use case handling. 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.