How to Migrate from FortiGate SSL VPN to ZTNA: A Step-by-Step Guide for 2026

When an SSL VPN deadline approaches, many organisations default to IPsec because it feels like the simplest replacement. It works quickly and is familiar, but it still relies on a tunnel that gives authenticated users a path into the network.

Fortinet ZTNA uses a fundamentally different access model. Instead of placing users on the network, it gives them access to specific applications through an access proxy on the FortiGate. Before the connection is allowed, the device's security posture is evaluated. There is no network tunnel, no broad network-level access, and far less opportunity for lateral movement if an endpoint is compromised.

However, moving from SSL VPN to ZTNA is not a matter of replacing one configuration with another. It is a structured migration project, and the order in which you approach it has a direct impact on the outcome.

Why Choose ZTNA Instead of Another VPN?

If you have to undertake a remote-access migration anyway, it is worth considering where you want that migration to take your organisation.

Three factors generally make ZTNA the more attractive destination.

• You may already have much of the required technology: ZTNA functionality is included with FortiOS, so there is no standalone ZTNA product to buy. FortiClient EMS is still required for endpoint management and certificate issuance, which means there is a licensing cost. However, organisations that already use FortiClient EMS typically face very little additional expenditure.

• Access policies become consistent: Traditional VPN environments often create different access experiences for remote and office users. ZTNA can enforce the same application-level access controls regardless of whether an employee is working from an office in Gurugram or connecting from a hotel network in Singapore.

• VPN gateways remain a significant attack surface: Remote-access infrastructure has consistently attracted attacks because compromising the gateway can provide a route into the network. Removing the tunnel eliminates an entire category of attacks associated with tunnel-based remote access.

There is also an important timing consideration. FortiOS 7.4 reached the end of its engineering support period in May 2026, while SSL VPN tunnel mode is removed in FortiOS 7.6.3. Organisations currently operating SSL VPN on FortiOS 7.4.x should verify their specific branch lifecycle with Fortinet before deciding on their migration timeline.

How Fortinet ZTNA Works

Understanding the underlying architecture is essential because many ZTNA migrations fail when one of the required components is overlooked.

FortiGate ZTNA relies on four key elements working together.

• FortiClient EMS acts as the certificate authority: When an endpoint registers with EMS, it receives a unique client certificate. FortiGate uses this certificate to identify and establish trust in the device. If the endpoint has not registered with EMS, it will not receive the required certificate and cannot access ZTNA-protected resources.

• FortiClient runs on the endpoint with its ZTNA functionality enabled: Installing a basic VPN-only version of FortiClient is not sufficient. The ZTNA module must be installed, and the endpoint needs to be managed.

• FortiGate connects to EMS through the EMS connector: After the connection is authorised, FortiGate can synchronise endpoint security-posture information from EMS. Fortinet documentation may refer to these as ZTNA tags or security posture tags.

• EMS tagging rules determine device trust: Administrators can define conditions based on factors such as operating-system version, disk encryption, antivirus status and domain membership. EMS assigns tags according to those conditions, and FortiGate access policies use those tags when deciding whether access should be granted.

The resulting connection process is straightforward:

1. The user requests access to an application.

2. FortiGate's access proxy validates the device certificate.

3. The device's current posture tags are evaluated.

4. The user's identity and group membership are checked.

5. If all required conditions are satisfied, FortiGate proxies the connection to the internal application.

One implementation detail deserves particular attention. If FortiClient EMS is located behind the FortiGate, remote endpoints must be able to reach EMS during registration. In this scenario, a VIP forwarding TCP port 8013 is required. Missing this configuration can prevent the entire remote-endpoint onboarding process from working.

Selecting the Right ZTNA Access Proxy

FortiGate provides two primary methods for publishing applications through ZTNA. Choosing the appropriate one for each application is an important part of the design.

HTTPS access proxy is intended for browser-based applications. The user connects to the access-proxy address, and FortiGate forwards the request to the internal web server once the required security checks succeed. From the user's perspective, the main requirement is having a properly registered FortiClient endpoint. This approach is the closest ZTNA equivalent to an SSL VPN web portal.

TCP forwarding access proxy is designed for non-browser TCP services such as RDP, SSH and SMB. The endpoint connects using the destination service's IP address and port, while FortiClient encapsulates the traffic within HTTPS over port 443 to FortiGate. FortiGate then decrypts the proxied connection and forwards it to the internal service.

In practice, most organisations require both proxy types. That makes application classification one of the most useful exercises to complete before beginning the actual migration.

A Practical Phased Migration Plan

Fortinet recommends moving workloads incrementally rather than attempting a single large-scale cutover. That approach also reduces operational risk.

Phase 1: Create Your Application Inventory

Begin by documenting every resource currently accessed through SSL VPN.

For each application or service, record:

• The protocol it uses

• The user groups that require access

• The approximate number of users

• The type of access it requires

Once the inventory is complete, sort the applications by user count, starting with the smallest audience.

This is intentional. Your first migration should involve a resource on which relatively few employees depend. If an unexpected issue appears, the impact is limited instead of affecting the entire organisation.

Phase 2: Establish the ZTNA Foundation

This stage should happen without changing the end-user experience.

Deploy FortiClient EMS if it is not already part of your environment. If EMS is already deployed, verify that it can provide the certificates required by ZTNA.

Next:

• Authorise the EMS connector on FortiGate.

• Confirm that security posture information is synchronising.

• Publish EMS through TCP 8013 if it is located behind the firewall.

• Define the device-posture tagging rules.

Do not make the initial posture requirements unnecessarily strict.

For example, requiring every endpoint to be fully patched, encrypted and domain joined from the first day could immediately exclude legitimate users and turn the migration into a support exercise. Start with practical controls and strengthen them progressively.

Phase 3: Prepare User Endpoints

Deploy FortiClient with the ZTNA module through EMS.

Then verify that endpoints:

• Successfully register with EMS

• Receive their client certificates

• Receive the expected posture tags

Keep the existing SSL VPN configuration active throughout this stage.

An endpoint can maintain both configurations simultaneously, allowing you to prepare the environment without disrupting users.

Phase 4: Publish the First Application

Create a ZTNA server configuration on FortiGate.

This involves defining:

• The access-proxy VIP users will connect to

• The internal server mapping

• The ZTNA policy connecting the application, user group and device posture requirements

Start with a small pilot group.

Validate the entire access path before expanding it to additional users. The underlying access-proxy configuration is also covered in our companion article, How to Migrate FortiGate SSL VPN to IPsec VPN.

Phase 5: Migrate Users and Applications Incrementally

Move one application and one user group at a time.

After confirming that the new ZTNA path works correctly, remove that group's access to the same resource through SSL VPN.

This final step is easy to overlook.

If the legacy VPN route remains available, users are likely to return to it whenever the new process feels unfamiliar. Over time, the organisation ends up maintaining both environments indefinitely.

Phase 6: Decommission SSL VPN

Once every application and user group has successfully transitioned:

1. Remove the remaining SSL VPN portals and policies.

2. Create a fresh configuration backup.

3. Confirm that the migration is complete.

4. Upgrade to FortiOS 7.6.3 or a later supported release.

Do not reverse that order.

What Should Not Be Migrated to ZTNA?

ZTNA is not automatically the correct solution for every workload. Identifying exceptions early prevents problems later.

• Resources requiring broad network access: If a user genuinely needs access to an entire subnet rather than specific applications or services, ZTNA may not be appropriate. Certain engineering and infrastructure use cases fall into this category.

• Endpoints that cannot run FortiClient: ZTNA relies on the endpoint certificate and device posture information. Devices that cannot run or be managed by FortiClient therefore require another access mechanism. This can include unmanaged contractor devices as well as embedded or industrial systems.

• Applications incompatible with proxy-based access: Applications that use unusual ports, peer-to-peer communication or connections initiated from the server toward the client require careful testing before migration.

• Legacy authentication dependencies: Applications using older Windows authentication mechanisms should be validated against the specific FortiOS release before being included in the migration plan.

• For many organisations, the remaining exceptions represent only a small portion of their environment. A practical hybrid model is to retain a limited IPsec tunnel for those workloads while moving everything else to ZTNA. That is a valid target architecture, not an unsuccessful migration.

Not sure where your applications belong? Share your SSL VPN portal configuration with us, and we can help classify your resources into HTTPS proxy, TCP forwarding or alternative-access categories. Request an application access audit.

How Long Does the Migration Actually Take?

Be cautious with migration estimates that do not account for application volume. FortiGate configuration is only one part of the project. The number of applications you need to publish—and how well those applications are documented—is usually the bigger variable.

The quality of your initial inventory has one of the biggest effects on project duration.

Organisations with a well-documented application environment can move through the migration relatively quickly. Teams that discover applications and dependencies during implementation should expect a much longer process.

If the upgrade deadline is too close to complete a full ZTNA rollout, there is another practical option.

Move to IPsec first to maintain remote connectivity and create additional time for a properly planned ZTNA project. We discuss this approach in FortiOS 7.6.3 Removed SSL VPN Tunnel Mode: Your Migration Options.

Where Should You Begin?

If your FortiOS upgrade deadline is still several months away, start with the application inventory.

It is the foundation for everything that follows, and you can complete this work immediately without making production changes.

If the deadline is only a few weeks away, moving to IPsec first may be the safer option. That keeps remote access operational while giving your team the time required to design and implement ZTNA properly.

Trying to rush the ZTNA project can result in overly permissive policies that undermine the security model you were trying to introduce in the first place.

The overall sequence is straightforward:

Inventory → Foundation → Endpoints → First application → Group-by-group migration → SSL VPN retirement

NetNXT is a Fortinet partner and supports organisations across India with these migrations, including FortiClient EMS deployment and device-posture policy implementation.

If you want a structured migration roadmap instead of starting from scratch, book a phased ZTNA rollout plan and we can scope the approach around your existing environment.

FAQs

1) Does Fortinet ZTNA require additional licensing?

There is no separate ZTNA product. The functionality is included in FortiOS. However, FortiClient EMS is required for endpoint management and certificate issuance, and EMS uses endpoint-based licensing. Organisations that do not already have EMS should therefore include this cost in their migration budget.

2) Can SSL VPN and ZTNA operate simultaneously?

Yes. Running both during the transition is recommended. Keep the SSL VPN configuration available while applications are migrated individually. Once a particular user group has successfully transitioned to ZTNA, remove its corresponding SSL VPN access.

3) Can ZTNA protect RDP and SSH as well as web applications?

Yes. Web applications can use the HTTPS access proxy, while RDP, SSH, SMB and other TCP-based services can use TCP forwarding. In the latter model, FortiClient carries the connection through HTTPS to FortiGate, where it is proxied to the internal service.

4) What happens when a device fails its posture check?

The ZTNA session is denied until the endpoint once again satisfies the required security conditions. This is why posture policies should be introduced carefully. Establish a practical baseline first and gradually strengthen the requirements rather than applying maximum restrictions on the first day.

5) Is ZTNA more difficult to deploy than IPsec?

Yes. An IPsec migration can be relatively close to a like-for-like replacement and may be completed quickly by an experienced engineer. ZTNA requires considerably more preparation. You need EMS, endpoint deployment, certificate management, posture policies and application-by-application access configuration. The trade-off is a stronger application-centric security model, but the implementation should be planned in weeks rather than hours.