MFA Fatigue

MFA fatigue (sometimes called MFA bombing or push fatigue) is an attack pattern where an attacker who has stolen credentials triggers repeated MFA push notifications to the legitimate user. The attacker hopes the user will eventually approve one — accidentally, out of frustration, or to make the notifications stop. Mitigated by number matching (the user must enter a number shown on the sign-in screen, not just tap Approve), context information in the push (showing the sign-in app and location), risky-sign-in policies in Identity Protection that block obvious anomalies, and phishing-resistant MFA (FIDO2 / passkeys / Windows Hello) which can't be triggered remotely by an attacker. Microsoft enables number matching by default in tenants.

Why the attack works at all

MFA fatigue only works because the attacker already has the first factor — a stolen or guessed password, usually from a breach elsewhere or a prior phishing attempt. Push-based MFA was originally designed to be as low-friction as possible: tap Approve, done. That same low friction is the vulnerability, because a legitimate user who is genuinely being prompted repeatedly, late at night, with no context, will eventually tap Approve just to make it stop — especially if they assume it's a glitch on their own phone rather than an active attack. Number matching directly attacks that assumption: approving now requires reading a number on the sign-in screen and typing the matching number into the app, which is a small enough step that an inattentive tap can no longer approve a sign-in by accident, and a user who does type the number is making a more deliberate (if still exploitable through social engineering) decision.

Worked example

An attacker obtains a valid username and password for an executive's account from a third-party breach dump, unrelated to any Microsoft 365 compromise. At 11pm, they attempt sign-in repeatedly, triggering a burst of MFA push notifications on the executive's phone. With number matching off (an older tenant configuration, or a third-party MFA app that doesn't support it), each notification is a single tap to approve — after the fifteenth notification in ten minutes, the executive, assuming their phone is malfunctioning, taps Approve to stop the noise. The attacker is in. With number matching on, the same burst of prompts each requires the executive to read and type a two-digit number shown only on the attacker's screen — something the legitimate user can't do correctly without seeing that screen, which breaks the attack even if they get fatigued enough to want it to stop.

Common pitfalls

The most common gap is assuming number matching alone is sufficient and stopping there — it closes the accidental-tap failure mode, but a sufficiently patient attacker can pair MFA fatigue with a follow-up phone call impersonating IT support, reading the number to the victim over the phone (a technique sometimes layered on top of the fatigue attack itself). The second is not alerting on the burst pattern itself: a user receiving ten sign-in prompts in five minutes is a strong signal worth surfacing to a SOC regardless of whether any prompt was approved, and Identity Protection's risky sign-in detections should be tuned to catch it. The third is treating MFA fatigue as a training problem rather than a configuration one — the fix that actually closes the hole is enabling number matching and moving toward phishing-resistant methods, not just telling users to be more careful at 11pm.