VPN to ZTNA Migration: A Practical Playbook for Replacing Legacy Remote Access
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.
VPN's security model — authenticate once, access everything on the segment — was designed for a threat model where the perimeter was the primary defense. In a world where phishing, credential stuffing, and MFA bypass attacks routinely compromise user credentials, network-level access on successful authentication gives attackers immediate access to internal systems that are often far less hardened than perimeter defenses. ZTNA inverts this: every application connection is individually authorized, device health is verified, and lateral movement within the network does not follow from credential compromise.
The migration is achievable but requires planning. The organizations that fail at VPN-to-ZTNA migrations typically try to do it too quickly, miss applications in their inventory, or attempt to force non-HTTP protocols through a web-native ZTNA platform without testing. This guide provides the workflow that avoids each of these failure modes.
Pre-migration: application inventory and policy design
An incomplete application inventory is responsible for the majority of VPN-to-ZTNA migration failures. If an application is missed in the inventory phase and removed from VPN routing, users lose access with no ZTNA fallback configured. This section covers how to build a comprehensive inventory by combining 90-day VPN destination log analysis, application owner surveys, DNS query review, and IT help desk institutional knowledge. It then covers how to translate each application's current access pattern into a formal ZTNA access policy that maps user identity groups and device health requirements to specific application grants before any infrastructure changes are made.
Map applications to user groups and access requirements
For each application identified in the inventory: document the application name and URL or host/port, the user groups that need access (HR team, engineering, all employees), whether access is currently unrestricted or IP-restricted within the VPN segment, and any additional access requirements (only during business hours, only from corporate devices, requires MFA). This mapping becomes the ZTNA access policy: HR tools accessible to HR department identity group from managed devices only; developer tooling accessible to engineering identity group from any device; financial applications accessible to finance team from managed devices during business hours. The policy design phase is where the security improvement over VPN is realized — VPN typically has no per-application access control, while ZTNA requires you to explicitly grant access per application per user group.
Test a pilot application before migrating anything else
Choose a low-risk, widely-used web application for the first migration: an internal wiki, a project management tool, or a HR self-service portal. Migrate this application to ZTNA with a 10-person pilot group that includes technically proficient users who can troubleshoot edge cases. Run for 2 weeks in parallel operation (ZTNA for the pilot group, VPN still available as fallback). Document every issue encountered and its resolution. This pilot teaches your team the ZTNA platform's configuration interface, troubleshooting tools, and common failure modes before you migrate business-critical applications. After a successful pilot: expand to all users of that application, confirm success for 2 weeks, then remove that application from VPN routing. The pilot pattern prevents a failed migration from affecting all users simultaneously.
Migration execution and VPN decommissioning
With the inventory complete and policies designed, migration execution follows a consistent application-by-application pattern: configure the ZTNA access policy, run a 2-week pilot with a small user group, expand to all users, confirm no remaining VPN usage for that application, then remove it from VPN routing. This section covers how to prioritize migration order to maximize security impact first (remote admin access and customer data systems before productivity tools), and how to handle the long tail of applications that cannot migrate cleanly to ZTNA due to IP-based authentication, proprietary thick-client protocols, or non-agent-capable IoT devices.
Prioritize migration order for maximum security impact
Migrate in order of security impact: (1) First: remote admin access (SSH, RDP, admin console access) — these are the most valuable targets for attackers, and ZTNA's device trust and per-session authentication provides the most security improvement here. (2) Second: customer data systems (databases, CRM, data warehouses accessible to employees) — restricting these to per-user, per-application grants with device verification significantly limits breach impact if an employee credential is compromised. (3) Third: productivity tools (internal wikis, project management, email archives) — lower risk but large user population makes ZTNA adoption easier here (less specialized configuration required). (4) Last: legacy thick-client applications that require the most investigation — leave these for when your team has ZTNA operational experience from the earlier migrations.
Handle the long tail: applications that cannot migrate to ZTNA
Some applications will not migrate cleanly to ZTNA: legacy applications authenticating by source IP, IoT devices that cannot run ZTNA clients, and protocols that your ZTNA platform cannot tunnel. For these: maintain network access controls (firewall allow-lists) rather than VPN, document which applications remain on traditional network access and why, and review the list annually as applications are modernized or replaced. The goal is not to decommission VPN for 100% of access on day one — it is to move all human user remote access to ZTNA, leaving VPN or direct network access only for non-human devices and legacy applications with documented justification. A hybrid ZTNA and legacy access state with clear documentation is more secure than keeping full VPN because the human credential attack surface is eliminated.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
VPN to ZTNA migration is an application-by-application process, not an infrastructure cutover. The migration sequence: complete application inventory from VPN logs and user surveys, map each application to its required user groups and device trust requirements, design ZTNA access policies before deploying any configuration, pilot with a low-risk application and 10 users, expand application by application with 2-week parallel operation periods, and decommission VPN segments only after confirming all applications in that segment are accessible via ZTNA. The security outcome — per-application access grants with device health verification instead of network-level access on VPN authentication — eliminates the lateral movement path that makes VPN credential compromise so damaging. Plan for 6-12 months for a full VPN replacement in a 200+ user organization; organizations that plan for 4 weeks consistently find themselves running a hybrid state for 18 months because of applications they did not inventory.
Frequently asked questions
What is the core difference between VPN and ZTNA security models?
VPN creates an encrypted tunnel that places the remote user's device inside the corporate network segment — once authenticated, the user has network-level access to all resources in that segment, constrained only by firewall rules. ZTNA grants access to specific applications rather than to a network segment: each connection is individually authenticated, each application requires an explicit access grant for that identity, and device health is verified before each connection is permitted. Security consequence: a VPN credential compromise gives an attacker network-level access and the ability to scan for and exploit any host on the connected segment. A ZTNA credential compromise gives access only to the specific applications that identity is authorized to reach — the attacker cannot scan the network, cannot access applications they are not explicitly granted, and cannot exploit hosts they cannot reach.
How do I inventory all applications that currently use our VPN for remote access?
Application inventory methodology: (1) Query VPN logs for destination IPs and ports: for each VPN connection over the past 90 days, extract the destination IP, port, and username. Cluster by destination IP/port to identify all applications being accessed via VPN. (2) Survey application owners: send a questionnaire to all application owners asking which applications require VPN access from remote users. This catches applications that are rarely used and might not appear in 90-day logs. (3) Analyze DNS queries from VPN clients: users accessing applications by hostname (not IP) generate DNS queries that can be extracted from DNS logs during VPN sessions. (4) Interview IT help desk: the help desk team receives tickets from users who cannot access applications remotely — their institutional knowledge of VPN-dependent applications is valuable. Categorize each application: web-based HTTP/HTTPS (migrates easily to ZTNA), SSH (migrates easily), RDP (migrates with some ZTNA platforms), proprietary thick client (may require special handling), non-IP protocols (requires specific investigation).
How do I choose between Cloudflare Access, Zscaler Private Access, and Tailscale for ZTNA?
Cloudflare Access: best for primarily web-based and SSH applications, organizations already using Cloudflare, and teams that want minimal infrastructure (agentless browser-based access for many applications). Supports rich identity provider integrations (Okta, Entra ID, Google Workspace). Pricing: per-user with free tier available. Gap: non-HTTP thick client applications require a client agent and additional configuration. Zscaler Private Access (ZPA): enterprise-focused, best for large organizations with complex application portfolios including thick clients, strong integration with Zscaler Internet Access for full SSE platform consolidation. Pricing: enterprise contract, not suitable for small teams. Tailscale: best for developer-heavy organizations and teams that need peer-to-peer mesh networking (not just client-to-server access), DevOps workflows requiring SSH access to internal infrastructure, and environments with a mix of cloud and on-premises resources. Based on WireGuard, very low overhead. Pricing: per-user with free tier for small teams. Gap: less suited for large-scale end-user application access than Cloudflare or Zscaler.
How do I migrate applications from VPN to Cloudflare Access without disrupting users?
Phased migration workflow for Cloudflare Access: (1) Set up Cloudflare Tunnel: deploy a cloudflared tunnel daemon on a server in your internal network. This creates an outbound-only connection from your network to Cloudflare's edge, eliminating inbound firewall rules. (2) Configure the first application: in Cloudflare Zero Trust dashboard, add a Self-hosted application pointing to the internal URL of your first migration target. Set the access policy: who can access (identity groups, specific emails), and what additional verification is required (country restriction, device health check via WARP client). (3) Test with a pilot group of users (the application owner and power users): they access the application through the Cloudflare Access URL and confirm functionality. VPN remains available as fallback during pilot. (4) Expand to all users of that application. (5) After 2 weeks of successful operation with all users: remove that application's internal server from the VPN routing table. Repeat for each application. Never remove VPN access for an application until all its users have confirmed ZTNA access works.
What are the hardest applications to migrate from VPN to ZTNA and how do I handle them?
Applications that resist ZTNA migration and their handling strategies: (1) Thick client applications (proprietary software that connects via TCP to a specific port): requires ZTNA platform support for non-HTTP TCP tunneling. Cloudflare Access supports this via its network tunnel feature; Tailscale handles it natively as a mesh network. Test thoroughly — thick clients often use multiple connection types (UDP, multicast) that may not tunnel correctly. (2) Windows file shares (SMB/CIFS): Tailscale handles SMB natively as a mesh network. For Cloudflare-based ZTNA, SMB requires the WARP client in split-tunnel mode routing SMB traffic. (3) Printers and IoT devices: devices that cannot run a ZTNA agent need to stay behind a traditional network boundary — consider maintaining a small VPN segment for device-only access while migrating human user access to ZTNA. (4) Applications with IP-based authentication: some legacy applications authenticate users by their source IP — these cannot be migrated to ZTNA without application-layer changes because ZTNA changes the source IP seen by the application.
How do I configure device trust checks in ZTNA to replace VPN's implicit device trust?
VPN typically trusts any device that can authenticate — the VPN credential is the only gate. ZTNA platforms support device health verification as an additional access requirement. Cloudflare Access with WARP client: the WARP agent runs on user devices and reports device posture to Cloudflare. In Access Policy: add a device posture rule requiring Serial Number from Okta Device Trust, Disk Encryption enabled, or Carbon Black sensor active. Only devices meeting the posture requirement can access the protected application. Tailscale: integrates with Headscale or can use tagged nodes to identify managed devices. For Intune-enrolled devices: configure Tailscale to accept only devices with valid Intune compliance certificates. The posture check should verify: device is MDM-enrolled (ensuring corporate device), EDR agent is running and updated (endpoint protection active), and OS patch level meets a minimum version (known vulnerabilities not present). Set these as required conditions for access to your highest-sensitivity applications first.
How do I decommission the VPN after migrating all applications to ZTNA?
VPN decommissioning workflow: (1) Run a 30-day parallel period where ZTNA is fully deployed and VPN is available as fallback but not required. Monitor VPN usage logs during this period — any remaining VPN traffic indicates an application that was not migrated or a user who has not adopted ZTNA. Investigate all VPN usage and either migrate the application or document why it requires VPN (printers, IoT devices, specific protocols). (2) After 30 days of minimal VPN usage: notify all users that VPN will be decommissioned in 30 days. Provide the ZTNA access URLs for all applications that previously required VPN. (3) On decommission date: remove VPN client from device management deployment, disable VPN gateway authentication, and archive VPN configuration documentation. (4) For applications that cannot be migrated: maintain a minimal VPN configuration for those specific users (device maintenance team for printer access) rather than keeping full VPN infrastructure for all users. A 'stub VPN' for edge cases is acceptable; a full VPN deployment for user convenience is not the target state.
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.