# Why the SSL-VPN is being dismantled, and what is actually replacing it > FortiOS 7.6.3 removed SSL VPN tunnel mode from every FortiGate, and existing settings are not carried over on upgrade. That is a verified fact with real operational consequences. The claim that every vendor is abandoning SSL-VPN is more complicated, and most of the timelines circulating are published by companies selling the replacement. Here is what is established, what is inference, and what a practitioner should actually do. Source: https://ronutz.com/en/learn/the-ssl-vpn-is-being-dismantled Updated: 2026-09-08 --- ## The fact, first Fortinet's own release notes are unambiguous. **FortiOS 7.6.3 removes SSL VPN (a virtual private network carried over TLS) tunnel mode entirely** - not on entry-level models, not by licence tier, but from every FortiGate, in the graphical interface and the command line. Existing tunnel-mode configuration is **not migrated** when the firmware is upgraded, which means an unplanned upgrade disconnects every remote worker at once and there is no rollback of the settings. Web mode survives under a new name, **Agentless VPN**, and is itself unsupported on several current model families. The phase-out began earlier on 2 GB memory models, and the G-series never shipped with it at all. Anyone running remote access on a FortiGate needs that paragraph, and needs it before a maintenance window rather than during one. The rest of this article is about why it happened and what the honest state of the wider industry is. ## What Fortinet says, and what the record says The stated reasons are reasonable and mostly technical: memory constraints on small appliances, IPsec's hardware acceleration on Fortinet's own silicon, standardisation on one remote-access stack, and better integration with multi-factor and SAML authentication. The replacement is IPsec, which can be configured to listen on TCP port 443 so that it traverses the same restrictive networks SSL-VPN was chosen for in the first place. The reason the vendor does not put in a release note is the CVE record. Fortinet's SSL-VPN carried a chain of flaws that were exploited in the wild: CVE-2018-13379, a path traversal that exposed plaintext credentials on tens of thousands of devices and which remains in the United States government's catalogue of known exploited vulnerabilities years later; CVE-2022-42475, a heap overflow in the SSL-VPN daemon used against unpatched devices; CVE-2023-27997, a pre-authentication heap overflow reachable on every SSL-VPN appliance, where multi-factor authentication was no defence because the flaw was reached before authentication; and CVE-2024-21762, an out-of-bounds write that entered the same catalogue within days. And then the detail that matters more than any of them. In April 2025 Fortinet disclosed that attackers who had exploited the earlier flaws had left a **symbolic link between the SSL-VPN user filesystem and the device's root filesystem**, retaining read-only access to configuration files - including credentials - *after the vulnerability was patched*. The company stated plainly that organisations which patched promptly could still be affected if the device had been compromised beforehand. Removing the feature removes the class of problem in a way that patching it demonstrably did not, which is the same reasoning the [worm era](https://ronutz.com/en/learn/the-worm-era) records behind turning the Windows firewall on by default. ## Why this class of product concentrates risk Strip away the branding and an SSL-VPN concentrator is a specific and uncomfortable object: **an unauthenticated listener on TCP 443, which must be reachable from the entire internet, which terminates TLS, parses attacker-controlled input through an HTTP stack and often a web application, frequently runs with high privilege, and sits inside the device that is also the security boundary.** Every one of those properties is load-bearing, and together they explain why the same shape of vulnerability keeps recurring across unrelated vendors' products. Three consequences follow. **Pre-authentication reachability makes authentication controls irrelevant.** A flaw in the code that parses a request before credentials are checked is not helped by multi-factor authentication, certificate authentication or an identity provider. Those controls protect the session; the flaw is in the doorway. **The web layer is a large, complicated attack surface** that a purely cryptographic tunnel does not have. HTTP parsing, session cookies, file handling for language packs and portal customisation, and a browser-facing portal are all code that must be correct. **And the concentrator is the wrong place to fail.** It holds the credentials, the configuration and the route into the network, which is exactly what the Fortinet symlink case shows an attacker taking. ## Is IPsec actually safer? Not automatically, and any article that says so is selling something. IKE implementations have their own history of parser flaws and their own exploited vulnerabilities, and a badly configured IPsec deployment with pre-shared keys and aggressive mode is worse than a well-managed SSL-VPN. What genuinely changes is the shape of the exposure. There is no HTTP parser and no web application in the pre-authentication path. The code that processes an unauthenticated packet is smaller, older, more scrutinised and does less. The [IPsec and IKE article](https://ronutz.com/en/learn/ipsec-and-ike-fundamentals) covers the mechanics; the security argument here is narrow and worth stating precisely: **a smaller pre-authentication surface is a better bet than a larger one, and that is the whole of it.** It is not a promise. ## Are other vendors abandoning it? The careful answer This is where the available commentary needs reading with care, because a great deal of the "SSL VPN is dead" material circulating in 2026 is published by companies that sell zero-trust or SASE (secure access service edge) platforms. The incentive does not make the claims false, but it does mean the strong version deserves scepticism, and a practitioner asked about this in a meeting should be able to separate the parts. **What is clearly established.** Fortinet has removed tunnel mode, from primary sources. SonicWall's SMA 100 series was deactivated at the end of October 2025 rather than merely losing support, following repeated exploitation. Ivanti's Connect Secure - the former Pulse Secure, the archetypal SSL-VPN - was compromised by chained zero-days whose web shell survived a factory reset, and its follow-on advisories indicated the attack surface was not fully understood by the vendor either. Microsoft deprecated DirectAccess and named a final Windows Server release to include it. **What is lifecycle rather than verdict.** Cisco's AnyConnect 4.x reached end of software maintenance in 2024 and several ASA 5500-X hardware families have reached or are reaching last-day-of-support. That is a hardware and client generation ending on a normal schedule; it is not Cisco declaring the technology unsound, even though the ASA remote-access stack has certainly had its exploited flaws, including a pair chained in the wild in 2025. **What is simply not true.** Nobody has stopped selling remote access over TLS. Palo Alto Networks continues to develop GlobalProtect. Fortinet kept web mode and renamed it. Every SASE and ZTNA (zero trust network access) product in the market terminates TLS from a client on a public endpoint - which is worth saying out loud, because a cloud-hosted broker with a public listener has the same architectural property as an appliance with one. What changes is who operates it, how quickly it is patched, and whether the listener sits in front of your network or in front of a single application. The accurate summary is narrower than the headline: **the industry is abandoning the full-tunnel, appliance-terminated, network-level SSL-VPN as the default remote-access architecture.** It is not abandoning TLS, and it is not abandoning remote access. ## What replaces it, and what that does not fix The named replacement is zero-trust network access, and the [zero trust article](https://ronutz.com/en/learn/zero-trust-ztna-and-sase-without-the-marketing) covers what the term does and does not mean. The one property that matters to this argument is real: brokered per-application access removes the standing public listener and stops granting network-level reach on successful authentication. An attacker who compromises a session gets one application rather than a route. Two honest caveats belong with it. The broker is now the concentrator - a single point that authenticates everyone, operated by someone else, with its own vulnerability history. And migration is not a swap: applications that assume they are on the corporate network, thick clients, and anything that needs inbound connections to the user all require work that the marketing timeline does not include. ## What a practitioner should do 1. **Find out which firmware version removes the feature on your platform, and plan the migration deliberately.** For FortiGate that is 7.6.3, and the settings do not survive the upgrade. This is the item with a date attached. 2. **Treat any historically exploited concentrator as compromised until checked**, not as fixed because it is patched. Look for the specific indicators the vendor published - Fortinet's symlink is a named, checkable artefact - and rotate every credential the device could read. 3. **Reduce reachability before re-architecting.** Restricting the management interface, geofencing, and putting the portal behind an identity-aware proxy all buy time, and none requires a new platform. 4. **Move the target from full-tunnel to per-application access** where the applications allow it, and be honest in the plan about the ones that do not. 5. **Do not treat the replacement as the end of the problem.** The [there-is-no-perfect-code](https://ronutz.com/en/learn/there-is-no-perfect-code) argument applies to the broker exactly as it applied to the appliance: what will matter is how fast you detect, contain and evict, not what the product's brochure said. The vendors named here are the ones with published advisories, public timelines and researchers willing to write them up, which is a mark of maturity rather than of weakness. The list is not a ranking and it is not complete; a comparable paragraph could be written about every manufacturer whose equipment is worth attacking. Every vendor of consequence has shipped a flaw that facilitated a breach, and on the evidence of thirty years, every one of them will again - which is why the argument that matters is [not about perfect code](https://ronutz.com/en/learn/there-is-no-perfect-code) but about the clock that starts when the next one is found. ## Sources - [Fortinet FortiOS 7.6.3 release notes: SSL VPN tunnel mode is no longer supported and has been removed from both the graphical interface and the command line, and SSL VPN tunnel mode settings are not carried over when upgrading](https://docs.fortinet.com/document/fortigate/7.6.3/fortios-release-notes/236526/changes-in-behavior) - [Fortinet documentation on the replacement: SSL VPN web mode is renamed Agentless VPN, and IPsec VPN can be configured to use TCP port 443](https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/580249/ipsec-vpn-with-tcp-443) - [Fortinet PSIRT, April 2025: threat actors who exploited earlier vulnerabilities created a symbolic link between the user filesystem and the root filesystem in a folder used to serve SSL-VPN language files, retaining read-only access to configuration files including credentials; organisations that patched promptly could still be affected if the device had been compromised before remediation](https://www.fortinet.com/blog/psirt-blogs/analysis-of-threat-actor-activity) - [On the exploited chain: CVE-2018-13379, CVE-2022-42475, CVE-2023-27997 and CVE-2024-21762 in Fortinet SSL-VPN, with CVE-2024-21762 described as likely already exploited at disclosure](https://www.channeldive.com/news/ssl-vpn-era-ends-cybersecurity-zero-trust-pcc/821765/) - [On Ivanti Connect Secure: CVE-2023-46805 and CVE-2024-21887 chained to gain root-level access, with persistence surviving factory resets](https://www.fusiontek.com/ssl-vpn-is-a-thing-of-the-past/) - [Industry survey of vendor timelines, published by a SASE vendor and to be read with that in mind: Fortinet stripped SSL VPN from FortiOS 7.6.3 with configurations not migrated; SonicWall deactivated all SMA 100 series appliances on 31 October 2025 after repeated exploitation; Cisco is ending support for ASA 5500-X models running SSL VPN with deadlines through August 2026](https://jimber.io/blog/ssl-vpn-is-deprecated-every-vendors-timeline-and-what-replaces-it/) - [The same publisher on Cisco's lifecycle: AnyConnect 4.x reached end of software maintenance on 31 March 2024 with last date of support 31 March 2027; ASA 5525-X, 5545-X and 5555-X reached last date of support on 30 September 2025 and the 5506-X, 5508-X and 5516-X follow on 31 August 2026; CVE-2025-20333 and CVE-2025-20362 are being chained in the wild](https://jimber.io/blog/cisco-anyconnect-replacement/) - [On Microsoft's position and the broader watchlist, same publisher: DirectAccess was formally deprecated in June 2024 with Windows Server 2025 named as the final release to include it](https://jimber.io/blog/legacy-vpn-end-of-life-2026/)