January 10, 2024. Ivanti discloses CVE-2023-46805 and CVE-2024-21887 in Connect Secure. Chained together, authentication bypass plus command injection, no credentials needed. Already being exploited as a zero-day by a China-nexus actor before disclosure.
January 19, 2024. CISA issues an emergency directive. Federal agencies are told to disconnect the appliances.
January 31, 2024. Two more Ivanti CVEs land. The vendor’s own understanding of its attack surface is visibly incomplete.
April 2024. Palo Alto GlobalProtect, CVE-2024-3400, unauthenticated remote code execution as root. Another CISA emergency directive.
2024 overall. Google counts 75 zero-days exploited in the wild, with 44% of them targeting enterprise security products.
That ledger is the actual argument for zero trust network access, and it’s a better one than any vendor deck. The remote access appliance sitting at your perimeter is internet-facing, runs vendor firmware you can’t inspect, and holds the keys to your internal network. It became one of the most attractive targets in enterprise IT. Nation-state crews now hunt these boxes specifically.
None of which means your VPN needs to die this quarter. It means the risk calculation changed, and the honest version of that calculation includes what migration actually costs you in broken things and dollars.
What ZTNA Is, Once You Strip The Marketing Off It
The term got slapped onto nearly every security product on the market around 2018, so it’s worth going to the source. NIST’s Special Publication 800-207, published August 2020, is the authoritative definition, and the concept that does the real work is the implicit trust zone, the area where subjects are trusted by default after one initial authentication event.
On a traditional VPN, the implicit trust zone is your entire internal network. A user authenticates once, gets an IP on the corporate subnet, and from that moment can reach whatever that subnet reaches. Their laptop is now inside. So is anything on their laptop.
ZTNA compresses that zone down to a single application. The user authenticates, a policy engine evaluates identity plus device posture plus context, and the result is a connection to one specific resource. No subnet. No lateral movement. Ask for a second app, get evaluated again.
One thing worth saying plainly, since vendors blur it: zero trust is an architecture, not a product. NIST’s own guidance recommends gradual adoption, starting with asset discovery and a low-risk pilot, precisely because you cannot buy your way to it in a single purchase order. Anyone selling you a box labeled zero trust has already misunderstood the document.
What Actually Breaks During Migration
Here’s the section I wish existed when I first watched one of these projects go sideways. ZTNA handles HTTP and identity-aware access beautifully. Your environment contains a great deal that is neither.
Legacy And Non-Web Protocols
ZTNA products are strongest with web applications. The trouble starts with everything else. SMB file shares, print servers, thick clients that open their own ports, SIP phones, SCADA and OT gear, database admin tools connecting directly to instances, legacy client-server apps built when the network was assumed friendly. Most platforms support these to varying degrees through connectors and TCP or UDP tunneling, but “supported” and “works the way it did on the VPN” are separate claims and you should test the difference before committing.
Anything That Assumes A Flat Network
Applications that call each other by internal IP. Hardcoded hostnames. Split DNS setups. Licensing servers that need to see a corporate subnet. Any app that does a callback to the client. These worked because the VPN handed everyone a corporate IP, and the whole point of ZTNA is that it doesn’t.
The Inventory Problem, Which Is The Real One
Nearly every migration stalls in the same place. To write per-application access policy, you need to know what applications exist and who legitimately uses them. Most organizations don’t. The VPN never required that knowledge, because it granted network access and let the apps sort it out. So the first real deliverable of a ZTNA project isn’t a policy, it’s an inventory, and that discovery phase routinely takes longer than the technical rollout.
The Edge Cases That Generate The Support Tickets
- Contractors and third parties, who often need access from unmanaged devices that will fail device posture checks.
- Break-glass access. If your identity provider is down, how does anyone reach anything? Answer this before cutover, not during the incident.
- Personal devices, where posture requirements collide with what people will accept on hardware they own.
- Merged or acquired entities running their own directory, with users who don’t exist in your IdP yet.
- On-network users, since the model treats office LAN traffic as untrusted too, which surprises people who expected the office to be exempt.
The pattern across all of these: ZTNA doesn’t just replace a tunnel, it forces you to make explicit dozens of access decisions that the VPN made implicitly and invisibly for years. That’s the actual work. The software install is trivial by comparison.
What It Costs Per User In 2026
Real numbers, and they’ve moved noticeably in the buyer’s favor.
- Focused ZTNA platforms (Cloudflare, Twingate, Tailscale, and similar) now run roughly $5 to $10 per user per month, down from $8 to $12 in 2024 as the category commoditized.
- Cloudflare publishes $7 per user per month on pay-as-you-go annual, with a permanent free tier covering up to 50 users, which is the cheapest credible on-ramp available for a pilot.
- Tailscale lists Standard at $8 and Premium at $18 per user per month.
- Zscaler Private Access, which doesn’t publish list pricing, lands around $6 to $10 per user per month by third-party estimate, with ZIA on top if you want the internet-access side.
- Full SSE bundles (Zscaler, Netskope, Prisma Access, Cisco, Cloudflare One) hold at $15 to $25 per user per month, a premium that has widened to roughly 2.5x to 3x over ZTNA-only.
Three costs that never appear in those figures and consistently blow up budgets. The discovery and policy work above, which is people-time measured in months. Parallel running, since you will operate both VPN and ZTNA simultaneously through the transition, paying for both. And the identity provider dependency, because ZTNA federates against Entra ID, Okta, or Google rather than replacing them, so if your IdP licensing needs an upgrade to support the required conditional access, that’s a real line item.
Against that, subtract what the VPN actually costs. Appliance refresh cycles, support contracts, the emergency patch weekends, and the concentrated risk of a single internet-facing box. Over a three-year horizon, organizations facing a hardware refresh usually find the math favors migration. Organizations that just bought appliances usually find it doesn’t, yet.
When VPN Is Still Fine, And Saying So Isn’t Heresy
This is where most vendor-adjacent content refuses to be useful, so let me be blunt. A well-run VPN remains defensible when:
- Your appliance is patched promptly and you have a process that proves it. Nearly every headline breach above hit organizations that were slow to patch or didn’t know they’d been hit. Speed of patching is the whole variable.
- The user population is small and homogeneous. Twelve employees on managed laptops don’t generate the lateral movement risk that justifies a migration project.
- Your internal network is already segmented. If a compromised VPN session lands in a tightly segmented VLAN rather than a flat corporate network, you’ve already solved most of what ZTNA solves.
- Your access needs are genuinely network-level. Heavy OT, lab environments, or protocol-diverse workloads where per-application brokering fights you at every turn.
- You just refreshed hardware. Sunk cost is real, and a rushed migration produces worse security than a maintained VPN.
What is not defensible is an unpatched, internet-exposed appliance granting flat network access to a workforce nobody has inventoried. That configuration is the one being actively hunted, and the CVE ledger at the top of this page is the receipt.
The realistic path for most organizations isn’t a cutover, it’s a coexistence period measured in quarters: put ZTNA in front of the crown-jewel web applications first, leave the awkward legacy protocols on the VPN, shrink the VPN’s reach as you go, and let the appliance’s remaining scope get small enough that it stops being a catastrophic single point of failure. Slower than the roadmap slide. Considerably more likely to actually finish.