Why MFA Fatigue Attacks Work
The failure is not that users are careless. It is that push approval asks a question the user has no way to answer correctly — and asks it dozens of times until they slip.
ThreatNotes4 min read
MFA fatigue — push bombing, prompt spamming, whatever your vendor calls it — has been behind several of the most consequential intrusions of the last few years. The mechanics are almost insultingly simple: the attacker already has a valid password, so they trigger the second factor over and over until the account holder approves one.
The usual reaction is that users need better training. That reaction misreads the failure. The user is being asked a question they are structurally unable to answer.
The prompt contains no useful information
A typical push notification says something close to:
Approve sign-in? Someone is trying to sign in to your account. [Approve] [Deny]
Consider what the recipient must determine to answer correctly: whether this prompt, right now, was caused by their action. And then consider the conditions they’re answering under. It’s 2am. They’re on a train. They signed in to three things this morning and can’t recall which might be re-authenticating. Their laptop does sync in the background. IT pushed something last week.
The prompt gives them no way to distinguish a legitimate login from a fraudulent one. Even a maximally attentive user is guessing. The system asked for a decision while withholding everything needed to make it.
That’s a design defect, not a discipline problem.
Volume converts a low probability into a certainty
Suppose a user approves an unexpected prompt 2% of the time — a genuinely attentive population.
Send one prompt: 2% chance. Send fifty over a night: the probability that all fifty are denied is 0.98⁵⁰, or about 36%. So roughly a 64% chance that at least one gets approved.
The attacker doesn’t need the user to be foolish. They need repetition. And repetition is free.
There’s a second-order effect that’s worse. After the tenth prompt, the user’s mental model stops being “someone is attacking me” and becomes “this thing is broken.” Approving starts to look like a plausible way to stop the noise. Several published incident write-ups describe exactly this reasoning from the victim, sometimes after the attacker phoned them posing as IT and offered approval as the fix.
Why the standard advice underperforms
“Train users to deny unexpected prompts.” Necessary, insufficient. Training raises the per-prompt denial rate; it doesn’t change that the attacker controls the number of attempts. Push the count high enough and you overwhelm any improvement training bought you.
“Users should report suspicious prompts.” Most systems make denying easy and reporting hard. If deny-and-move-on is one tap and reporting is a helpdesk ticket, you get denial without a signal, and your security team never learns an attack is in progress. Meanwhile the attacker keeps going.
“Rate limit the prompts.” Helps, and you should do it. But an attacker who knows the limit spreads attempts across days and hits the account at 3am when judgement is worst. Rate limiting slows the attack; it doesn’t break it.
What actually breaks the attack
Number matching. The login screen displays a two-digit number that the user must type into their authenticator. This is the highest-value change available short of replacing push entirely, because it inverts the interaction: approving now requires information only the person actually at the login screen possesses. A user who didn’t initiate the login has nothing to type. Passive assent stops being possible.
Context in the prompt. Show the application, the geographic location, and the IP. It’s imperfect — attackers proxy through the victim’s region — but a prompt reading “sign-in from Lagos” to someone in Manchester converts an unanswerable question into an obvious one.
Treat the burst as the alert. Ten denied prompts against one account inside five minutes is not noise to be discarded. It is an attack in progress, using a password that is already compromised. Most organisations log denials and alert on none of them. Alerting on denial bursts is cheap and it catches the campaign while it’s still failing.
Phishing-resistant factors. Passkeys and hardware security keys end this class of attack outright, because there is no approval to socially engineer. The credential is cryptographically bound to the origin. There is no prompt to spam, no number to relay, no user decision to exploit. Everything above is mitigation; this is a fix.
The uncomfortable part
If you’re running push-approval MFA today and an attacker has a valid password for one of your users, you are relying on that user making the right call under sustained pressure, repeatedly, with insufficient information, forever. That is not a control. It’s a hope.
Enable number matching this week — it’s a configuration change in every major identity provider and it removes the passive-approval path. Then start the longer project of moving to phishing-resistant factors, beginning with the accounts that would hurt most: administrators, finance, and anyone who can approve a payment or change a DNS record.