Most enterprises still run a VPN designed for a different era: a perimeter you log into once, after which you can reach far more than your job requires. That model made sense when applications lived in a single data centre and everyone worked from an office. It breaks down when applications are split across SaaS, multiple clouds, and on-premises systems, and when staff work from home, hotels, and client sites. The VPN becomes both a bottleneck and a blast radius. A single compromised credential or an unpatched VPN gateway can expose the whole internal network.
Zero Trust Network Access, or ZTNA, replaces that broad network access with per-application, identity-aware access. Instead of joining a network, a user connects to a specific application after the broker verifies identity, device posture, and context. Nothing else is reachable. This is a meaningful improvement, but it is not a product you buy and switch on overnight. A rushed migration breaks legacy applications, frustrates travelling staff, and creates shadow workarounds that are worse than the VPN you replaced.
This article lays out a migration path that works in practice: how to inventory what the VPN actually carries, how to sequence applications by risk and difficulty, how to run VPN and ZTNA in parallel without creating two perimeters, and how to handle the edge cases — legacy protocols, contractors, service accounts, and break-glass access — that derail most programmes.
#Quick Answer: How Do You Migrate From VPN to ZTNA Without Breaking the Business?
Migrate application by application, not user by user, and run the VPN and ZTNA in parallel for months. Start with web applications behind an identity-aware proxy, because they are the easiest to broker and the easiest to roll back. Keep the VPN for the long tail of legacy protocols, then shrink it as you publish each remaining application through ZTNA or a private connector. Do not turn the VPN off on a single cutover date. Turn it off application by application, and only retire it when traffic logs show zero legitimate use for several weeks. The migration succeeds when users barely notice it, not when the project team declares victory.
#Why VPNs Fail the Modern Enterprise
A VPN grants network-level access. Once authenticated, a laptop typically receives an IP address on the corporate network and can probe and connect to systems it was never meant to touch. Segmentation with firewall rules helps, but in practice those rules accumulate exceptions, go stale, and are rarely tested from an attacker's perspective. Lateral movement after phishing or credential theft is the predictable result. Attackers do not need to defeat every control; they need one valid VPN session and a flat network behind it.
VPN gateways are also attractive targets in themselves. They are internet-facing, they run complex code, and they must be patched urgently when vulnerabilities appear. Several high-profile incidents in recent years began with unpatched or misconfigured VPN appliances. Even a well-patched gateway concentrates risk: it is a single choke point whose compromise or outage affects everyone.
ZTNA changes the unit of access from network to application. The broker checks policy on every connection and tunnels only to that application. Other applications remain invisible; there is no network to scan. Identity becomes the new perimeter, but lateral movement drops sharply.
#Inventory First: What Does the VPN Actually Carry?
No migration plan survives contact with an undocumented VPN. Before choosing a vendor or a timeline, spend two to four weeks measuring real usage. Pull VPN gateway logs for at least 30 days and answer concrete questions: which destinations receive traffic, which protocols, which users, and at what times? Group destinations by application owner, not by IP address. You will usually find three categories: a small number of heavily used web applications, a long tail of occasionally used internal tools, and traffic that should not be on the VPN at all — SaaS applications reached through backhaul or forgotten integrations.
Classify applications by migration difficulty
A practical classification has four tiers. Tier 1 is web applications over HTTPS with standard authentication — the easiest ZTNA candidates. Tier 2 is web applications with legacy authentication, such as Kerberos, header-based single sign-on, or client certificates. These are still feasible but need header injection or an identity bridge. Tier 3 is non-web protocols: SSH, RDP, database connections, SMB file shares, and thick-client applications. These need a client-based ZTNA agent or a private connector, and they need more testing. Tier 4 is the hard tail: applications that embed IP addresses, require broadcast or multicast, or run on systems that cannot accept a connector. Tier 4 may stay on a shrunken VPN, move behind a jump host, or be replaced. Naming Tier 4 early prevents the project from stalling when it is discovered late.
#Designing the ZTNA Architecture
ZTNA products differ, but the core components are consistent: an identity provider, a policy engine, a broker, and connectors deployed near applications. Placement matters more than vendor diagrams.
Identity and device posture as policy inputs
Policy should combine at least three signals: who the user is, including group membership and authentication strength; what device they are on, including managed status, operating system version, disk encryption, and endpoint protection health; and context, including location and risk signals from the identity provider. A finance application might require phishing-resistant multi-factor authentication and a managed device, while an internal wiki might require only single sign-on and a compliant device. Avoid a single policy for everything. Uniform strictness drives exceptions; uniform leniency defeats the purpose.
Connector placement and policy as code
Connectors are lightweight agents that run near the application, typically in the same virtual private cloud or data centre segment, and establish outbound connections to the broker. Because connections are outbound, you do not need to open inbound firewall ports. Deploy at least two connectors per location for redundancy, and test failure explicitly: kill one connector during a maintenance window and confirm sessions fail over without user intervention.
``yaml
policies:
- name: finance-erp-access
application: erp.internal.example.com
users:
groups: ["finance", "finance-readonly"]
require:
mfa: phishing-resistant
device: managed-and-encrypted
session:
idle_timeout_minutes: 30
reauth_on_risk_change: true
``
#The Phased Migration Sequence
Sequence matters more than speed. Start with a pilot: one Tier 1 application with an engaged owner and a tolerant user base — an internal dashboard, not payroll. Migrate a pilot group of 50 to 200 users, keep the VPN path available, and measure login success rate, latency compared with the VPN, and help-desk ticket volume. Fix identity, group mapping, and certificate issues here, while the blast radius is small. Include users from different locations and devices, not only IT staff.
Next, migrate Tier 1 and Tier 2 applications in waves of five to ten, grouped by owner. For each wave, publish through ZTNA, run both paths for two weeks, then remove the VPN route and monitor for breakage. Communicate user benefit — faster access, no VPN client — not architecture. Watch for web apps hiding non-web behaviour, such as SMB downloads or thick-client plugins. Those belong in Tier 3.
Moving non-web protocols and retiring the VPN
SSH, RDP, and database access through ZTNA typically require an agent on the endpoint that intercepts connections and brokers them per application. Test this phase with engineers first, because they are the heaviest users of these protocols. Pay attention to tooling: scripts that hard-code hostnames, SSH configuration files, database connection strings, and jump-host workflows all need updating. Provide migration guides for the top ten workflows, not just a generic announcement. For RDP in particular, consider whether browser-based access or a privileged access management solution is a better fit than raw protocol brokering. Giving every administrator direct RDP to every server through ZTNA reproduces the VPN problem at a different layer.
Only when Tier 1 through Tier 3 traffic has moved should you shrink the VPN. Reduce its firewall rules to the remaining Tier 4 destinations, restrict its user groups, and set an expiry date for VPN accounts. Monitor VPN logs weekly; any new traffic to a supposedly migrated application signals a missed workflow or a user bypassing ZTNA. After four to six weeks of zero legitimate traffic, decommission the gateway. Keep the configuration archived, not deleted, in case a Tier 4 application needs emergency access. This phased approach also contains vendor risk: if the product proves unsuitable in the pilot, you have lost weeks, not an enterprise-wide cutover.
#Handling the Hard Cases
Contractors and third parties are the most common source of exceptions. They may not be in your identity provider, may use unmanaged devices, and may need access for a fixed period. Create a dedicated contractor lifecycle: sponsored accounts with expiry dates, scoped to one or two applications, with phishing-resistant authentication where feasible and browser-only access otherwise. Review contractor access monthly. An expired contractor account that still works is a finding in any audit.
Break-glass access must exist for the ZTNA platform itself. If the identity provider is down, or the broker is unreachable, administrators still need a path to critical systems. Define a break-glass procedure that does not depend on the same identity provider: a separate, heavily monitored administrative path, with credentials stored in a vault, usage that triggers immediate alerts, and a post-use review. Test it at least twice a year. An untested break-glass procedure is a hope, not a control. Service accounts need workload identity, not shared human credentials stuffed into a ZTNA client. Use short-lived certificates or tokens, scoped to the specific service, and rotated automatically. For how secrets and vault design interact with this problem, see the companion discussion of pipeline secrets and gates.
#Measuring Success and Avoiding Common Failures
Success metrics should be operational, not project-based. Track the percentage of application traffic flowing through ZTNA versus VPN, the number of applications still reachable only via VPN, authentication failure rates by application, mean time to resolve access tickets, and the number of standing exceptions. A migration that moves 95 percent of traffic but leaves the most sensitive application on the VPN has not reduced risk where it matters.
Finally, ZTNA is one control in a broader zero trust programme. It does not replace endpoint protection, patching, or monitoring. NIST SP 800-207 is explicit that zero trust is principles applied across identity, devices, networks, applications, and data — not a single product. A migration that leaves identity governance weak has moved the perimeter, not removed it. The same per-request principle applies on the frontend, as discussed in zero trust frontend architecture.
#Frequently Asked Questions
Can ZTNA completely replace a VPN?
For most enterprises, yes for human access, but not always on day one. Web and common non-web protocols are well covered. Remaining exceptions are usually legacy protocols, site-to-site connectivity, and certain industrial or VoIP systems, which may need a shrunken VPN or site connector. Plan for a long tail.
Does ZTNA work without an agent on the endpoint?
Browser-based ZTNA works for web applications without an installed agent, using the identity provider session and the browser itself. Non-web protocols such as SSH, RDP, and database connections generally need an agent to intercept and broker the connection. Many products offer both modes, and a hybrid approach — agentless for casual web access, agent-based for engineers and administrators — is common and sensible.
What happens if the ZTNA broker or identity provider goes down?
This is the availability trade-off of any brokered model. Mitigate it with multiple broker points of presence, a highly available identity provider with cached session handling where supported, and a tested break-glass path for critical administration. Also consider which applications genuinely need continuous access during an identity outage versus which can wait an hour. Not every application needs the same availability target.
How does ZTNA affect contractors and partners?
Contractors should get scoped, time-boxed accounts in your identity provider or a federated partner identity, limited to the applications they need. Avoid shared contractor accounts and permanent VPN credentials. If a partner cannot meet your authentication requirements, offer browser-only access to a limited application set, and review that access monthly. The goal is to make contractor access easy to grant, easy to audit, and automatic to expire.
Is ZTNA more expensive than a VPN?
Licensing is usually higher per user than a VPN concentrator, but total cost should include hardware refresh, patching, backhaul, and firewall management. Many organisations find ZTNA cost-neutral once those are counted. Compare total cost over three years, not licence price alone.
#Sources and Further Reading
- NIST SP 800-207, Zero Trust Architecture — https://csrc.nist.gov/pubs/sp/800/207/final — the foundational reference for zero trust principles, policy engines, and deployment models.
- CISA Zero Trust Maturity Model — https://www.cisa.gov/zero-trust-maturity-model — practical maturity stages across identity, devices, networks, applications, and data.
- Cloudflare, Zero Trust Network Access documentation — https://developers.cloudflare.com/cloudflare-one/connections/connect/ — connector deployment and policy concepts.
- Zscaler, Private Access documentation — https://help.zscaler.com/zpa/about-zscaler-private-access — brokered private application access architecture.
- OWASP, Authentication and session management guidance — https://cheatsheetseries.owasp.org/ — relevant to the identity controls that ZTNA depends on.