Replacing Corporate VPN with Zero Trust Network Access

Corporate VPN made sense in 2005, when "remote access" meant a sales rep dialing in from a hotel to grab one file. It doesn't hold up now, and the data backs that up in a way that's hard to argue with. The 2025 Verizon Data Breach Investigations Report found VPN attacks jumped from 3% to 22% of initial access vectors in a single year, the sharpest one-year spike the report has ever recorded for that category. Replacing VPN with Zero Trust Network Access isn't a five-year architectural dream anymore; it's a project with a sequence, a budget line, and an end date, and this piece is about how to actually run it.

What Zero Trust Network Access actually changes about how access works

VPN works like a hotel master key: show it once at the front desk, and it opens every door on every floor for the rest of your stay. That's the whole design flaw in one sentence. ZTNA throws out the master key and checks your ID at each individual door, every time, based on who you are, what device you're carrying, and whether anything about the request looks off.

Three things change structurally when you make that switch. Identity gets checked continuously instead of once at login. Access gets granted per application instead of per network, so a marketing coordinator who needs Salesforce never even sees that the finance server exists. And segmentation becomes the default state rather than something you bolt on with VLANs and firewall rules after the fact. Lateral movement, the thing that turns one phished credential into a company-wide incident, gets structurally harder because there's no "you're on the network now, go wherever" state left to exploit. The Zscaler ThreatLabz 2025 VPN Risk Report, surveying 632 organizations, found 89% worried about exactly this and 71% ranking it as a top concern.

Worth saying plainly: ZTNA doesn't swallow every VPN use case on day one. Site-to-site links between offices, legacy protocols that predate HTTP, and non-web traffic still need something else, which we'll get to under SASE. Anyone who treats ZTNA as a full VPN replacement out of the box is going to hit a wall around month three and wonder what happened.

The clearest proof this model works is boring old MFA. Microsoft's 2025 Digital Defense Report found MFA blocks 99% of identity-based attacks, even when the attacker already has a valid password in hand. That number only exists because the access decision happens at the identity layer, which is precisely the layer VPN skips. The 2025 DBIR found credential abuse was the leading initial access vector in 22% of all breaches. That's not a rounding error; that's the exact failure mode identity-first, per-application access was built to stop.

Where most organizations actually stand on this transition today

Everybody's on board, at least on paper. The Zscaler report found 96% of organizations are considering or actively pursuing zero trust, and 65% say they plan to replace their VPN within 12 months. Okta's State of Zero Trust Security report shows 61% of organizations worldwide have launched a zero trust initiative, up from 24% in 2021. That's not a trend, that's a stampede.

And yet a 2025 survey of over 400 IT and security professionals found only 8% report a full SASE implementation. Conviction is universal; completion is rare. That gap is the whole story right now, and it's worth sitting with for a second rather than rushing past it.

Part of the explanation is infrastructure inertia. On-premises ZTNA deployment still made up 60.3% of the market in 2024, which tells you this isn't a purely cloud-native shift. Financial services, healthcare, and government carry legacy systems and regulatory constraints that don't disappear because a vendor shipped a new dashboard. Gartner's widely cited prediction, that by 2025 at least 70% of new remote access deployments would run on ZTNA rather than VPN, shaped a lot of procurement conversations well before the actual rollouts caught up to the forecast.

So why the gap? It isn't a lack of belief. Talk to any security team stuck mid-transition and the honest answer is that they don't know where to start, or how to run VPN and ZTNA side by side without breaking something. That's a sequencing problem, not a conviction problem, and sequencing problems are solvable.

How to sequence a migration without cutting off access mid-way

VPN and ZTNA are not enemies during a migration. They're roommates, temporarily. The goal is to shrink VPN's footprint week by week, not to schedule a cutover weekend and hope nobody notices the outage.

Phase one is inventory, and it's duller than it sounds but skipping it is the single most common way projects go sideways later. Rank applications by blast radius: if this app's VPN access got compromised tomorrow, how bad is it? Map user groups against what they actually touch, and most security teams are surprised, sometimes alarmed, by how much broader the existing access grants are than anyone intended. Flag the non-web traffic now, because it's not going through ZTNA natively and needs to go on the SASE list for later.

Phase two starts with the accounts that carry the most risk: contractors, third-party vendors, anyone with elevated privileges. These are also, not coincidentally, the accounts most often abused in VPN breaches, so moving them first buys the most security for the least effort. Deploy ZTNA connectors on the applications these users need, route them through the ZTNA proxy, and leave VPN running untouched for everyone else. Nobody outside this group notices anything changed.

Phase three is the slow grind through the rest of the workforce, one application at a time: internal web tools, SaaS behind private access, developer environments. Treat device posture checks as a milestone you hit along the way, not a gate you have to clear before you're allowed to start. If SSO and MFA aren't already universal, this is where that gap usually adds the most time to the schedule, so plan for it rather than being surprised by it.

Phase four mops up the stragglers: legacy thick-client software, non-HTTP protocols, site-to-site connections between offices. These need either an IP-level tunneling overlay from your ZTNA vendor or an SD-WAN layer from SASE. Only once every use case has a home does the VPN actually get switched off, and for plenty of organizations, keeping a small sliver of VPN alive indefinitely for one stubborn legacy system is a perfectly reasonable place to land, not a failure.

The mistake to avoid: waiting to finish consolidating your identity provider or rolling out full device management before touching ZTNA at all. That's backwards. It delays real security gains by months when your highest-risk users could be protected within days.

The identity and device posture requirements that make ZTNA work

ZTNA is a policy engine, and a policy engine is only as good as what it's fed. Feed it garbage signal and it makes garbage decisions with more confidence than VPN ever did.

The foundation is an identity provider, Okta, Azure AD, Google Workspace, whatever your organization already runs, integrated cleanly into the ZTNA platform. MFA enrollment across the whole user base comes right behind it, because that 99% attack-block figure from Microsoft only applies to users who are actually enrolled. An unenrolled user is a hole in the fence, no matter how good the fence looks on paper.

Device posture is the second signal layer, and it answers questions VPN never asked: is this device company-managed or somebody's personal laptop? Is the OS patched? Is endpoint protection actually running, or did it get disabled six months ago and nobody noticed? Good ZTNA policy varies posture requirements by application, so a low-stakes internal wiki might only need valid identity, while a finance system demands a managed, patched, monitored device before it lets anyone in. This is also where BYOD gets workable instead of being an all-or-nothing headache: a contractor's personal laptop can still reach a designated app, just with tighter limits attached.

Mature policies layer in context on top of that: time of day, geographic location, whether the connection is coming from a corporate network or a coffee shop, behavioral patterns that look off. But that's a later phase, not a starting requirement. Build identity and MFA first, add device posture for your highest-risk application group second, and leave the full behavioral analytics for whenever you get there. Trying to design the perfect policy set before migrating a single user is exactly how these projects stall out at the whiteboard stage. The 2025 DBIR found 88% of basic web application attacks involved stolen credentials, which is the empirical case for identity-first controls; this isn't theory, it's just what the breach data says.

Where SASE fits when ZTNA alone isn't enough

ZTNA handles the user-to-application problem well. It was never built to handle site-to-site links between offices, deep inspection of outbound internet traffic, or network-level access for protocols older than the web itself.

SASE is the umbrella that covers what's left: ZTNA, SD-WAN, Secure Web Gateway, CASB, and firewall-as-a-service, delivered as one cloud service instead of five separate boxes. Got branch offices? SASE replaces the VPN concentrator and the branch firewall stack in one move. Heavy SaaS usage? The SWG and CASB pieces handle traffic inspection and data governance so you're not stitching together three vendors' worth of logs by hand.

The market is consolidating around this fact. The Forrester Wave for Q3 2025 found only eight vendors cleared the bar for fully integrated SD-WAN, SSE, and ZTNA in a single platform: Cato Networks, Cloudflare, Fortinet, Netskope, Palo Alto Networks, SonicWall, Versa Networks, and Zscaler. Compare that to 2023, when the dominant pattern was vendor partnerships duct-taped together rather than one company owning the whole stack. Gartner found that consolidating onto a single SASE fabric cuts ongoing network security operating costs substantially, which is the kind of number that gets a CFO to stop skimming the slide deck and actually read it.

Regulation pushes in the same direction. GDPR, HIPAA, and similar mandates want centralized logging, consistent policy enforcement, and audit trails that hold up under scrutiny. Scattered VPN logs across a dozen concentrators in a dozen offices don't produce that. A single SASE fabric does, by design.

The practical dividing line: an organization with fewer than five branch offices and applications that live entirely in SaaS can probably finish this migration on ZTNA alone. Anyone with real branch infrastructure or legacy on-premises systems is going to need the SD-WAN layer eventually, so plan for it rather than discovering it halfway through.

What evaluating ZTNA platforms actually involves in practice

Feature checklists are marketing documents. What actually determines whether a rollout goes well is duller and more specific than that.

How long does it take to connect one new internal application, in practice, with your own team doing the work? How close is the vendor's network to your actual users, since every ZTNA setup adds a proxy hop and that hop's latency is the difference between "nobody noticed" and "the help desk got forty tickets on Tuesday"? Does it plug into the identity provider you already run without a custom integration project? And where does the real cost live: per-user fees, bandwidth overages, connector licensing, the stuff that never shows up on the pricing page but shows up on the invoice.

At the enterprise tier, the field has real, meaningful differences. Zscaler carries the longest track record at large scale, though its ZPA connectors need VM-based infrastructure and real network path planning, which stretches out deployment timelines. Palo Alto's Prisma Access is the natural fit if you've already sunk money into their next-gen firewalls; it slots into that stack tightly. Netskope leans hard into data governance and DLP, which makes it a common pick in regulated industries with complicated data classification needs.

Cloudflare Zero Trust earns its place in this conversation on merit, not by default. It offers a free tier for up to 50 users with full ZTNA capability, the only enterprise-grade option a small team can run at zero cost, and paid tiers start at $7 per user per month with no annual lock-in and no bandwidth overage fees. The cloudflared connector deploys on any Linux host in minutes, not days. Cloudflare's network puts a ZTNA proxy within 50 milliseconds of the vast majority of the world's connected population, which makes that extra hop essentially invisible to end users. Forrester named Cloudflare a Leader in both its Q3 2025 SASE Wave and its Q1 2025 Wave, citing it as the strongest current offering in the latter. Cloudflare also publishes benchmark data showing it's the fastest ZTNA provider across most tested cloud regions; these are vendor numbers, so independent verification is worth doing, but they line up with a real structural advantage: a network built from the ground up for performance, rather than a security product with a network bolted on afterward.

None of these platforms replace your identity provider, and none of them should. The right question isn't "which ZTNA platform is best" in a vacuum; it's "which one integrates cleanest with the IdP we already have." For any organization under 50 seats, Cloudflare's free tier removes a barrier that used to keep serious ZTNA locked behind enterprise contracts and enterprise budgets.

How organizations that have completed this migration describe the operational difference

Ask a help desk what changed and they'll talk about tickets before they talk about security. VPN clients crash, credentials lock, split-tunneling breaks in ways nobody can explain over the phone; ZTNA removes the client entirely and the ticket volume drops with it. Cloudflare reports a dramatic reduction in remote access support tickets after organizations move off VPN and onto Access, and that number tracks with what makes intuitive sense: fewer moving parts, fewer ways for something to quietly break.

Users notice speed before they notice anything else. Web app traffic through a nearby ZTNA proxy usually beats VPN, because VPN insists on backhauling everything to one central data center no matter where the user actually sits.

For the security team, the shift runs deeper than user experience. Coarse VPN connection logs get replaced by granular records of exactly which application, which session, which user, at what time. Revoking access when someone leaves the company becomes a change in a dashboard instead of a scramble across firewall rules and VPN group policies scattered over half a dozen devices. And incident response itself changes shape: a compromised account used to mean the attacker had the network. Now it means the attacker has one application, maybe two, and nothing else, which turns a five-alarm fire into a much smaller, much more containable problem.