What MFA fatigue is
MFA fatigue is a social-engineering attack against the approval step of multi-factor authentication. The attacker has already obtained a working password, usually from a credential dump, a password-spraying run or an earlier phishing campaign. What they do not have is the second factor. So instead of trying to steal it, they ask for it repeatedly until someone says yes.
The names vary - push bombing, MFA bombing, prompt spamming - but the mechanic is identical. Each attempt generates a genuine notification from the genuine identity provider on the victim's genuine phone. There is no fake page and no forged message anywhere in the attack. That is exactly what makes it hard for a user to reason about.
How the attack runs
Volume alone rarely works against an alert user. What makes the attack effective is the combination of timing and a plausible explanation delivered by a human.
- The attacker authenticates with the stolen password, over and over. Each attempt fires a fresh approval prompt at the victim's device.
- The burst is usually timed for the middle of the night or the start of a holiday, when the victim is least likely to think carefully and most likely to want the noise to stop.
- Often a phone call follows. Someone claiming to be from IT support or the service desk explains that a system migration is generating erroneous prompts and asks the victim to approve the next one to clear the queue.
- The victim approves. The attacker completes authentication and holds a valid session.
- Persistence follows quickly: a mailbox forwarding rule, an added authenticator, or an OAuth application consent, so that access survives the password reset that eventually comes.
That third step is the one worth dwelling on. Prompt spam on its own is annoying and suspicious; prompt spam plus an authoritative voice offering an explanation converts annoyance into compliance. It is the pairing that makes this work, and it is why training that only says "do not approve prompts you did not start" is incomplete. The helpdesk call has to be part of the story.
MFA fatigue is also frequently a second stage rather than a standalone attack. A proxy-based campaign such as adversary-in-the-middle phishing may capture the password while prompt spam handles the approval, and the same operator will pivot between whichever route works. The broader question of what multi-factor authentication does and does not survive is covered in can phishing bypass MFA?.
The signal it leaves
MFA fatigue is one of the more detectable attacks in the phishing family, because it is noisy by design. It cannot work without generating a run of failed and denied authentication events against a single account in a short window - and that run happens before the compromise, not after.
- A cluster of denied or timed-out MFA challenges for one account within minutes, especially outside that user's normal working hours.
- Repeated correct-password, failed-second-factor events, which say plainly that someone has the password and is stuck at the second step.
- The attempts originating from an IP range, hosting provider or country with no history for that account.
- A successful approval arriving at the end of a denied run - the moment the attack landed.
- A new authentication method registered on the account shortly after that approval.
If your identity platform can alert on the first of those patterns, you have a genuine chance to reset the password while the attacker is still knocking. Very few phishing techniques offer that window, which makes it worth the detection rule.
How to shut it down
The controls below are ordered by how much they change the outcome rather than by how easy they are to turn on.
- Move to phishing-resistant authentication. Passkeys and FIDO2 security keys have no approve-or-deny prompt to spam, so the attack has no surface to work against at all.
- Turn on number matching. Instead of tapping Approve, the user must read a number from the login screen and type it into the app - which they cannot do if they are not the one logging in. This is the single highest-value setting if you are staying on push notifications.
- Add extra context to the prompt: the application, the location and the requesting IP, so an approval decision has facts attached to it rather than just a button.
- Rate-limit and lock out. After a handful of denials in a short window, stop issuing prompts for that account and alert instead. Endless retries are the attacker's only real requirement.
- Make an unexpected prompt a reporting event. The instruction has to be "deny it and tell us", not just "deny it" - a denial alone leaves the attacker free to keep trying against someone who has already proved they are awake.
- Tell people the helpdesk will never call and ask them to approve a prompt. Name the pretext explicitly in training, because a rule that does not cover the call is a rule that breaks the moment the call comes.
If an approval has already been given, treat it as an account compromise rather than a near miss: revoke sessions, reset the password, remove any authentication method or mailbox rule added since, and check for application consents. Anyone who realises after the fact that they approved something they should not have can follow the steps in I clicked a phishing link, and the wider control set is set out in phishing tests for employees.