Modernizing Remote Access Architecture

From SSL VPN to Zero Trust Network Access (ZTNA/SSE)

Intended for: IT Managers, CIOs, CISOs, and Infrastructure Managers

Executive Summary

Fortinet is phasing out SSL-VPN tunnel support across new FortiOS releases, and SSL-VPN gateways remain a leading target for exploitation. This document evaluates two remediation paths: an interim migration to IPsec VPN within the existing FortiGate estate, and a strategic shift to a cloud-delivered Security Service Edge (SSE) architecture built on Zero Trust Network Access (ZTNA). IPsec improves the cryptographic posture of remote access but preserves an internet-facing gateway and therefore the underlying exposure. SSE/ZTNA removes the inbound attack surface entirely by replacing network-level tunnels with per-application, identity-based access. The recommendation is to treat IPsec as a bridge, not a destination, and to plan a phased migration to SSE as the target architecture.

1. Background and Drivers for Change

Fortinet has announced the deprecation of SSL-VPN tunnel functionality in upcoming FortiOS releases, in parallel with a sustained increase in CVEs and active exploitation campaigns targeting SSL-VPN gateways. Because these gateways are internet-facing by design, they constitute a persistent, scannable attack surface regardless of patch cadence. This creates both a security and a lifecycle-management driver to re-evaluate the remote access architecture rather than simply patch the existing model.

2. Strategic Solution: SSE Architecture and Zero Trust Network Access (ZTNA)

Security Service Edge (SSE) reframes remote access around identity and application context rather than network-level connectivity, eliminating the need for a routable tunnel into the corporate network.

• Zero Trust enforcement: Access is brokered per application based on user identity, device posture, and contextual risk signals, rather than granting broad Layer 3/4 network reachability.
• Elimination of the inbound attack surface: Because the connection is broker-initiated through the cloud, there is no listening inbound service exposed to the internet – nothing to port-scan or fingerprint.
• Operational continuity: An always-on agent maintains transparent, low-friction connectivity without a manual VPN dialer, while enforcement follows the user regardless of location.
• Infrastructure elasticity: Enforcement capacity shifts from fixed on-premises appliances to an elastic, globally distributed cloud fabric, removing local throughput and concurrent-session ceilings.

3. Completing the Defense Envelope: Secure Web Gateway (SWG)

The SWG capability integrated into SSE closes a gap that traditional VPN architectures never addressed: protection of general internet and SaaS traffic, not just access to internal resources.

• Location-independent enforcement: Policy enforcement is tied to the user and device rather than the network perimeter, so protection is identical on-network and off-network.
• Inline threat inspection: Traffic is inspected in real time for malware and command-and-control activity, engineered to avoid perceptible latency in the browsing experience.
• DNS-layer security: Requests to known-malicious domains are blocked at the DNS layer before a session is established, reducing dwell time for phishing and malware delivery.

4. Interim Alternative: Migration to IPsec VPN

For organizations that need to remain on their existing FortiGate estate in the near term, migrating from SSL-VPN to IPsec VPN is a viable bridge.

Characteristics

• IPsec VPN retains a tunnel-mode architecture but replaces the SSL/TLS-based protocol with IPsec, which offers a materially stronger cryptographic foundation (IKEv2, AES-GCM) than legacy SSL-VPN.
• Centralized management: Organizations that standardize on FortiClient EMS gain centralized client provisioning, certificate/policy distribution, and compliance (posture) checks across endpoints.

Limitation

IPsec VPN still relies on an internet-facing inbound gateway identical in principle to the SSL-VPN model it replaces. The organizational endpoint remains discoverable through internet-wide scanning, so the fundamental exposure – as opposed to only the encryption weakness – is not resolved.

5. Recommendation

IPsec VPN is a legitimate, functional short-term improvement over SSL-VPN and should be adopted immediately wherever SSL-VPN is still in use, given the imminent end-of-support timeline. It does not, however, resolve the structural exposure of an internet-facing gateway. The recommended target plane Anda full SSE/ZTNA architecture, which eliminates the inbound attack surface, consolidates SWG-based protection for all internet and SaaS traffic under a single policy plane, and aligns with the broader industry migration toward Zero Trust. Organizations should treat IPsec as a bridge with a defined sunset date, not as a long-term architecture, and begin SSE pilot deployments in parallel.