Fortinet Engage Advocate Partner, Integrator

VPN to ZTNA Migration Guide

How to migrate from VPN to ZTNA.
The FortiGate method, step by step.

FortiOS 7.6.3 removed SSL-VPN tunnel mode from every FortiGate. This is the seven-step method we use to move an office to ZTNA with FortiClient EMS, with an exit test for each step.

Short Answer

How to migrate from VPN to ZTNA on a FortiGate, in seven steps.

  1. Inventory. List every SSL-VPN user and the applications they reach, from 30 days of FortiGate logs.
  2. Identity and MFA. Connect the FortiGate and FortiClient EMS to your identity provider with SAML, and enforce MFA there.
  3. EMS and posture. Deploy FortiClient EMS, authorize the EMS connector on the FortiGate so certificates and tags sync, and define ZTNA tags such as OS patched and endpoint protection running.
  4. Application rules. Build least-privilege ZTNA rules per application, matching the inventory.
  5. Pilot. Move about ten percent of users for two weeks, with SSL-VPN still running in parallel.
  6. Cutover. Move groups weekly and disable SSL-VPN for each group after it moves.
  7. Decommission. Disable SSL-VPN, remove the portal, close the port on the WAN policy and document the final rules.

Before step 1, confirm the model can run ZTNA at all (readiness list below). Each step has an exit test (full step table below); typical timeline four to six weeks for 20 to 200 users, confirmed after scoping.

Why Now

SSL-VPN is leaving FortiGate. ZTNA is the replacement.

FortiOS 7.6.0 removed SSL-VPN tunnel and web mode from 2 GB-RAM FortiGates, and FortiOS 7.6.3 removed tunnel mode from every FortiGate, including the G-series models. Fortinet's release notes name IPsec VPN as the direct replacement for tunnel mode; ZTNA is the per-application option, and the one this guide covers. If your remote staff log in through a FortiGate SSL-VPN portal today, a migration is on the calendar whether you plan it or not. Plan four to six weeks for 20 to 200 users, including a pilot and an agreed cutover window. Moving remote users to IPsec instead, or upgraded already and locked out? Start at the FortiGate SSL-VPN migration page.

What ZTNA changes

SSL-VPN is the older remote-access VPN Fortinet is retiring. ZTNA (zero trust network access) checks who the user is and what device they are on for every application. SSL-VPN firewall policies determine which resources users can reach; agent-based ZTNA adds device identity and posture checks to per-application access policies. FortiClient reports device health (patched, antivirus running) to FortiClient EMS, Fortinet's device-management server; the FortiGate enforces per-application rules with ZTNA tags.

What stays the same

Users still run FortiClient. The FortiGate still terminates the session. Your identity provider (Microsoft Entra ID, Google or Okta sign-in) still authenticates. The change is in policy granularity: access is granted per application and checked against device identity and posture.

What it costs

FortiClient EMS licensing (ZTNA is included in the EMS license tiers; the quote specifies the license metric, bundle and term), plus the project. We do the migration as a ZTNA project, or as part of a firewall migration (from $6,500).

What goes wrong unplanned

A firmware upgrade to 7.6.3 or later removes SSL-VPN tunnel mode (2 GB models lose it from 7.6.0) and remote staff are locked out on a Monday morning. It can happen to any office that was not warned. Still on a FortiGate 60E? It is not supported on 7.6 at all and reaches end of support on December 29, 2026; see FortiGate 60E end of life replacement.

Readiness

Is your FortiGate ready for ZTNA? A short checklist.

Fortinet's migration guide notes that when users sit in an external directory and FortiClient is already managed by EMS, most ZTNA building blocks are in place. Confirm each line before step 1.

  • FortiGate RAM above 2 GB. 2 GB models (40F, 60F and 50G series) cannot run the ZTNA access proxy; see the FAQ for the check. FortiGate VMs are not affected.
  • FortiOS version known and release notes read before any 7.6 upgrade.
  • Users and groups in a directory. Active Directory, Entra ID, Okta or Google, not only local FortiGate users.
  • FortiClient EMS licensed for ZTNA. EMS must be reachable by clients from everywhere; Fortinet's example places it in a DMZ.
  • A way to push FortiClient. An existing software-deployment tool, EMS's own Windows deployment, or a download link for the rest.
  • MFA on the identity provider. Integrated with the FortiGate through SAML.
  • DNS and certificates. External DNS records you control for each application FQDN, and a certificate whose Subject Alternative Names cover them.
  • Applications sorted by type. Web apps and TCP apps (RDP, SSH, SMB).
  • Logging destination ready. See logging before cutover in the design notes.

The Method

Seven steps from SSL-VPN to ZTNA on FortiGate.

This is the order we run a VPN to ZTNA migration on FortiGate. Each step has an exit test; nothing moves to the next step until the test passes.

StepWhat happensExit test
1. InventoryList every SSL-VPN user, group and the applications they reach: RDP hosts, file shares, web apps, printers. Pull it from the FortiGate logs for 30 days, not from memory.A spreadsheet of user → application pairs with last-used dates
2. Identity and MFAConnect the FortiGate and EMS to your identity provider (Entra ID, Google, Okta) with SAML (single sign-on); enforce MFA (a second check beyond the password) there, not on the firewall.A test user completes SAML sign-in with MFA against the FortiGate
3. EMS and postureDeploy or upgrade FortiClient EMS; authorize the EMS connector on the FortiGate and confirm it syncs; define ZTNA tags (OS patched, AV running, disk encrypted); push FortiClient with the EMS connection to the pilot group.Pilot devices show tags in EMS and on the FortiGate
4. Application rulesBuild ZTNA server definitions and rules per application, least privilege, matching the inventory. Dead applications are not migrated.Pilot users reach only their listed applications
5. PilotTen percent of users for two weeks, including the most vocal ones. Keep SSL-VPN running in parallel.Zero unresolved pilot tickets for five business days
6. CutoverMove groups weekly; disable SSL-VPN per group after each move; watch the logs for anyone still hitting the old portal.No SSL-VPN sessions in 7 days
7. DecommissionDisable SSL-VPN, remove the portal, close the port on the WAN policy, document the final rule set.External scan shows no SSL-VPN listener; as-built delivered

Plan on four to six weeks for 20 to 200 users; the pilot and group moves take the bulk of it. The schedule is confirmed after scoping the identity integration, EMS configuration, application rules, pilot and cutover. Programs with several identity providers or more than 500 users start with the assessment.

Design Notes

Decisions that decide whether it works.

Four choices made early save the project later.

Agent or agentless

FortiClient (the agent, a small program installed on each laptop) gives device-health checks and works for remote desktop and installed applications, not just web apps. Agentless ZTNA through the browser (FortiOS 7.6.1 and later) covers web applications and portal bookmarks for RDP, SSH and file shares, but without device-health checks. Plan on the agent for at least the IT and finance groups.

Posture rules you can actually enforce

Start with two tags: OS patch level and endpoint protection running. Add disk encryption when every laptop can pass it. A rule nobody can pass is a help-desk flood, not security.

Site-to-site stays IPsec

ZTNA is for users. Branch offices, cloud VPCs and partner tunnels stay on IPsec; migrate them separately if at all. Two internet lines at a site? See SD-WAN migration.

Logging before cutover

Turn on ZTNA logging to FortiAnalyzer (Fortinet's log server) or any syslog collector before the pilot so the first access denial is diagnosable in a minute, not an hour.

Pitfalls

Common VPN to ZTNA migration mistakes.

  • Missing DNS or a certificate SAN. Users see browser certificate errors on the ZTNA portal or access proxy.
  • Treating RDP and SSH like web apps. TCP forwarding needs a ZTNA destination rule in FortiClient for each app, normally pushed from EMS. Windows 7 endpoints cannot use TCP forwarding.
  • Using the free VPN-only FortiClient. ZTNA tags and posture checks need licensed FortiClient managed by EMS.
  • Deleting SSL-VPN before the last group has moved. See the FAQ for Fortinet's shutdown order.

Track Record

The numbers behind the outcomes.

We only do networks. That is not a limitation — it is why the outcomes are different.

Engineering
20+

Years of network-only practice. Architecture, security, and operations — not IT generalism.

Delivery
300+

Sites delivered. Healthcare clinics, law offices, financial branches, multi-site operations.

Availability
99.99%

Design target for fully redundant builds with HA firewalls, diverse ISPs, and backed-up power.

Ownership
100%

Senior engineer–led. No junior handoffs. No ticket queue. No escalation chain.

Career aggregate. The 20+ years and 300+ sites span the operator’s full network-only practice, including prior-employer engagements. 99.99% availability, about 53 minutes of downtime per year, is an architecture design target for engagements that fund full redundancy. It is not a service guarantee or uptime SLA. Contracted response times and service levels are defined in each customer agreement.

Where We Work

Sacramento, the Bay Area, and remote across California.

Pre-staging and configuration happen remotely; cutover is on site or remote-hands guided, your choice. For on-site work, see our Fortinet MSP in Sacramento, Sacramento network management and Fortinet MSP in San Francisco pages. Replacing a non-Fortinet firewall? See firewall migration. Want it watched afterward? See network monitoring. Not sure what else the firewall is carrying? Start with a Network Risk Assessment.

FAQ

VPN to ZTNA questions.

How do I migrate from VPN to ZTNA on a FortiGate?

Inventory the SSL-VPN users and the applications they actually reach from 30 days of logs; connect the FortiGate and FortiClient EMS to your identity provider with SAML and MFA; define posture tags in EMS; build per-application ZTNA rules; run a two-week pilot alongside SSL-VPN; move groups weekly; then disable SSL-VPN and close the port. Plan on four to six weeks for an office of 20 to 200 users, confirmed after scoping.

Is SSL-VPN really being removed from FortiGate?

FortiOS 7.6.3 removed SSL-VPN tunnel mode from every FortiGate; 7.6.0 had already removed tunnel and web mode from 2 GB-RAM models such as the 40F, 60F and 61F. The 30G and 50G never supported SSL-VPN; support on the 70G and 90G depends on the FortiOS release, so check the exact model and version before upgrading. Fortinet's documented direction is IPsec and ZTNA.

Do I need FortiClient EMS for ZTNA?

For agent-based ZTNA with posture checks, yes. EMS issues the client certificate and tags that the FortiGate enforces. Agentless browser-based ZTNA (web apps, and portal bookmarks for RDP and SSH from 7.6.1) does not need an agent on the device but still uses the FortiGate as the proxy.

What does ZTNA licensing cost?

ZTNA capability is part of FortiClient EMS licensing. The license metric, bundle and term vary by part number; ask us for a quote by part number, which specifies all three. The FortiGate side needs no extra license.

What does the migration project cost?

It is quoted after scoping. The project covers policy design, the agent or agentless rollout plan, a pilot group and cutover of the existing SSL-VPN population; the fee depends on how many users, rules and applications move, so we price it after a short review of your current setup. Conversion can be included within the agreed firewall migration scope; additional users, applications or identity work are quoted after scoping. Larger programs with multiple identity providers or more than 500 users start with a Network Risk Assessment.

Can ZTNA replace site-to-site VPN too?

No. ZTNA governs user-to-application access. Site-to-site links between offices and cloud networks stay on IPsec, which FortiGate handles with SD-WAN steering if you have two circuits.

Will users notice?

Yes, in a few specific ways. Sign-in moves to your identity provider with MFA; laptops run FortiClient managed by EMS, and some applications may open from a browser portal instead; a user who is not entitled to a server is denied access to it. The pilot runs each group's daily workflows through these changes before SSL-VPN is switched off.

Can a FortiGate 40F or 60F run ZTNA?

Not as a ZTNA application gateway. From FortiOS 7.4.4, models with 2 GB RAM or less, including the 40F, 60F and 50G series, no longer support the ZTNA access proxy and its objects. From FortiOS 7.6.3, ZTNA tags in IP/MAC-based access control are supported again on those models, so EMS posture tags can still be used in firewall policies, for example alongside IPsec VPN. Run diagnose hardware sysinfo conserve; a total under 2000 MB means the unit is affected. For per-application ZTNA, replace the firewall with a larger model.

Can users reach RDP or SSH through ZTNA without FortiClient?

Yes, on FortiOS 7.6.1 and later. The ZTNA web portal gives browser access without FortiClient or a client certificate check, with bookmarks for RDP, SSH, SMB, VNC, SFTP and web applications. Without the agent there is no device posture check, so keep FortiClient for groups that need it.

Do we have to turn SSL-VPN off on day one?

No. Fortinet's migration guide keeps SSL VPN running for users who have not moved yet, disables the SSL VPN policies once ZTNA access is verified, then turns off SSL-VPN and disables the Remote Access profile in EMS.

What if a FortiOS upgrade already removed our SSL-VPN?

Assess before you roll back. Check that the previous image is still on the unit, that you have a configuration backup from that release, that you still have management or console access, and which security fixes the older release lacks. If all of that checks out, booting the previous image in a maintenance window can restore access for the length of this migration; otherwise, set up supported remote access such as IPsec VPN first. Call us the same day at (916) 915-3335 if you are locked out.

Sources

Checked against primary sources.

Last reviewed October 24, 2026. Vendor documents and prices change; confirm against the linked pages before you decide.

Fortinet, FortiGate, FortiOS, FortiGuard and FortiCare are trademarks of Fortinet, Inc. Other vendor names are trademarks of their respective owners, used to identify the products discussed. Ambio Edge Networks is an independent Fortinet partner and is not affiliated with or endorsed by any vendor named here.

Plan the Migration

Send us your FortiGate model and user count.
Get a migration plan and a fixed quote.

Tell us the model and FortiOS version, how many SSL-VPN users, your identity provider, and whether you already run FortiClient EMS. We return a plan with the pilot group and dates, and a written quote for the ZTNA migration, or confirm it fits inside a firewall migration. Want the whole firewall reviewed first? A Network Risk Assessment is $3,500 for a single small site; larger networks are priced on the assessment pricing page. See a sample report (PDF).

What Happens Next

Response from a senior engineer within 1 business day.

A direct conversation — no sales team, no runaround.

An honest assessment of whether we are the right fit.

Clear next steps if we are — no pressure if we are not.

Schedule a conversation Call