MFA fatigue is not a user problem

Here is the incident, and it is always roughly the same incident.

An attacker has a valid password — bought, phished, or reused from a breach three years ago. The only thing between them and the account is a push notification. So they log in. And again. And again. The victim's phone lights up at 2am, 2:01, 2:03. Somewhere around the fortieth prompt, half asleep and wanting it to stop, they tap Approve.

The post-incident meeting then produces the same conclusion it always does: we need to retrain staff on MFA hygiene.

We would like to gently push back on that.

The user did the thing the system asked them to do

Think about what actually happened. Your identity provider received forty authentication attempts against one account, from an unusual location, in under five minutes, and its considered response was to keep politely asking the user whether that was fine. It never once decided this pattern was strange. It never rate-limited. It never fell back to something the attacker could not answer.

The person holding the phone is the last control in that chain, and they are the only part of it we are proposing to fix with a slideshow.

If a burst of forty prompts is not, on its own, enough for your system to say "hang on," then the fatigue attack is not exploiting your users. It is exploiting your configuration, and it will keep working no matter how many training modules people click through.

What actually stops it

The good news is that this one is not subtle to fix. In rough order of impact:

Number matching. The single highest-leverage change. Instead of a yes/no push, the login screen shows a two-digit number and the user has to type it into the app. Now an attacker spamming prompts cannot get in by wearing someone down, because approval requires information the victim only has if they are the one actually logging in. Most major IdPs support this. Turn it on.

Rate limits with teeth. Three failed or ignored prompts inside a few minutes should lock the flow and force a stronger step, not queue up a fourth. This is a setting, not a project.

Context in the prompt. "Sign-in from Frankfurt on Windows" is a very different prompt to approve than a blank "Approve sign-in?" at 2am. Give people something to disagree with.

Phishing-resistant factors for the accounts that matter. For admins and anyone near production, get off push entirely and onto passkeys or hardware keys. A WebAuthn credential is bound to the origin. There is no prompt to fatigue, because there is no prompt.

Now the part your SOC owns

Even with all of that, treat a prompt storm as a detection, not a footnote. This is the bit teams skip.

A cluster of MFA challenges to one identity in a short window is one of the cleanest signals you will ever get. It means somebody already has the password. The account is compromised in every way except the last step — and you are being told about it in real time, before the breach, which almost never happens.

So write the rule. In our own detection work the pattern we alert on is simple: N or more authentication challenges to a single principal within a rolling window, from a new ASN or geo. When it fires, the triage agent pulls the recent sign-in history, checks whether any of the prompts were approved, and if one was, it is already drafting the session revocation before an analyst has finished reading the alert.

That is the difference between "we retrained the team" and "we caught it at 2:04." One of those is a control. The other is a story you tell after the fact.

So, the training?

Sure, tell people what a fatigue attack looks like — it does no harm, and someone who has seen the pattern once is more likely to report the next one. Just do not let it be the fix. "Be more careful" has never once survived contact with a tired human at 2am, and it is not going to start now.

Fix the configuration. Watch for the storm. Then, if you like, run the training — so that the humans become another sensor instead of the last line of a defence that should never have reached them.