FortiBleed: 73,932 Fortinet firewalls exposed — FIDO2 is now mandatory

On 17–19 June 2026, researchers disclosed “FortiBleed”: a massive credential theft targeting ~74,000 Fortinet firewalls/VPNs. Here is how phishing‑resistant MFA (FIDO2/WebAuthn) satisfies GDPR Article 32 and blocks initial access.

What happened

Between 17 and 19 June 2026, multiple sources documented an active campaign dubbed “FortiBleed”: a dump exposing credentials (usernames, emails, cleartext passwords) for 73,932 Fortinet firewall/VPN URLs, impacting organizations in nearly 200 countries. Attackers did not rely on a novel exploit: they primarily abused reused/leaked passwords, credential stuffing, and password spraying against Internet‑exposed admin and SSL‑VPN interfaces. TechCrunch, ITPro and others confirm the scale and the password‑centric nature of the attack, with major companies listed in the archive. TechCrunch; ITPro.

In response, authorities and the security community issued emergency steps: reset all VPN and admin passwords, remove Internet exposure of consoles, and enable strong access controls. The U.S. CISA explicitly calls for hardening Fortinet deployments. HSToday (CISA). Technical write‑ups (CSO Online, Dark Reading) also note many environments had not enabled Fortinet’s newer PBKDF2 password hashing, easing credential recovery from stolen configs. CSO Online.

Measured impact: beyond compromised access, affected firewalls often serve as a pivot to harvest other secrets (internal accounts, network layouts), creating high risk of lateral intrusions and ransomware in the short term. In several cases, emergency response required temporary VPN shutdowns and mass password rotations, causing business disruptions.

Applicable legal framework

For organizations in Luxembourg, Belgium, France, Germany and across the EU, a “password‑based” attack is no mitigating factor: GDPR Article 32 mandates “appropriate technical and organizational measures” to ensure confidentiality, integrity and availability, considering the state of the art, costs, nature and risks. In practice, regulators expect multi‑factor authentication for sensitive access, attack surface reduction, and evidence of control. See our reference page on GDPR Article 32. References: EUR‑Lex — GDPR, Art. 32; CNPD — Chapter IV (Art. 32).

Beyond GDPR, NIS 2 and DORA entities must demonstrate robust access controls and identity risk management: even without a zero‑day, exposing admin interfaces without phishing‑resistant MFA is hard to defend during supervision.

The technical solution to deploy

Phishing‑resistant MFA (FIDO2/WebAuthn). Legacy factors (SMS, TOTP, push) are vulnerable to phishing proxies and “MFA fatigue.” FIDO2/WebAuthn relies on public‑key cryptography bound to the origin, preventing reusable secrets from transiting. Outcome: even if an attacker gets a password, it is useless without the FIDO2 authenticator bound to the right service. Reference: CISA — Phishing‑resistant MFA.

Applied to FortiBleed and perimeter access in general:

• Eliminate passwords as an acceptance factor on admin consoles and VPN portals: enforce SAML/OIDC federation behind an enterprise IdP where FIDO2/WebAuthn is mandatory for privileged accounts.
• Origin binding: the private key stays in the FIDO/passkey; the authenticator only responds if the domain matches the registered origin, neutralizing phishing proxies.
• Attestation and key policy: require compliant keys (e.g., FIPS/NFC/USB‑C) for administrators, enable unapproved device detection, and log attestations.
• Surface reduction: remove Internet exposure of Fortinet consoles; allow admin via an internal bastion/admin VPN with mandatory FIDO2.
• Rotation and PBKDF2: after FortiOS updates, force admin re‑login to enable PBKDF2 hashing and reduce reuse of old configuration dumps. CSO Online.

Reference standards: ISO 27001:2022 Annex A.5.17 Application access control, A.8.2 Identity management; NIST CSF v2 (ID.AM‑08, PR.AC‑02/03); CIS Controls v8 (IG1: 6, 12).

How Luxgap delivers this

• Our ISO 27001 governance: we define a “phish‑resistant‑first” authentication policy (population segmentation, approved factors, documented Article 32 exemptions, audit evidence) and align residual risks with your risk register.
• Our fractional CISO consultants: we integrate FIDO2/WebAuthn with your existing IdP (Microsoft Entra, Okta, Keycloak…), enable SAML/OIDC federation on Fortinet, lock down admin flows (bastion, ACL), and draft the evidence (records of processing, risk analysis, rotation procedures).
• Our 24/7 managed SOC: SIEM/XDR correlation on authentication failures, brute‑force detections on perimeter interfaces, real‑time alerting if a FIDO2 policy is bypassed, and emergency rotation playbooks (accounts, tokens, keys).

We execute in 3 sprints: (1) Design of access policies and privileged groups; (2) Integration IdP↔Fortinet, FIDO2 key pilots and bastion; (3) Rollout with internal comms kits, field support and audit‑ready Article 32 compliance dashboards.

EU or Luxembourg case study

A NIS 2‑regulated fiduciary with ~300 staff and an exposed FortiGate migrated in 6 weeks from VPN/password+TOTP to SAML federation + mandatory FIDO2 for IT, with optional passkeys for the wider workforce. Outcomes: no more Internet‑exposed admin console, removal of orphaned local accounts, zero false positives against phishing proxies in our simulations, and an audit‑ready dashboard consolidating IdP logs, Fortinet logs and training evidence.

First concrete steps

1. Block today direct Internet access to Fortinet consoles; allow admin only via an internal bastion. Apply recent FortiOS updates and force PBKDF2 activation via admin re‑login.
2. Federate authentication for Fortinet (SAML/OIDC) behind your IdP and make FIDO2 mandatory for privileged accounts; disable unnecessary local accounts.
3. Deploy FIDO2 security keys for administrators (USB‑C/NFC/BLE as appropriate), enable attestation and block unapproved keys; for employees, enable passkeys on managed devices.
4. Log and alert: integrate IdP, Fortinet and EDR into the SIEM; real‑time alerts on auth failures, local account creation, MFA policy changes.
5. Document Article 32: update risk analysis, access policy, rotation procedures and response plan. Prepare clear “before/after” evidence for your DPO and audits.

Official sources

• News — TechCrunch: Fortinet — FortiBleed campaign (17 June 2026)
• News — ITPro: ~74,000 Fortinet credentials exposed (19 June 2026)
• Regulator — EUR‑Lex — GDPR, Article 32 (security of processing)
• Regulator (LU) — CNPD Luxembourg — Chapter IV (incl. Art. 32)
• Best practice — CISA via HSToday — Fortinet hardening (19 June 2026)
• Technical context — CSO Online — FortiBleed details and FortiOS PBKDF2
• MFA — CISA — Implementing Phishing‑Resistant MFA

Need hands‑on, Article 32‑aligned support? Reach out via our contact page.