ZTNA vs VPN: When to Replace, When to Layer, and How to Migrate Without Breaking Remote Work

The VPN was the original answer to "how do remote workers reach internal apps." For two decades, that answer was good enough. In 2026, it isn't. The workforce moved off the LAN, the apps moved into SaaS, and the VPN tunnel kept doing what it always did: route everything to a single concentrator and hope nothing inside the perimeter goes wrong.

ZTNA is what replaces it. Or at least, ZTNA is what most teams are moving toward, in stages, while keeping a thin VPN layer for the apps that aren't ready yet. This is the practical view of ZTNA vs VPN: when to replace, when to layer, and how to migrate without breaking a remote workforce on the way.

The two-sentence answer

VPN extends the corporate network to a remote device, then trusts everything inside the tunnel. ZTNA, or Zero Trust Network Access, gives a user access to a specific application based on identity and device posture, without putting the device on the network at all. ZTNA wins for SaaS-era workforces. VPN survives where legacy on-prem apps still live.

What VPN actually does

A VPN client builds an encrypted tunnel from the device to a concentrator inside the corporate network. Once the tunnel is up, the device behaves as if it's on the LAN. It can resolve internal DNS. It can reach internal IPs. It can talk to anything the firewall allows on the inside.

That model worked when "internal apps" meant Exchange, SharePoint, a few file shares, and an internal wiki. It does not work cleanly today, for three reasons.

Most apps are SaaS now. Salesforce, Microsoft 365, Google Workspace, Slack, Notion, Workday, GitHub: they don't live behind your firewall. The VPN doesn't help you reach them. It just adds latency to your hop.

The trust model is too broad. A user on the VPN can talk to anything on the network the firewall lets them reach. A compromised laptop on the VPN is a compromised laptop on the LAN. East-west movement after a single foothold is the textbook breach pattern of the last decade.

Performance is a tax. VPN concentrators are physical or virtual chokepoints. Every web request and every SaaS login routes through them. For a hybrid workforce, that's a constant drag on the user experience and a constant operational headache for IT.

What ZTNA actually does

ZTNA inverts the model. Instead of putting the device on the network and trusting it, the user authenticates, the device's posture is checked, and the user is granted access to a specific application. Not the network. The app.

The control point sits between the user and the resource. It checks identity (SSO, MFA), device posture (managed, healthy, encrypted, patched), and policy (this user, on this device, in this location, can reach this app). If everything passes, the user gets a brokered connection to the app and nothing else.

The practical differences from VPN are large.

• The user never sees the network. They see the app they need, and only that app.
• Lateral movement after a foothold is structurally harder, because the device is never on the LAN.
• Performance scales with the broker, not with a single concentrator.
• Policy is per-app, not per-network. A contractor who needs access to the design tool gets the design tool, not the rest of the corporate network.

Where VPN still has a role in 2026

The honest version of the ZTNA story is that VPN doesn't go to zero overnight, and some of it might never go to zero. The places VPN survives:

Legacy on-prem apps without modern auth. If the app doesn't speak SAML, OIDC, or any modern protocol, ZTNA brokering is harder. A thin VPN tunnel scoped to that one app is often the cleanest answer until the app gets retired.

IT operations to data center infrastructure. Server-side admin work, console access to networking gear, and similar back-of-house tasks often still ride a VPN. The volume is small, the risk is high, and the policy is tight.

Sensitive admin paths under change-management pressure. Some teams keep a VPN as a defense-in-depth path for break-glass scenarios. ZTNA covers 95% of access; the VPN is the fallback nobody touches in a normal week.

If you're at the planning stage, the move is not "rip out the VPN this quarter." The move is "shrink the VPN's surface area until it's running for a small, named set of apps and admin paths."

The four questions that decide whether ZTNA replaces or layers

If you only have time to ask four questions in a planning session, ask these.

1. What percentage of access today is to SaaS vs on-prem apps?

If you're 80%+ SaaS, ZTNA replaces almost the whole VPN. If you're heavily on-prem, ZTNA layers on top while VPN shrinks slowly. Most mid-market teams are somewhere between 70/30 and 90/10 in favor of SaaS, which is why the move is mostly replace.

2. Do all your critical apps speak modern auth?

SAML or OIDC is the bar. If yes, ZTNA brokers cleanly. If a few apps don't, plan a thin VPN scoped to those apps and budget for retiring or modernizing them.

3. Where does inspection of web traffic happen today, and where will it happen tomorrow?

VPN often carried web traffic to a perimeter web filter as a side effect. Once VPN goes, web traffic needs a new control. A modern, agent-based SWG is the right answer because it works the same on or off the network. If the SWG is a cloud proxy, you've replaced one backhaul with another.

4. How will you handle device posture without the VPN as the gate?

The VPN was a coarse posture check: is the device healthy enough to come onto the network? ZTNA needs a finer-grained check at the app level. Tie ZTNA to your IdP's conditional access policies and your endpoint management posture data. If the device isn't healthy, the SaaS login should fail, not just the VPN connect.

A 90-day plan to retire most of the VPN

If you're starting from "we have a working VPN and a SaaS-heavy workforce," this is the shortest sane sequence.

• Days 1 to 14: inventory every app reached over the VPN. Bucket them: SaaS, on-prem with modern auth, on-prem legacy. Note the user counts on each.
• Days 15 to 45: stand up ZTNA for the SaaS bucket and the on-prem-with-modern-auth bucket. Tie it to your IdP and your endpoint management posture. Run users in parallel: VPN still up, ZTNA brokering the same apps.
• Days 46 to 75: move users off VPN for SaaS access first. Watch tickets. Tune posture rules. Most VPN sessions will start to drop on their own.
• Days 76 to 90: shrink the VPN to the legacy-app bucket only. Document the named apps still riding it. Schedule the modernization or retirement work.

Most mid-market teams hit 80% VPN reduction inside that window. The remaining 20% is the slow work, which is fine. The point is that VPN stops being the universal access path.

What changes for the SWG and DLP layer

This is the part that gets missed in most ZTNA conversations. When VPN goes, web traffic stops trombone-ing through a corporate firewall on the way to SaaS. The web filter that was running on that firewall stops protecting most of the workforce most of the time.

The fix is not "buy a cloud SWG and route everything to a vendor PoP." That's the same backhaul model, with a different vendor logo. The fix is an agent-based SWG that runs on the device, inspects SSL on-endpoint, and applies the same policy whether the user is at home, in the office, on a plane, or in a country your VPN never reached.

dope.security ships the agent-based SWG specifically because the alternative falls apart for a distributed workforce. The remote work security playbook walks through the broader stack. A mid-market public sector IT team rolled out their first SWG on this model and stopped depending on the VPN being on. An SMB financial services firm stood up SWG and CASB Neural inside a quarter for the same reason.

How dope.security fits into a ZTNA-era stack

dope.security covers the SWG, CASB, DLP, and AI governance side of a ZTNA-era stack. The architectural fit:

Agent-based SWG. SSL inspection, URL filtering, and policy enforcement run on the device. Same policy on or off the corporate network. No PoP routing tax. Under 100 MB of RAM. 4x the performance of legacy proxy SWGs in our benchmarks.

Dopamine DLP. Inline endpoint DLP that catches file uploads, AI prompts, and clipboard pastes before they leave the device. Block, Monitor, or Off. Zero-retention classification.

CASB Neural. Scans OneDrive and Google Drive for externally and publicly shared files containing PII, PCI, PHI, or IP. One-click remediation. Continuous monitoring.

Cloud Application Control. Tenant-level SaaS control. Allow your enterprise ChatGPT or Microsoft 365 tenant. Block personal accounts on the same domain. The piece a VPN-and-firewall stack could never enforce cleanly.

VPN is the access path that's shrinking. ZTNA is the new access broker. dope.security is the layer that watches what people actually do once they get to the app.

FAQ

Is ZTNA the same as SASE or SSE? Not exactly. SSE is the umbrella for SWG, CASB, ZTNA, and FWaaS. SASE adds SD-WAN to that. ZTNA is one component of an SSE platform, focused specifically on application access. SASE vs SSE has its own write-up.

Can I run ZTNA and VPN at the same time? Yes, and most teams do during migration. Run ZTNA for SaaS and modern on-prem apps. Keep a thin VPN for legacy on-prem apps and admin paths. Shrink the VPN over time.

Does ZTNA work for traveling and international staff? Better than VPN. ZTNA brokers don't care where the user is, only that the user and device meet the policy. The piece that matters more for travelers is the SWG, which needs to be agent-based to work consistently in restricted geographies.

What's the right starting point if my workforce is mostly remote? Stand up an agent-based SWG first. It gives you visibility and enforcement on day one. Then layer ZTNA on top for application access. Retire VPN routes as ZTNA coverage expands.

Try dope.security

If your VPN is doing the work of an access policy, that's the gap dope.security closes. Agent-based SWG, Dopamine DLP, CASB Neural, and Cloud Application Control all run on one agent and one console. Book a 20-minute demo or start an instant trial.