ZTNA replacing VPN — what GlobalProtect, AnyConnect and FortiClient users need to know in 2026
Published 28 May 2026
· By
Pawan Sharma
· Fortinet / SASE
· 24 min read
Your VPN works. Mostly. It also generates the same six tickets every week, lets one compromised laptop reach every share on every server, throws random TLS errors at 9:15 on a Monday morning, and asks the helpdesk to walk a new joiner through a 14-step client install on day one. The frustrations are small individually — and architectural collectively. You can't tune them out of a VPN, because they're a consequence of what a VPN is. ZTNA, delivered through SASE, fixes them by changing the model: it grants access to applications, not networks, after checking who the user is and what state their device is in — every time.
Flat reach
The VPN problem in one phrase
Once a user authenticates, the routing table treats them like any other LAN host — full subnet reach.
9:15 AM
Concentrator peak
Every login storm hits the same hour. HA pairs get sized for it; nobody likes the bill.
Per-app
How ZTNA grants access
Not "the network" — the specific application, on the specific port, for the specific session.
Every connect
Posture, not just identity
OS patch level, AV state, disk encryption, EDR running — checked before access is granted.
The six small problems your users complain about every day
Nobody files a ticket called "our VPN architecture is wrong". They file tickets like the ones below — six everyday frustrations that are individually irritating, collectively expensive, and architecturally unfixable while you stay on a VPN concentrator model.
1 "I'm in, but I can see things I shouldn't."
The user dialled in to retrieve one file on one share. They now have routable reach to every Windows share on the corporate /16, the print server, the build infrastructure, the test database and the dev jumphost. That's not a privilege issue — it's how routing on a flat tunnel works.
ZTNA fix: the user gets an outbound session to one named application. No route, no broadcast, no other ports.
2 "The VPN is slow today" (Monday, 9:15 AM)
The Monday-morning login storm hits the same HA pair every week. Concentrators were sized for steady state — peak is twice that. TLS handshakes queue, IKE rekeys back up, and the helpdesk hears about it for an hour.
ZTNA fix: the SASE PoP is shared, elastic and globally distributed. There is no fixed concentrator to overload at 9:15.
3 "My laptop joined yesterday and I still can't connect."
New joiner gets a corporate laptop. The VPN client has to be installed manually, the profile imported, the certificate enrolled, the MFA seed paired and the user walked through the disconnect-reconnect dance. IT loses 45 minutes per joiner.
ZTNA fix: FortiClient EMS pushes the agent, profile, posture rules and trust anchors as part of zero-touch enrolment. The user signs in once with the corporate identity and the access works.
4 "The contractor's laptop is on the VPN."
You can grant a contractor a VPN account in five minutes. You can't easily check whether their laptop has BitLocker enabled, the EDR agent running, or last week's critical patches installed — and the VPN doesn't care.
ZTNA fix: every connection is gated by a posture check that runs on this connection. Out-of-date OS, missing EDR, encryption off → access denied or restricted, automatically.
5 "We can't tell who accessed what."
The VPN log says "user X authenticated, source Y, at time T". What did they actually do? Which servers, which apps, which records? That's reconstructed from disparate logs at three other places, after the incident, on a deadline.
ZTNA fix: every session is a named application access, logged centrally with user, device, app, time and bytes. The audit trail is application-level by design.
6 "One user clicked a link and now ransomware is spreading."
The user was on VPN. Their laptop got popped. The implant immediately tried — and succeeded — to reach the file server, the domain controller, and the application servers on adjacent subnets. The blast radius is the whole network, because that's what the VPN gave them.
ZTNA fix: the compromised laptop can only reach the applications the user was explicitly granted access to. Lateral movement is denied by architecture, not by hoping segmentation rules held.
Why a VPN can't fix any of these — the architectural reason
You can patch a VPN. You can tighten its split-tunnel policy, segment the destination network behind it, add MFA on the gateway, and force device certificates. Each one of those helps, and every one of them is a workaround for the same fact: a VPN's job is to put a remote user on the network. The trust model is binary — you're in or you're out — and the routing table is built for hosts that belong on a LAN.
The core mismatch
VPN trusts the network. ZTNA trusts neither network nor user.
Every protection on a VPN bolts onto a model that already trusts the user once they're connected. Network segmentation, micro-segmentation, NAC, host-based firewalls — each adds back a check the VPN itself never made. None of them undo the fact that a successful VPN login produced a routable presence on the corporate network.
ZTNA inverts that. There is no "on the network". There is "this user, on this device, with this posture, accessing this application, right now". Every condition is re-evaluated for every session. The network never becomes the trust boundary, because the network never gets to be a boundary at all.
What ZTNA fundamentally changes
| Dimension | VPN model | ZTNA model |
|---|---|---|
| Trust boundary | The network — once authenticated you're on it. | The application — every session is gated independently. |
| Identity | Checked once, at connect. | Checked per session, with conditional access policies. |
| Device posture | Often unchecked, or checked at connect only. | Continuous evaluation — OS, patch, AV, EDR, encryption. |
| Granularity | Subnet / VLAN. | Application + port + protocol + user + device. |
| Lateral movement | Possible — routing table allows it. | Denied by default — no route exists between apps. |
| Onboarding | Client install + profile + cert + MFA seed. | Agent push from EMS, identity-driven enrolment. |
| Scale | Concentrator HA pair — capacity-planned for peak. | SASE PoP — elastic, distributed, shared. |
| Audit | "User connected at T". | "User accessed app X on device D for N minutes". |
Device onboarding done right — FortiClient EMS + posture
The single most underrated reason to move to ZTNA is not the security story — it's that new-joiner laptops just work. FortiClient EMS pushes the agent, the policy, the posture rules and the trust anchors at enrolment. The first time the user signs in to the laptop, ZTNA access is live. No client install screenshots. No profile-import instructions. No "have you tried disconnecting and reconnecting".
▸ Zero-touch agent push
EMS deploys FortiClient with the correct telemetry, posture rules and trust anchors as part of enrolment.
▸ Identity-bound access
Sign-in to the corporate identity provider unlocks ZTNA access. No separate VPN credentials, no MFA seed pairing.
▸ Continuous posture
OS version, patch level, AV / EDR state, disk encryption, firewall state — evaluated on every connection.
▸ Posture-driven policy
Healthy device gets full access. Drift → restricted scope. Compromised → quarantined. No human-in-the-loop required.
▸ BYOD and contractor lanes
Unmanaged devices get a separate posture profile — clientless or thin-agent — that opens only the applications appropriate to the role.
▸ Off-boarding in seconds
Disable the identity, the next ZTNA session fails. No "deactivate the VPN account, revoke the cert, kick the live session" race.
SASE is the delivery — ZTNA is the access model
ZTNA on its own is a model, not a product. FortiSASE is the way that model arrives at the desktop. The same cloud-delivered fabric that runs FWaaS, SWG and CASB for outbound traffic runs ZTNA for inbound application access. It's the same agent (FortiClient), the same identity, the same posture data, the same policy plane.
The work-from-anywhere reality
Designed for the world your users already live in
The VPN model assumed "occasional remote". Modern enterprise has the opposite distribution — people work from home offices, from cafes, from client sites, from hotels, from airports, on home Wi-Fi and on cellular. They're not "remote" — they're distributed. The corporate network is one more thing they connect to, not where they live.
SASE was designed for that distribution. Identity, posture, application access, web filtering, CASB and DLP all happen at the nearest PoP, not at a concentrator in a single data centre. The user gets the same experience and the same security from anywhere — because there is no "anywhere else" to fall back to.
From GlobalProtect, AnyConnect or FortiClient VPN — what changes
The path off your current remote-access stack is the same in shape regardless of vendor — what's different is the order. The summary table below maps the typical migration sequence by incumbent.
| From | What stays | What you replace first | What you replace last |
|---|---|---|---|
| Palo Alto GlobalProtect | Identity provider (Azure AD / Okta / AD); MFA | Per-app access for the top 5 SaaS & internal apps; FortiClient EMS rolled out alongside GP | The GP gateway itself, once posture and per-app policy cover ≥90% of sessions |
| Cisco AnyConnect | Identity provider, certificate authority for device identity | ZTNA for internal HTTPS apps; FortiClient EMS rolled out alongside AnyConnect | AnyConnect gateway and ASA / FTD VPN config, once IPSec backhaul is gone |
| FortiClient VPN | FortiClient agent itself — EMS just gets new posture and ZTNA policy | The ZTNA tunnel mode replaces SSL-VPN dial-in for app access; EMS pushes the new profile | The FortiGate's SSL-VPN portal, once application coverage is complete |
| Home-grown OpenVPN / WireGuard | Identity provider | FortiClient EMS rollout + ZTNA for the highest-traffic internal app | The OpenVPN / WireGuard server, after one quarter of stability |
The cutover — a realistic 10-day plan
Day 1–2: inventory what users actually reach over VPN
Pull last 30 days of VPN logs. List the top 20 internal applications by session count, the top 20 by user count and the long tail. The top 20 are your first ZTNA policies — they cover the bulk of traffic with the least policy surface.
Day 3: stand up FortiSASE tenancy and FortiClient EMS
Provision the FortiSASE tenancy, bind it to your identity provider, and configure the FortiClient EMS profile with the right posture rules — OS, patch, AV / EDR, disk encryption.
Day 4: roll out FortiClient to a pilot of 20 users
Mix of IT, finance and ops. The agent runs alongside your existing VPN client. ZTNA policies cover the top 5 applications for these users.
Day 5–6: validate posture, performance, audit logs
Confirm denied / restricted access fires correctly on posture drift. Compare ZTNA latency vs VPN latency to the same app. Confirm the audit trail shows the application access at the granularity your auditors need.
Day 7–8: expand to 200 users and 20 applications
FortiClient EMS pushes to the next 200 users automatically. Add the next 15 apps to the ZTNA policy. The VPN is still up — users now have both paths.
Day 9: stop publishing the VPN URL to new joiners
Onboarding moves to ZTNA-only. Existing users get a deprecation note. Monitor "VPN fallback" usage — should fall to a trickle within a week.
Day 10: full rollout to remaining users
FortiClient EMS pushes the agent to the rest of the fleet. Each user has ZTNA access to every application they need. Decommission of the VPN concentrator is a separate, calmer conversation — typically 4-8 weeks later.
What gets better the day you cut over — and what gets better over the quarter
Day 1 of ZTNA
- New joiners onboard with no helpdesk ticket
- The 9:15 Monday "VPN slow" thread goes quiet
- Application access is per-app, lateral movement off the table
- Audit trail is application-level by default
- Compromised laptops can no longer reach the file server "as a network host"
Quarter 1 of ZTNA
- VPN concentrator licence renewal cancelled
- HA pair compute removed from the cloud bill
- Posture drift becomes a measured metric, not a guess
- Contractor / BYOD lane productised — IT stops bespoke-handling each one
- Internal apps that were "VPN-only" become candidates for hybrid-work UX (mobile, tablet) because access is per-app, not per-tunnel
The compliance story your auditor will love
The strongest single sentence in a SOC 2, ISO 27001, RBI or DPDP audit is "every user-to-application access is identity-bound, device-posture-bound, time-bound and logged at the application layer". That sentence is true on day one of a ZTNA deployment. It is approximately never true of a VPN.
A real outcome — anonymised
A mid-market Indian BFSI client, 400 staff, two offices + WFH
VPN concentrator HA pair, GlobalProtect for remote users, AnyConnect for the legacy users IT never migrated. Audit finding from last cycle: "Inadequate evidence of per-application access control for remote users." Every quarter the GRC team spent two weeks reconstructing access logs from VPN logs + Active Directory logs + application server logs.
Post-FortiSASE rollout: ZTNA per-app policy in place for all 47 internal applications and 12 SaaS. FortiClient EMS pushed posture rules aligned to RBI's baseline control set. Audit cycle: one report generated from the SASE console answered the finding directly. Time spent on the access-control evidence: 2 hours, not 2 weeks. Same posture data also satisfied the DPDP DPIA's "access control" section.
What about latency? What about performance?
This is the question every network architect asks first and it deserves a straight answer. ZTNA delivered through SASE adds a hop — the SASE PoP. For Indian users, Fortinet operates PoPs in-country with very low single-digit-millisecond added round-trip. For most internal applications hosted in an Indian cloud region or data centre, the user-perceived latency is better, not worse, because:
- The VPN tunnel was already adding overhead (IPSec / SSL framing, MTU and fragmentation, single concentrator hop).
- The PoP is geographically closer to most users than the corporate concentrator was.
- Session establishment is faster — no IKE rekey, no PHASE-2 dance, no fragmentation-induced retransmits.
- Most internal apps are HTTPS — HTTP/2 over a SASE PoP outperforms HTTPS-over-IPSec on the same network.
For a small number of latency-sensitive flows — interactive remote-desktop, voice, screen-share — the SASE PoP routing is tuned and the performance is at parity with direct connection in our experience. Validate this in the pilot phase (Day 5–6 above); if it isn't true for one of your apps, the policy carves it out.
FAQ
Do we have to replace our VPN all at once?
What about non-HTTPS internal apps — SSH, RDP, thick clients?
How does ZTNA handle unmanaged devices — BYOD, contractors?
Does ZTNA work without an internet connection — air-gapped users?
What posture checks does FortiClient EMS run?
How do users authenticate — does ZTNA replace our identity provider?
What does this cost compared to keeping the VPN?
How do we prove this works before committing?
Free 14-day ZTNA pilot — work from anywhere, securely
Replace one VPN frustration this fortnight. See the rest go in the next.
Ogma stands up a FortiSASE tenancy, rolls FortiClient EMS to a 20-user pilot, configures ZTNA for your top five applications and runs a full posture assessment on the pilot fleet. Inside 14 days you'll have hard data on user experience, audit-trail depth and posture compliance — against your applications and your users.
Request the 14-day ZTNA pilot or explore Ogma as your Fortinet partner in IndiaSources (official documentation only)
- docs.fortinet.com/product/fortisase — FortiSASE Admin Guide (ZTNA, identity, posture)
- docs.fortinet.com/product/forticlient — FortiClient EMS administration, posture rules
- fortinet.com/products/sase — FortiSASE datasheet and tier structure
- fortinet.com/products/ztna — Fortinet ZTNA datasheet (tunnel mode, posture, EMS)
- CERT-In and CISA public advisories on VPN gateway exploitation patterns — referenced by class, not specific advisory.
Related: How FortiSASE shrinks your AWS / Azure cloud bill · Fortinet Partner India · Talk to Ogma
Stay ahead of cyber threats
One short email a week — curated Indian cybersecurity news, Fortinet releases, DPDPA updates. No fluff.
