MFA failed to prevent attacks in 84% of incident responses during 2026, and 99% of SaaS compromises originate at the identity provider. For a control that has been the centrepiece of identity security advice for a decade, that is a difficult pair of numbers.
It is worth being precise about what failed. MFA was not bypassed in the sense of being defeated cryptographically. In most of these incidents MFA worked exactly as designed. The attacker simply arranged for it to work on their behalf.
The shift from credential to session
Authentication produces a session token. That token is what actually grants access for the following hours or days; the password and the second factor are just the ceremony that produces it.
Attackers noticed. Rather than trying to defeat the ceremony, they take its output:
- Adversary-in-the-middle proxies relay the genuine login through a reverse proxy, let the victim complete MFA, and capture the session cookie in transit.
- Infostealer logs contain session cookies harvested directly from browsers on infected machines — no interaction with the victim required at all.
- MFA fatigue sends repeated push notifications until someone approves one to stop the noise.
- Self-enrolled devices let an attacker with a valid session register their own authenticator, converting temporary access into durable access.
Every one of these produces an authentication event that looks entirely legitimate in the logs. The user really did authenticate. The MFA challenge really was satisfied.
Which factors actually survive
Not all MFA is equivalent, and the differences matter enormously here:
| Method | Resists AiTM? | Notes |
|---|---|---|
| SMS one-time code | No | Also exposed to SIM swap and carrier compromise |
| Email one-time code | No | Inherits the security of the mailbox |
| TOTP authenticator app | No | Code is relayed through the proxy like any other input |
| Push notification | No | Vulnerable to fatigue and to AiTM |
| Push with number matching | Partially | Defeats fatigue, not AiTM |
| FIDO2 security key / passkey | Yes | Origin-bound; will not produce an assertion for the wrong domain |
The distinction is that FIDO2 authenticators bind the authentication to the origin cryptographically. On a lookalike domain, the authenticator does not produce a valid response. There is nothing for the proxy to steal.
The identity provider is your perimeter now
The figure that should reshape architecture decisions is the second one: 99% of SaaS compromises originate at the identity provider. Everything federated to that IdP inherits whatever happens there.
Yet in most organisations, IdP monitoring is markedly less mature than network monitoring. Teams that would immediately investigate an unusual outbound connection from a server routinely have no alert at all for an administrator granting a new OAuth consent, or for a user registering an authenticator from a new country.
The detections worth building first
- New MFA method registered shortly after a sign-in from an unfamiliar location or device. This is the highest-fidelity signal in the identity stack and it is frequently unmonitored.
- Sign-in from hosting provider IP ranges. Legitimate users rarely authenticate from datacentre address space.
- OAuth consent granted to a new application, particularly one requesting broad mail or file scopes.
- Conditional access policy modified. Attackers with administrative access disable the controls that would catch them.
- Mailbox forwarding rules created, especially with keyword filters around invoices and payments.
- Session token used from a materially different device fingerprint than the one that obtained it.
A realistic remediation sequence
- Phishing-resistant MFA for administrators. Every privileged role, including break-glass accounts, on hardware keys. This is a weeks-long project, not a year-long one.
- Remove weaker fallbacks for those groups. Leaving SMS enabled as an alternative negates the rollout entirely — this is the step programmes most often skip.
- Session revocation in the IR playbook. Password reset and session revocation are separate actions in every major IdP. Automate both together.
- Token protection and device binding wherever your platform supports it.
- Shorter session lifetimes for high-value applications, accepting the usability cost where the data justifies it.
- Extend phishing-resistant MFA to the general population, phased by risk.
What to stop saying
"We have MFA" is no longer a meaningful statement about security posture. The useful questions are which factors, for which users, with which fallbacks still enabled, and what happens to a stolen session.
An organisation with hardware keys on all privileged accounts, weak methods disabled, and automated session revocation is in a fundamentally different position from one with SMS codes enabled for everyone — even though both will tell you they have deployed multi-factor authentication.
