FortiGate SSL-VPN Risk in 2026: Why Internet-Exposed VPN Appliances Became a Liability and ZTNA Is the Answer

Replace an SSL-VPN safely: the secure access assessment inventories access and legacy setups and defines the target model and migration path. The VPN migration sprint then implements it with a pilot group, parallel operation and documented rollback. WZ-IT can then take over ongoing operations as Managed NetBird from €349.90 net per month with monitoring, updates, backups and a selectable service level. View secure access assessment · Migration sprint · Managed NetBird · CVE monitoring

On 27 January 2026, the US agency CISA added an actively exploited FortiOS flaw to its Known Exploited Vulnerabilities (KEV) catalog and gave US federal agencies three days to fix it. Fortinet FortiOS CVE-2026-24858 (CVSS 9.8) is an authentication-bypass flaw in FortiCloud SSO login: an attacker with their own FortiCloud account could log in to other organizations' FortiGates, including devices running the then-current firmware (Fortinet PSIRT FG-IR-26-060). Fortinet locked the two abused FortiCloud accounts on 22 January 2026 and shipped fixes from 27 January 2026.

FortiGate is not an isolated case. 2026 is the year in which the internet-exposed SSL-VPN appliance became a liability as a category. Citrix NetScaler, Ivanti Sentry and FortiClient EMS followed within months, each with its own critical, actively exploited flaw. This article puts the wave in context, explains why the open VPN listener at the network edge is the structural problem, and walks through a practical path to identity-based ZTNA built on a sovereign, self-hosted mesh architecture.

Table of contents

• The 2026 VPN appliance exploitation wave in facts
• Why the internet-exposed SSL-VPN became a liability
• Fortinet pulls the plug itself: FortiOS 7.6.3
• From flat VPN to identity-based ZTNA
• NetBird plus IdP as a sovereign mesh alternative
• A five-step migration path
• NIS2 and the liability question
• How we work at WZ-IT
• Further reading

The 2026 VPN appliance exploitation wave in facts

Four incidents in half a year reveal a pattern, not a single vendor failing. All data verified against NVD and the CISA KEV catalog (as of June 2026, FortiOS row corrected in October 2026):

FortiOS CVE-2026-24858. Affected releases are FortiOS 7.0.0-7.0.18, 7.2.0-7.2.12, 7.4.0-7.4.10 and 7.6.0-7.6.5; fixes ship in 7.0.19, 7.2.13, 7.4.11 and 7.6.6. The precondition is enabled FortiCloud SSO administrative login. It is off by default, but it is switched on when a device is registered in FortiCare unless the administrator explicitly disables the option.

Citrix NetScaler CVE-2026-3055 (CVSS 9.3) is an out-of-bounds read that can leak appliance memory - including session tokens - without authentication. It affects only appliances configured as a SAML Identity Provider; the companion CVE-2026-4368 (CVSS 7.7) affects Gateway and AAA virtual servers. Citrix published the advisory on 23 March 2026; CISA added the CVE to its KEV catalog on 30 March 2026 based on evidence of active exploitation - a pattern reminiscent of prior NetScaler incidents (CitrixBleed).

Ivanti Sentry CVE-2026-10520 reaches the maximum CVSS 10.0: a pre-auth OS command injection that grants unauthenticated attackers with access to management port 8443 root-level code execution. Affected versions are Sentry 10.5.1, 10.6.1, 10.7.0 and earlier (fixes in 10.5.2, 10.6.2, 10.7.1). In the CISA KEV since 11 June 2026; researchers observed compromises shortly after patch release.

FortiClient EMS CVE-2026-35616 (CVSS 9.8) is an improper-access-control / API auth bypass in versions 7.4.5 and 7.4.6. The nasty twist: a threat cluster used the flaw to push an infostealer disguised as a Fortinet patch to managed endpoints. CISA added the CVE to the KEV catalog on 6 April 2026.

Update of 12 October 2026: An earlier version of this post named CVE-2026-0847 and a CISA directive of 26 February 2026 as the FortiOS flaw. That was wrong: according to NVD, CVE-2026-0847 affects the Python library NLTK, and CISA Emergency Directive ED 26-03 of 25 February 2026 concerned Cisco SD-WAN. The section now names the FortiOS flaw that was actually exploited, CVE-2026-24858. Since June, CISA has added two more FortiOS flaws to the KEV catalog: CVE-2025-68686 (a bypass of the protection against the symlink persistence mechanism on already compromised devices, since 27 July 2026) and CVE-2025-25249 (a heap overflow in the CAPWAP daemon cw_acd, since 9 September 2026). CVE-2025-25249 is fixed in FortiOS 7.0.18, 7.2.12, 7.4.9 and 7.6.4; FortiOS 6.4 receives no fix (Fortinet PSIRT FG-IR-25-084). Since 10 June 2026, US federal agencies follow BOD 26-04, which supersedes BOD 22-01 and BOD 19-02. It prioritises remediation by public exposure, KEV status, exploit automation and technical impact; the shortest deadline is three days plus forensic triage.

Why the internet-exposed SSL-VPN became a liability

The common thread is not the individual bug but the architecture. A classic SSL-VPN appliance is an internet-exposed, highly privileged single point of failure:

• By definition it runs an open listener at the internet edge (typically 443) that every scanner finds. Search engines like Shodan continuously index exposed FortiGates, NetScalers and Ivanti gateways.
• After a successful login it often grants flat network access - the compromised VPN endpoint becomes a springboard for lateral movement.
• It terminates TLS and holds credentials and session tokens in memory, making it a rewarding target for memory leaks (see NetScaler) and auth bypasses (see FortiOS).
• Patching requires maintenance windows, HA failover and functional testing. The gap between disclosure and rollout is exactly the window in which mass-scanning runs.

This is not a Fortinet-specific problem. We described the same structural weakness with Cisco ASA and ArcaneDoor. As long as the access path is an open, anonymously reachable listener, every new flaw in the appliance remains a potential full network compromise.

Fortinet pulls the plug itself: FortiOS 7.6.3

The debate about whether an internet-exposed SSL-VPN appliance is still appropriate has meanwhile been settled by the vendor. From FortiOS 7.6.3 onwards, SSL-VPN tunnel mode is removed entirely - available in neither the GUI nor the CLI, and that applies to all FortiGate models (FortiOS release notes).

Two details turn this into a hard deadline rather than a recommendation:

• Existing configurations are not carried over. All SSL-VPN tunnel mode settings including the associated firewall policies do not survive the upgrade.
• Upgrading unprepared means losing remote access. Fortinet explicitly states that the migration must happen before the upgrade to avoid interrupting access.

As the direct successor Fortinet points to IPsec, optionally over TCP 443 for restrictive networks. That is the path which keeps you inside the same ecosystem.

The more useful question is a different one: if every remote access configuration has to be touched anyway, this is the cheapest moment to ask the architecture question. A forced rebuild onto IPsec does not solve the underlying problem - the internet-exposed listener remains, and the appliance stays the privileged single point of failure. Moving to an identity-based overlay instead spends the same effort on the step that actually removes the attack surface.

From flat VPN to identity-based ZTNA

The answer to an architecture problem is a different architecture. ZTNA (Zero Trust Network Access) inverts the model: instead of "get on the network first, then see what is reachable," it is "verify identity and context first, then expose exactly one application." The core differences:

• No anonymous listener at the internet edge. Connections are established outbound and identity-first; there is no open port offering authentication to anyone who knocks.
• Access per application, not to the whole network. A policy like "the maintenance group may reach the PLC subnet at site B" replaces the flat tunnel.
• Identity, device posture and context govern every access decision - not a single validated VPN login.
• A full audit trail: who accessed which application and when. That is the foundation for NIS2 evidence.

What ZTNA means precisely and how it differs from a classic VPN is covered in our knowledge article What is ZTNA?. Importantly, ZTNA is not a single vendor's product but an architecture principle - implementable with commercial clouds (Zscaler, Cloudflare, Twingate) or with sovereign, self-hosted open-source components. How the replacement works regardless of vendor, from inventory and target model to switching off the gateway, is described in the guide Replacing your VPN.

NetBird plus IdP as a sovereign mesh alternative

For DACH organizations with a sovereignty mandate, the self-hosted variant is especially attractive. NetBird is a Berlin-built, WireGuard-based zero-trust mesh platform under a BSD-3 license. The management server, signal server and relay (TURN) are open source and fully self-hostable.

Instead of an exposed concentrator you get a flat, peer-to-peer encrypted overlay: every node reaches every other node directly, as long as policy allows it. There is no central internet listener acting as a single point of failure. On top of the WireGuard foundation NetBird adds a management layer with:

• SSO/IdP integration with Keycloak, Authentik or Entra ID - identity comes from your own directory, not from the VPN box.
• Group-based access policies (per-application network segmentation).
• An audit trail across all connections.

The sovereignty advantage: control plane and data plane run on your own or EU infrastructure, the IdP stays in-house, and there is no dependency on a US cloud. NetBird closed a EUR 8.5M Series A in January 2026 and is under active development. For a comparison against Tailscale and plain WireGuard, see NetBird vs. Tailscale vs. WireGuard. If you need a pure WireGuard foundation for site connectivity, the options are on our WireGuard expertise page.

We run exactly this model in production: at ABCO Water Systems in Australia, secure remote maintenance of machines and plants runs over an identity-based mesh rather than an exposed VPN concentrator.

A five-step migration path

A switch does not have to be a big-bang cutover. A parallel rollout has proven itself:

1. Inventory and audit. Which VPN appliances are internet-exposed? Which versions, which open CVEs, which user and machine access runs through them? This is the core of our security audit.
2. IdP as the single source of truth. Consolidate identities, groups and MFA in Keycloak, Authentik or Entra ID. Without a clean IdP there is no robust ZTNA.
3. Mesh pilot. Stand up the NetBird control plane on your own or EU infrastructure, connect a first user group and a non-critical target system via policy, and verify audit logging.
4. Step-by-step migration. Move user groups and machine access from the SSL-VPN to the mesh one after another. The FortiGate stays in place for now as a firewall and for site-to-site tunnels.
5. Disable the listener. Once no end users go through the SSL-VPN service, deactivate the internet-exposed listener - the central attack surface disappears.

The architectural background for NIS2-compliant remote access is detailed in our knowledge article NIS2-compliant remote access.

NIS2 and the liability question

The German NIS2 transposition obliges essential and important entities to maintain documented risk management - explicitly including vulnerability and patch management (Section 30 BSIG) - and reporting within 24 and 72 hours (Section 32 BSIG). On top of that comes management accountability (Section 38 BSIG); for essential entities, fines reach up to EUR 10M or 2 percent of global annual turnover (Section 65 BSIG).

An internet-exposed VPN appliance with a known CVSS 9.8 flaw left unpatched for weeks for lack of a patch SLA is a textbook finding in a BSI inspection or after a reportable incident. By contrast, organizations that can show a documented CVE-monitoring and patch process plus an identity-based, segmented access architecture with an audit trail satisfy several requirements at once.

This article is general information and not legal advice. We are engineers, not lawyers - the concrete assessment of your NIS2 obligations belongs in qualified legal hands.

Still unsure which tool fits? The orientation workshop sorts out your requirements and delivers a prioritised topic list with a recommendation per topic. From €1,490 excl. VAT, remote.

How we work at WZ-IT

WZ-IT is a German managed service provider for sovereign IT and managed open source. When replacing internet-exposed VPN appliances, we work as follows:

• Security audit first. We map the attack surface: exposed appliances, version levels, open CVEs, access paths. The outcome is a prioritized action plan - see security audit.
• A sovereign mesh platform instead of a concentrator. We build and operate NetBird-based remote management platforms on your own or EU infrastructure, integrated with your IdP and group-based policies.
• CVE monitoring and a patch SLA. Daily checks against NVD, CISA KEV, CERT-Bund and BSI - with documented response as an annex to the NIS2 risk-management documentation. More under CVE monitoring.
• Parallel operation and a clean cutover. The existing firewall stays in operation; the SSL-VPN listener is disabled only once all access has been migrated and verified.
• NIS2-ready documentation. Architecture, policies and audit trail are documented to withstand an audit.

Further reading

• What is ZTNA? Zero Trust Network Access explained - the architecture principle behind the move
• What is NetBird? - the sovereign, self-hosted mesh platform
• NetBird vs. Tailscale vs. WireGuard - the options compared
• NIS2-compliant remote access - architecture and evidence requirements
• Secure remote maintenance of machines and plants - the OT/industrial use case
• Cisco ASA, ArcaneDoor and a modern VPN stack - the same pattern in edge appliances
• CVE monitoring as a managed service - automated response to NVD, CISA KEV, CERT-Bund and BSI
• ABCO Water Systems case study - identity-based remote maintenance in production

You run a FortiGate, Citrix or Ivanti appliance with an internet-exposed SSL-VPN - and want to reduce the attack surface? We assess your remote access in a security audit and plan the move to a sovereign, identity-based mesh architecture - without a big-bang cutover.

Book a free initial call · Remote management platforms · CVE monitoring

Sources

• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk (replaces BOD 22-01)
• Fortinet PSIRT FG-IR-26-060 (CVE-2026-24858, FortiCloud SSO Authentication Bypass)
• NVD - CVE-2026-24858
• Fortinet PSIRT FG-IR-25-084 (CVE-2025-25249)
• Fortinet PSIRT FG-IR-26-099 (CVE-2026-35616, FortiClient EMS)
• CISA ED 26-03: Mitigate Vulnerabilities in Cisco SD-WAN Systems
• Citrix Security Bulletin CTX696300 (CVE-2026-3055, CVE-2026-4368)
• Rapid7 - CVE-2026-3055 Citrix NetScaler ADC and Gateway Out-of-Bounds Read
• NVD - CVE-2026-10520 (Ivanti Sentry OS Command Injection)
• Help Net Security - Critical Ivanti Sentry flaw allows root-level RCE (CVE-2026-10520)
• The Hacker News - Fortinet Patches Actively Exploited CVE-2026-35616 in FortiClient EMS
• Arctic Wolf - FortiClient EMS Exploited via CVE-2026-35616 to Deliver EKZ Infostealer
• NetBird - Open Source Zero Trust Networking
• NetBird Documentation
• EU-Startups - NetBird raises EUR 8.5 million Series A (January 2026)
• Section 30 BSIG - risk management measures (German)
• BSI - NIS-2 and the German Cyber Resilience Act