VPN to ZTNA Migration: What Actually Changes for Users and Security Teams
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Every major network security vendor will tell you to replace your VPN with ZTNA. What they rarely explain is what the transition actually looks like on the ground: which applications move first, how users experience the change, what breaks during a parallel run, and how your security team's daily workflow shifts once the perimeter model is gone. This guide covers the operational reality of a VPN-to-ZTNA migration, not the marketing version.
ZTNA vs. VPN: The Architectural Difference That Changes Everything
A traditional VPN grants network access. When a user authenticates to a VPN concentrator, they receive an IP address on the corporate network and can, in practice, reach any system that is not explicitly blocked by a firewall rule. The trust model is: authenticated user equals trusted network participant. Attackers love this, because a single compromised credential grants broad lateral movement capability across the entire network segment.
ZTNA grants application access, not network access. A user authenticates to a control plane, their device posture is assessed, and they receive a proxied connection to a specific application or service. They cannot scan the network, probe adjacent systems, or reach anything outside the explicit policy grant. The trust model is: per-session, per-application, continuously verified.
This architectural difference has direct operational implications. With VPN, your security team manages a network perimeter: firewall rules, ACLs, and segment boundaries. With ZTNA, your security team manages application-level policies: who can reach which app, from which device posture state, under which conditions.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
What Stays on VPN and What Moves First
A common migration mistake is treating the cutover as binary: everything moves to ZTNA on a target date. In practice, some workloads will stay on VPN for months or years, and the sequence in which you migrate the rest matters significantly.
Move to ZTNA first: Web-based SaaS applications with modern authentication (SAML/OIDC) are the easiest starting point. Remote desktop access to managed endpoints via your EDR's remote access feature or a purpose-built ZTNA connector is another fast win. Developer access to cloud-hosted services (AWS, GCP, Azure) via identity-aware proxy fits naturally into ZTNA's model.
Keep on VPN longer: Legacy client-server applications that rely on IP-based licensing or hardcoded port/IP configurations are poor early ZTNA candidates. Manufacturing and OT environments where proprietary protocols do not tolerate proxy intermediaries should stay on VPN until a dedicated OT-aware ZTNA solution is validated. Thick clients that perform local network discovery have behaviors that are fundamentally incompatible with application-level proxying.
The practical rule: if an application's network behavior can be described as 'client connects to a specific FQDN on a specific port,' it is a ZTNA candidate. If its behavior requires broadcast, multicast, or IP-range scanning, leave it on VPN for now.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The Four-Phase Migration Approach
A phased migration reduces risk and creates natural checkpoints for validating that your ZTNA configuration actually enforces the policies you intend before you remove the VPN safety net.
Phase 1: Inventory and baseline. Before touching any infrastructure, document every application accessed over VPN, who accesses it, from which device types, and at what frequency. This inventory becomes your migration backlog and your policy template. Most organizations discover 30 to 50 percent more VPN-dependent applications than they knew about during this phase.
Phase 2: Pilot with a low-risk user group. Select 20 to 50 users from a single team whose applications are all web-based and modern. Deploy ZTNA connectors, configure application policies, enroll devices, and run ZTNA as their exclusive access path for two weeks. Collect support tickets and edge case data.
Phase 3: Parallel run. Expand to 20 to 40 percent of users while keeping VPN available as a fallback. This phase surfaces application compatibility issues, certificate problems, and DNS resolution failures before they affect the entire workforce. Set a defined end date for the parallel run to prevent it from becoming a permanent state.
Phase 4: Cutover and VPN decommission. Migrate remaining users and disable VPN access in cohorts. Retain VPN infrastructure in a disabled state for 30 days post-cutover as a rollback option, then decommission completely.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
User Friction Points and How to Handle Them
User experience during a VPN-to-ZTNA migration is frequently underestimated. VPN, for all its security flaws, is a known quantity to users: connect, enter credentials, done. ZTNA introduces new concepts that require communication and, in some cases, workflow changes.
The most common friction point is device enrollment and posture assessment. Users whose personal devices were previously allowed on VPN may find those devices blocked by ZTNA policy if they do not meet minimum patch or disk encryption requirements. Address this before cutover by publishing device requirements and providing a self-enrollment guide.
A second friction point is application discovery changes. Users accustomed to VPN-based access to internal hostnames may find those names do not resolve the same way through a ZTNA proxy. Split-horizon DNS configurations require careful validation during the pilot phase.
Authentication prompt frequency is a third complaint. ZTNA solutions that require re-authentication per application session, or that have short session token lifetimes, generate repeated MFA prompts. Configure session duration policies that balance security with usability: 8-hour sessions with device posture re-checks are a reasonable starting point for corporate-managed devices.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Common Failure Modes and How to Avoid Them
Most VPN-to-ZTNA migrations that stall or roll back hit the same set of problems. Knowing them in advance means you are not discovering them for the first time under pressure.
Legacy application incompatibility is the most common blocker. Applications that use IP-based session management, that embed the client's IP in application-layer headers, or that rely on NetBIOS name resolution will behave incorrectly or fail silently through a ZTNA proxy.
Certificate issues account for a large share of pilot-phase failures. ZTNA proxies that perform SSL/TLS inspection will break applications that implement certificate pinning. Applications that validate intermediate certificate chains will fail if your ZTNA vendor's CA is not trusted by the application's runtime.
Connector single points of failure are an architectural mistake that creates outages blamed on the ZTNA platform. Deploy at least two connectors per application or application group, in separate availability zones or on separate physical hosts, before moving production workloads.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
The bottom line
A VPN-to-ZTNA migration is not a weekend cutover project. It is a 12-to-18-month operational change that requires an accurate application inventory, a phased rollout, and honest planning for the applications that will not fit the model. The security outcome is worth the effort: per-application access control, continuous device posture enforcement, and the elimination of the lateral movement surface that makes VPN compromises so costly. Zero trust network access pairs closely with privileged access management for complete lateral movement control: see best PAM solutions for vendor options. For SOC-level context on what attackers do after initial access through a compromised VPN, see PowerShell and LOLBAS offensive techniques.
Frequently asked questions
Can ZTNA fully replace VPN, or will some VPN always be needed?
For most enterprise environments, a small VPN footprint will persist for years alongside ZTNA. Legacy applications with IP-dependent architectures, OT and manufacturing systems with proprietary protocols, and some thick-client applications are poor fits for ZTNA's application-proxy model. The goal is not to eliminate VPN entirely on a fixed date but to reduce VPN scope to only the workloads that genuinely cannot migrate, and to harden and monitor that remaining VPN infrastructure accordingly.
How do we handle contractors and third-party vendors who cannot install a ZTNA client?
Most ZTNA platforms offer a clientless access mode for browser-based applications, delivered via a reverse proxy or isolated browser session. Contractors access the application through a URL in their browser without installing any agent on their device. Device posture assessment is limited in this model, so clientless access should be restricted to lower-sensitivity applications and combined with session recording or DLP controls where possible.
What happens to site-to-site VPN tunnels between offices during a ZTNA migration?
User-to-application VPN and site-to-site VPN are separate infrastructure components with different replacement paths. ZTNA addresses remote user access, not office interconnect. Site-to-site tunnels between branch offices and data centers are typically replaced by SD-WAN, private MPLS circuits, or cloud-native networking configurations depending on your architecture. Include site-to-site tunnels in your network inventory but treat them as a separate workstream from your ZTNA user-access migration.
How long does a typical VPN-to-ZTNA migration take for a 500-person company?
For a 500-person organization with a mix of SaaS and legacy on-premises applications, a realistic timeline is 9 to 14 months from inventory to full VPN decommission. The inventory and baseline phase typically takes 4 to 6 weeks. The pilot runs 2 to 4 weeks. The parallel run phase, where most migrations spend the most time due to legacy application issues, runs 3 to 6 months. Final cutover and decommission add another 4 to 6 weeks.
How do we size the ZTNA connector deployment for a mid-sized organization?
Connector sizing depends on the number of concurrent sessions and the bandwidth profile of the applications being proxied. Most vendors publish sizing guides based on concurrent users per connector instance. As a starting point, deploy two connectors per application group and monitor CPU and memory utilization during peak usage hours in the pilot phase. Scale out horizontally by adding connectors rather than vertically by upgrading connector VM size, since horizontal scaling also improves availability.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.