MFA fatigue (push bombing): detect and stop it in Entra ID

A user calls the service desk: their phone keeps asking them to approve a sign-in they didn't start. Eight prompts in ten minutes, one at two in the morning. That's an MFA fatigue attack, also called push bombing. The attacker already has the password and is hoping the user taps Approve to make the noise stop, or by mistake.

The prompts themselves tell you something important: Entra ID only asks for MFA after the password has been accepted. So a user getting unexpected MFA prompts has a compromised password, even if every prompt was denied. Treat it that way.

Does number matching stop MFA fatigue?

It helps a lot. Microsoft Authenticator push notifications now require number matching: the user has to type the number shown on the sign-in screen, which the attacker can see but the user can't. A sleepy tap on Approve no longer works. Authenticator also shows the app and location of the sign-in, which makes a strange request easier to spot.

It doesn't end the attack, though. Attackers now pair the prompts with a phone call or Teams message pretending to be IT: "we're fixing your account, read me the number you see". And users who registered SMS or voice calls as their method still get the old, easy-to-approve prompts. So detection still matters.

How do I detect MFA fatigue in Entra ID sign-in logs?

Denied MFA prompts show up in the sign-in logs with error code 500121 ("Authentication failed during strong authentication request"). The Authentication details tab on each sign-in says why, for example "MFA denied; user declined the authentication" or that the user didn't respond to the notification.

One 500121 means very little: people dismiss prompts by accident all the time. What you're looking for is:

• Several 500121 failures for one user within an hour, especially outside working hours.
• From an IP or country the user has never signed in from, often a hosting provider or VPN service.
• Followed by a successful sign-in from that same IP. That's the one that matters most: the user gave in.

In Sentinel or Log Analytics:

let denials = SigninLogs
| where TimeGenerated > ago(7d) and ResultType == "500121"
| summarize Denials = count(), FirstDenial = min(TimeGenerated), LastDenial = max(TimeGenerated), IPs = make_set(IPAddress, 10)
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where Denials >= 3;
denials
| join kind=leftouter (
    SigninLogs
    | where TimeGenerated > ago(7d) and ResultType == "0"
    | project UserPrincipalName, SuccessTime = TimeGenerated, SuccessIP = IPAddress
  ) on UserPrincipalName
| extend ApprovedAfter = SuccessTime between (FirstDenial .. LastDenial + 1h) and set_has_element(IPs, SuccessIP)
| summarize Denials = max(Denials), Approvals = countif(ApprovedAfter), IPs = take_any(IPs) by UserPrincipalName, FirstDenial
| order by Approvals desc, Denials desc

Any row with Approvals above zero goes to the top of your queue.

What should I do if a user approved the prompt?

1. Revoke sessions and reset the password at once. The attacker has a valid session; the reset alone doesn't end it.
2. Check the user's MFA methods. Registering the attacker's own authenticator app is often the very next step, so they don't need the user again. Look for "User registered security info" in the Entra audit log and remove anything the user doesn't recognise.
3. Check the mailbox for new inbox rules and forwarding. The inbox rules guide has the searches.
4. Review what the session did: files opened in SharePoint and OneDrive, emails sent, app consents granted, all from the attacker's IP.
5. Find out where the password came from. A recent phishing email, reuse of a password from a breach, or a spraying campaign. If it was spraying, others may be affected too; the impossible travel guide covers the sign-in side.

If the user denied every prompt, you still reset the password and revoke sessions, because the password is known. You just don't need the full incident review.

How do I stop MFA fatigue for good?

• Move people off SMS and voice. They're the methods that still allow a simple approve, and SIM-swap is a separate problem. Set the Authenticator registration campaign to nudge users over.
• Use phishing-resistant MFA for admins: passkeys in Authenticator, FIDO2 keys or Windows Hello for Business, enforced with a Conditional Access authentication strength. No push, nothing to approve.
• Add a sign-in risk policy if you have Entra ID P2, so sign-ins from anonymous or unfamiliar locations need a stronger check or get blocked.
• Protect MFA registration with a Conditional Access policy on "Register security information" that requires a trusted location or compliant device, so a stolen password can't be used to register a new method.
• Tell users what to do: an unexpected prompt means their password is known. Deny it, report it, and call the service desk. IT will never ask them to read out a number.

FAQ

Does an MFA prompt mean the attacker has the password?

In Entra ID, yes. With password plus MFA, the prompt only appears after the password is accepted. The exception is passwordless sign-in, where the prompt comes first, so check whether the user is set up for that before concluding.

What is error 500121 in Entra ID?

"Authentication failed during strong authentication request": the MFA step didn't complete. It covers denied prompts, prompts left unanswered and wrong codes. The sign-in's Authentication details tab shows which.

How many denied prompts should trigger an alert?

Three or more for one user within an hour is a reasonable starting point. Any denial followed by a success from the same unfamiliar IP should alert on its own.

Is MFA fatigue still possible with number matching?

Yes, with social engineering: the attacker contacts the user and asks for the number. And it remains fully possible against SMS and voice methods. Number matching makes accidental approval much harder; it doesn't make the account safe.