The Free breach. Before that, Viamedis and Almerys. Before that, others. Each time, the same cycle: announcement, press coverage, security advice. Advice that has barely moved in twenty years.
In 2025, credentials leak. That is a baseline fact, not a working hypothesis. Starting from there changes what you are trying to solve: no longer protecting the password, but designing authentication so that a stolen password is not enough to open an account. That shift is what leads to MFA, and explains why not all MFA is equal.
The two vectors: they do not work the same way
Credential stuffing: the stolen password
A breach exposes email/password pairs, or hashes that can be cracked. The attacker is generally not targeting a specific account: they are automatically testing these pairs across thousands of services. It works because passwords get reused. A credential compromised on one site in 2021 can open access to a professional email account in 2026 if the password has not changed.
Yes, changing your password after a breach cuts this vector. But it is a response to the last attack, not the next one.
Phishing: the password handed over
Phishing does not need a breach. A convincing email, a cloned login page, and the user types their own credentials into the fake site. Password strength is irrelevant: a 32-character password that has been phished is just as useful to the attacker as an 8-character one.
This is by far the most documented vector in real corporate compromises. The Verizon DBIR confirms it year after year: phishing is the primary initial access method in serious incidents, ahead of brute force, ahead of cracking.
What MFA solves, and what it does not
Against credential stuffing: TOTP is sufficient
A user with active TOTP makes a stolen password unusable. The attacker has the right email and the right password: the connection fails anyway. They are missing the second factor, stored on the legitimate user’s device, never exposed in the compromised database.
MFA turns a credential breach into an incident with no direct operational consequence for the affected account. That is significant.
A note on SMS-based MFA: it is an improvement over no MFA at all. But it remains vulnerable to SIM swapping, a fraudulent number transfer obtained through social engineering on the carrier. For low-stakes accounts, it can serve as a transition step. For critical access, it does not constitute a sufficient assurance level.
Against phishing: only FIDO2
TOTP does not protect against real-time phishing. AiTM (Adversary-in-the-Middle) attacks proxy the connection: the user enters their credentials on the fake site, the attacker immediately relays them to the real site, TOTP code included, within the 30-second window. The legitimate session is captured.
FIDO2 (passkeys, physical keys such as YubiKey) closes this vector by design. The private key signs a challenge tied to the exact domain of the site. A fake site, even a pixel-perfect clone, cannot receive a valid signature for the real site. Authentication is cryptographically bound to the origin. Phishing fails, regardless of the social engineering techniques deployed.
| Vector | No MFA | SMS MFA | TOTP / hardware key | FIDO2 |
|---|---|---|---|---|
| Credential stuffing | Exposed | Protected | Protected | Protected |
| Targeted SIM swapping | Exposed | Exposed | Protected | Protected |
| AiTM phishing | Exposed | Exposed | Exposed | Protected |
This is not a difference of degree between levels. It is a difference of kind.
FIDO2 raises concrete questions before deployment: fallback for incompatible devices, account recovery, synced passkeys vs hardware-bound keys. Our dedicated article covers these points.
The practical problem: systems that cannot do this
Most organisations that have not yet deployed strong MFA do not have a conviction problem: they have an architecture problem.
Legacy systems frequently authenticate directly against an in-house LDAP directory, a custom user database, or an authentication layer written fifteen years ago. Integrating FIDO2 into that type of system without touching the application code is generally not feasible.
The answer is not to rewrite the application. It is to introduce an identity layer in front of it: an identity provider (IdP) that handles authentication, MFA and sessions, and to which the application delegates via OIDC or SAML. The legacy application validates a token. It no longer knows anything about passwords, TOTP codes or FIDO2 keys.
Depending on the context, this layer takes different forms: Keycloak for deployments requiring customisation and infrastructure control (we deployed it for Erganeo, among others), integration of Microsoft Entra ID or Google Identity for environments already built on those ecosystems, or a custom OIDC server when business or regulatory constraints demand it. That is the model behind the authentication service we develop and maintain for a regulated professional body in the accounting and auditing sector.
What this means for decision-makers
Choosing a service provider that handles sensitive data (HR, financial, medical, legal) without strong MFA means accepting a known, documented risk. Not a theoretical one: a risk that recent breaches have made concrete and quantifiable.
MFA is no longer up for debate. What remains to decide: which level, for which accounts, and whether the current architecture supports it.
For standard accounts: TOTP cuts credential stuffing. For high-stakes access (admin accounts, sensitive data, regulated professions): FIDO2 is the only response that closes both vectors. For legacy systems that do not natively support MFA: an IdP layer, not a rewrite.
Do you want to assess the robustness of your authentication architecture, or implement an IdP on a legacy perimeter? Let’s talk about your context.