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

Is your remote access still an internet-exposed SSL-VPN appliance? We map the attack surface and plan the move to ZTNA. WZ-IT runs sovereign, self-hosted mesh platforms (remote management platforms) on EU infrastructure - with CVE monitoring and NIS2-ready documentation. Book a free consultation · Security audit · CVE monitoring

On 26 February 2026, the US agency CISA issued a Binding Operational Directive ordering an actively exploited FortiOS zero-day to be patched or disabled within 72 hours. Fortinet FortiOS CVE-2026-0847 (CVSS 9.8) is an authentication-bypass flaw in the SSL-VPN function: an unauthenticated attacker bypasses login and gains network access. Roughly 47,000 FortiGates were reported as internet-exposed. Attackers were on devices within minutes of identification - credential harvesting, backdoors, lateral movement, and in several incidents follow-on ransomware.

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
• 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 CVE-2026-0847. Affected releases are FortiOS 7.0.0-7.0.15, 7.2.0-7.2.9 and 7.4.0-7.4.6; fixes ship in 7.0.16, 7.2.10 and 7.4.7. Between disclosure and broad patching there was a window in which attackers mass-scanned the roughly 47,000 exposed devices.

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.1) 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.

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.

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.

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 (Art. 21) - and reporting within 24 and 72 hours (Art. 23). On top of that comes personal liability for management; fines reach up to EUR 10M or 2 percent of global annual turnover.

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 audit finding. The first formal NIS2 audits run from 30 June 2026. 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.

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 consultation · Remote management platforms · CVE monitoring

Sources

• CISA Known Exploited Vulnerabilities Catalog
• CISA Binding Operational Directive 22-01 (Reducing the Significant Risk of Known Exploited Vulnerabilities)
• NVD - CVE-2026-0847 (FortiOS SSL-VPN Authentication Bypass)
• 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)
• BSI - NIS-2 and the German Cyber Resilience Act