VPN to Zero Trust Migration
Replace Implicit Trust with Verified Access
Legacy VPN gives attackers the keys to your network. Zero Trust Network Access grants per-application access with continuous posture verification — no network-level trust, no lateral movement. We deploy FortiGate ZTNA and FortiSASE with a phased coexistence strategy.
VPN Is a Liability, Not a Control
VPN was designed for a perimeter-based world. Once a user authenticates to the VPN, they are on the corporate network — with access to every subnet, server, and service reachable from that network segment. This is implicit trust, and it is the root cause of lateral movement in virtually every major breach.
Stolen VPN credentials are the number one initial access vector in ransomware attacks. VPN concentrators are high-value targets with a steady stream of CVEs. Split tunnelling creates data exfiltration paths. Full tunnel routing creates bandwidth bottlenecks. VPN was never designed for the modern hybrid workforce.
Zero Trust eliminates all of this by design. No network access. No implicit trust. Every access request is verified against identity, device posture, and context — continuously.
Three Principles of Zero Trust
Verify Explicitly
Always authenticate and authorise based on all available data points — user identity, device health, location, service or workload, data classification, and anomaly detection. Never trust a session based on network location alone.
Least Privilege Access
Limit user access to only the specific applications and resources required for their role. No network-level access. No broad subnets. Per-application micro-tunnels with just-in-time and just-enough-access controls.
Assume Breach
Design your architecture as if the attacker is already inside. Segment access, verify end-to-end encryption, use analytics for threat detection, and minimise the blast radius of any compromise. If one app is breached, no other app is reachable.
VPN vs ZTNA — Side-by-Side Comparison
| Aspect | Traditional VPN | ZTNA (FortiGate / FortiSASE) |
|---|---|---|
| Access Scope | Full network access (subnet-level) | Per-application access only |
| Trust Model | Implicit — trust after VPN login | Continuous verification per request |
| Lateral Movement | Possible — attacker can pivot across network | Impossible — no network-level access |
| Device Posture | One-time check at connection (if any) | Continuous — real-time tag updates |
| User Experience | Manual connect/disconnect, split tunnel issues | Always-on, transparent, seamless SSO |
| Scalability | VPN concentrator capacity limits | Distributed proxies, cloud-scale |
| Attack Surface | VPN portal exposed to internet (CVE target) | Applications hidden — no public exposure |
| Visibility | Connection logs only | Per-app access logs, user+device context |
4-Phase Migration Strategy
Endpoint Preparation
Deploy FortiClient with ZTNA module to all managed endpoints via Intune, SCCM, or GPO. Configure FortiClient EMS and establish connectivity with FortiGate/FortiSASE. Define posture check rules — OS version, antivirus, patch level, disk encryption, domain join status. Create ZTNA tags and verify tag assignment across the device fleet. This phase runs in parallel with existing VPN — zero disruption.
Web App Migration (Wave 1)
Configure ZTNA HTTPS access proxy rules on FortiGate or FortiSASE for the first wave of web applications — typically 5-10 low-risk internal apps (intranet, wiki, ticketing, HR portal). Create ZTNA server objects, access rules with posture tag requirements, and SAML/certificate authentication. Users access these apps via ZTNA while all other apps remain on VPN. Validate access, performance, and logging for each application.
TCP App Migration (Wave 2-N)
Migrate non-web TCP applications — RDP to jump servers, SSH to Linux infrastructure, database clients (SSMS, pgAdmin, Toad), thick-client ERP access. Configure ZTNA TCP forwarding access proxy rules. For each wave, validate application functionality, latency, and user experience. Progressively remove VPN access to migrated applications. Continue until all applications are on ZTNA.
VPN Decommission
Once all applications are validated on ZTNA, disable VPN tunnels and remove VPN configuration from FortiClient. Decommission VPN concentrators and reclaim IP addresses. Update firewall policies to deny VPN protocols. Run a 30-day monitoring period to catch any missed application dependencies. Document the final ZTNA architecture and update runbooks.
FortiGate ZTNA vs FortiSASE — Which Is Right for You?
FortiGate ZTNA (On-Premises Proxy)
- Uses your existing FortiGate as the ZTNA access proxy
- Traffic proxied through your data centre
- Ideal for on-premises applications
- No additional licensing beyond FortiOS 7.0+
- Leverages existing FortiGate HA cluster
- Best for: organisations with FortiGate infrastructure and on-prem-heavy workloads
FortiSASE ZTNA (Cloud-Delivered)
- ZTNA proxy runs in Fortinet's global PoP network
- Traffic routed to nearest cloud PoP
- Ideal for SaaS apps and remote-first teams
- Includes SWG, CASB, and DLP in one licence
- No hardware to manage — fully cloud-managed
- Best for: cloud-first organisations, distributed teams, BYOD
Many organisations use both — FortiGate ZTNA for on-premises applications and FortiSASE for SaaS and remote users. Both share the same FortiClient EMS and ZTNA tagging system, providing a unified policy framework.
ZTNA Architecture Components
FortiClient (Endpoint Agent)
Installed on every managed endpoint. Handles ZTNA tunnel establishment, device posture reporting, certificate-based device identity, and endpoint telemetry. Lightweight agent supporting Windows, macOS, iOS, and Android.
FortiClient EMS (Management)
Centrally manages FortiClient endpoints. Defines posture check rules, evaluates device compliance in real-time, and assigns ZTNA tags. Tags are synchronised to FortiGate and FortiSASE via Security Fabric connector. Provides endpoint visibility dashboard.
ZTNA Access Proxy (FortiGate/SASE)
The enforcement point. Receives ZTNA connection requests, validates user identity (SAML/certificate), checks device ZTNA tags, and proxies traffic to the protected application. Supports HTTPS (web apps) and TCP forwarding (non-web apps).
Who Needs VPN to ZTNA Migration
Hybrid Workforce Organisations
Your employees work from home, co-working spaces, and client sites. VPN creates bandwidth bottlenecks and poor user experience. ZTNA provides direct-to-app access without routing all traffic through HQ, improving performance and reducing infrastructure load.
Post-Breach Recovery
You experienced a breach where the attacker used stolen VPN credentials for initial access and lateral movement. ZTNA eliminates the attack path — no network access means no lateral movement, even with compromised credentials.
Regulated Industries (BFSI, Healthcare)
RBI CSCRF, SEBI CSCRF, and DPDPA all require least-privilege access and continuous monitoring. ZTNA provides per-application access with full audit trails — exactly what regulators expect. VPN's all-or-nothing access model fails these compliance requirements.
Third-Party & Contractor Access
Vendors and contractors need access to specific applications — not your entire network. ZTNA provides scoped, time-limited access to exactly the apps they need, with device posture enforcement. FortiSASE agentless ZTNA supports unmanaged BYOD devices via browser.
Ready to Eliminate VPN Risk?
Get a free ZTNA assessment. We will map your current VPN usage, identify high-risk applications, and design a phased migration plan — no obligation, no disruption.