CNIL fines Free/Free Mobile €42M and why to move to FIDO2 MFA

On 13 January 2026, CNIL fined Free Mobile €27M and Free €15M for inadequate security controls, including VPN authentication deemed “not robust enough.” Here is how phishing‑resistant MFA (FIDO2/WebAuthn) concretely meets GDPR Article 32 and avoids this scenario.

The facts

According to CNIL, an attacker infiltrated Free/Free Mobile’s IT in October 2024, accessing data tied to 24 million contracts, including IBANs for some shared subscribers. On 13 January 2026, the restricted committee fined Free Mobile (€27M) and Free (€15M), citing GDPR Article 32 failures: “insufficiently robust” VPN authentication and “ineffective” anomaly detection. CNIL also noted shortcomings in data subject information (Art. 34) and retention limitations at Free Mobile (Art. 5‑1‑e); it ordered remediation within three to six months. Official source: CNIL, 14/01/2026 and decisions SAN‑2026‑001 / SAN‑2026‑002. Press coverage: BleepingComputer.

The applicable legal framework

• GDPR — Article 32: requires appropriate technical and organisational measures, risk‑based, to ensure a suitable level of security (confidentiality, integrity, availability). Choices and strength of controls must be demonstrable. Official text: Eur‑Lex. For Luxembourg organisations, see the GDPR framework and local obligations.
• Breach notices: where there is high risk to individuals, communications must be clear and complete (GDPR Art. 34). In the Free case, CNIL found the notice email incomplete (CNIL).
• NIS 2/DORA context (EU): for essential/important or financial entities, authorities expect strengthened access controls and effective detection. Even outside strict scope, these baselines shape the “state of the art.”

The technical solution to deploy

Phishing‑resistant MFA (FIDO2/WebAuthn) for all sensitive access (VPN, SSO, critical SaaS, admins). Goal: remove “reusable” factors (passwords, interceptable OTP) and man‑in‑the‑middle.

• How it works: FIDO2/WebAuthn creates a per‑service asymmetric key pair. The private key stays in the authenticator (hardware key, OS enclave, smartcard) and signs a challenge bound to the domain (“origin binding”), blocking phishing and proxying. Tech refs: FIDO Alliance, NIST SP 800‑63B.
• In practice:
  • VPN/Remote Access: front the VPN with the IdP (SAML/OIDC) and require FIDO2 for all internal/third‑party accounts. Disable password‑only/OTP.
  • SSO and SaaS: enable guided passkey enrolment, enforce FIDO2 for privileged roles and sensitive data (finance, HR, CRM).
  • Device posture: bind authentication to endpoint compliance (MDM/EDR) and conditional access policies.
  • SecOps: log attestation, provenance, and origin‑binding failures; correlate in the SIEM to detect bypass attempts.
• References: ISO/IEC 27001:2022 Annex A — A.5.15 (access control), A.5.16 (identity management), A.5.17 (authentication information); NIST SP 800‑63B (phishing‑resistant authenticators); EU guidance preferring FIDO2 for privileged access.

How Luxgap delivers this

• ISO 27001 governance: our Lead Implementers/Auditors shape the authentication policy (A.5.15–17), risk register, and documented justification for choosing FIDO2 to satisfy GDPR Art. 32 and, where relevant, NIS 2/DORA.
• Managed SOC 24/7: integrate WebAuthn/IdP/VPN logs into the SIEM, detect suspicious events (no origin‑binding attempts, attestation failures, abnormal elevations), with response playbooks (revocation, key rotation, conditional access blocks).
• Externalised CISO and DPO consultants: align to Article 32 (proportionality evidence), update privacy notices and breach templates (Art. 34), and plan remediation and periodic tests.

Real‑world case in Luxembourg or the EU

Realistic example: a Luxembourg financial services firm (in scope of NIS 2 and DORA) used SMS OTP for VPN and complex passwords for some internal apps. In six weeks we (1) fronted VPN with the IdP and enforced FIDO2, (2) mandated FIDO2 for admins and IBAN‑processing apps, (3) fed WebAuthn/IdP logs into the SIEM with origin‑anomaly alerts, (4) trained teams (passkey enrolment, emergency kits). Result: removal of reusable OTPs, a sharp drop in phishing‑driven account takeovers, and structured proof for the DPO, CSSF, and ILR.

First concrete steps

1. Map critical access: VPN, SSO, sensitive SaaS, privileged accounts. Decide where FIDO2 is “mandatory” within 30 days (admin‑first).
2. Enable FIDO2/WebAuthn in the IdP: publish a phishing‑resistant MFA policy, disable uncontrolled SMS/OTP fallbacks, and provision recovery keys in an HSM vault.
3. Put VPN behind the IdP: require FIDO2 for all remote access. Test split‑tunnel, always‑on, and device compliance with EDR/MDM.
4. Stream to the SIEM: collect and correlate WebAuthn/IdP/VPN events. Define alerts (origin mismatch, repeated failures, factor removal).
5. Train and document: passkey enrolment guides, loss/theft procedures, break‑glass policy, and Art. 34 notification templates.

Why this matters after Free/Free Mobile

The Free case shows that, given data scale and IBANs, the 2026 minimum expectation includes strong authentication and effective detection. Phishing‑resistant MFA for VPN/SSO/admin access is no longer a “nice to have”: it is the most direct way to demonstrate proportionality and the “state of the art” under Article 32. In incidents, it also yields technical evidence (attestation, origin, policies) vital for defence, remediation, and communicating to individuals.

Official sources

• CNIL — Data breach: FREE MOBILE and FREE fined €42 million (14/01/2026)
• Légifrance — Decision SAN‑2026‑001 (Free Mobile) / SAN‑2026‑002 (Free)
• Eur‑Lex — GDPR, Article 32 (security of processing)
• NIST SP 800‑63B — Authenticators (WebAuthn/FIDO2 phishing resistance)
• FIDO Alliance — FIDO2/WebAuthn Specifications

Need support tailored to your context? Reach out via our Luxgap contact page.