MFA Fatigue (Push Bombing): How the Attack Works, How to Detect It, and How to Stop It

MFA fatigue is an attack in which someone who already has a valid password floods the account owner with repeated push-approval prompts until one gets approved. You have probably met the term the way most practitioners do: in an incident writeup, a SIEM alert you were triaging, or a vendor advisory that assumed you already knew it.

Most explainers stop at "don't tap approve." This one goes where they do not: the exact log signal each attack leaves in your identity provider, and the specific control that ends it. We will decode the technique and its MITRE mapping, walk the real attack chains from the primary incident reports, name the detection strings a SOC hunts, configure the vendor controls that defeat it, and place all of it inside CISA's phishing-resistance hierarchy, where number matching is the interim step and passkeys are the endgame.

What is MFA fatigue?

MFA fatigue - also called MFA bombing or push bombing - is an attack where someone who already has your password floods your authenticator app with repeated login-approval prompts until you approve one out of confusion or annoyance. That single tap bypasses multi-factor authentication and hands over the account. MITRE tracks it as technique T1621.

The technique has several names, and it helps to recognize all of them. Vendors call it MFA prompt spamming or MFA bombing; CISA uses the term "push bombing." They describe the same behavior: bombarding a user with push notifications until one is accepted. In MITRE ATT&CK it is T1621, Multi-Factor Authentication Request Generation, a Credential Access technique. The name matters because it fixes the scope: this is a second-factor bypass that begins after the password is already gone, not a way to steal the password itself.

How does an MFA fatigue attack work?

The attack rests on one fact: a real person has to approve the prompt. Everything else is engineered to make that approval happen. The chain is short:

1. The attacker already holds valid credentials. They were phished, bought on a criminal market, or lifted by an infostealer. MFA fatigue assumes this step is done.
2. They trigger a flood of push-approval prompts by repeatedly attempting to sign in, sending notification after notification to the victim's authenticator.
3. They often add a social-engineering nudge - a call or message impersonating IT support to talk the target into approving. In the Uber breach the attacker pretended to be Uber IT support to convince the employee to accept.
4. The victim approves one prompt out of confusion, annoyance, or reflex, and the attacker inherits the authenticated session.

Why does flooding work at all? Because the odds favor the attacker over enough prompts. Microsoft's own telemetry found that about 1% of users will accept a simple approval request on the first try, and Microsoft reports these attacks are on the rise. One percent sounds small until it is multiplied across a flood aimed at one person, or across a whole workforce. The control target, then, is not the user's willpower. It is the blind tap itself, which is exactly what the fix in a later section removes.

What does a real MFA fatigue attack look like?

The technique is not theoretical, and it did not stop being used after 2022. Four documented cases show the pattern:

• Uber, September 2022: An attacker used the stolen credentials of an external contractor, flooded the account with 2FA requests until one was accepted, and Uber tied the breach to the Lapsus$ group. Uber's own account notes the contractor's corporate password was likely purchased on the dark web after malware exposed it. This is the canonical MFA-fatigue breach.
• Cisco, May 2022: According to Cisco Talos, the attacker ran voice-phishing calls under the guise of trusted organizations to convince the victim to accept MFA push notifications, and ultimately succeeded in getting a push approved, which granted VPN access.
• Microsoft / Lapsus$ (DEV-0537): Microsoft's threat intelligence team documented the same group using session-token replay and stolen passwords to trigger simple-approval MFA prompts, spamming the target until consent was given.
• Scattered Spider, still active: The CISA and FBI joint advisory maps Scattered Spider to T1621 and states the group sends repeated MFA notification prompts to lead employees to accept. The advisory was last revised in July 2025 with FBI findings as recent as June 2025, and Mandiant's M-Trends 2026 report records voice phishing, the usual delivery vehicle, surging to the second-most-common initial-access vector.

Every one of these attacks left a signal a defender could have caught. That is the next question, and the one page 1 rarely answers.

How do you detect MFA fatigue?

A push-bombing attempt is loud in the logs if you know the event to look for. Each major identity provider records a denied or fraud-reported push under a specific string:

Hunting the burst

The hunting logic is a burst. One denied push is routine; a cluster of denial events for a single user inside a short window is the fatigue signal. Splunk's detection content, for example, alerts on more than ten failed MFA attempts within ten minutes, a threshold you should tune to your environment.

What the denial signals miss

One honest limit applies here. These strings capture denials and fraud reports, which means they fire when the attack is failing. A successful fatigue attack ends in an approval, which looks like a normal sign-in. So pair the denial bursts with the signals that catch the successful case: impossible travel, a new device, or an anomalous session immediately after a run of denials. Detection tells you an account is being targeted; it does not, on its own, tell you the attacker got in.

A quick note on the Entra string: 500121 appears in the sign-in logs as a failure reason, and the "Authentication failed during strong authentication request" wording comes from Microsoft's support answers, not the canonical AADSTS error reference. Treat it as a sign-in-log signal, which is how detection content uses it.

How do you stop MFA fatigue attacks?

Detection tells you it is happening; the following controls make it stop working. Each one attacks the same weakness, the blind approval, and each is configured differently.

Microsoft Authenticator: number matching

When a user responds to a push, the app shows a number from the sign-in screen that the user must type in to approve. Number matching is enabled for all Authenticator push notifications, and users cannot opt out. Pair it with additional context, which shows the requesting application's name and the sign-in location on the prompt, so an out-of-place request is easier to reject.

Okta Verify: number challenge

Okta presents a number in the Sign-In Widget that the user selects in the app. Unlike Microsoft's mandatory setting, this is admin-selectable: you can enforce it never, only for high-risk sign-ins, or on all push challenges. Enforce it on all push challenges where the risk warrants, and add ThreatInsight, which evaluates sign-in requests against IP reputation and can log and block traffic from known-malicious addresses before authentication.

Cisco Duo: Verified Duo Push

Duo can require the user to enter a three-to-six-digit code, defaulting to three digits, before the push is approved. Note the defaults: Verified Push is off by default for Duo Advantage and Premier, and it needs a recent Duo Mobile version, so confirm both before you rely on it.

Alongside these, rate-limiting and lockout of repeated push attempts blunt the flood, and fraud reporting turns a targeted user into an alert source. Each control works by the same mechanism: it replaces a one-tap approval with an action the attacker cannot complete from the outside. Verify the exact options against your own IdP version, because defaults and available settings change between editions.

Is number matching enough to stop MFA fatigue?

Number matching is a strong control, and it is not the finish line. CISA's guidance is precise about this. In its ranking of MFA strength, app-based push with number matching is listed as resistant to push bombing, while the same push without number matching is vulnerable to it. That is a real improvement, and it is why turning number matching on is the right first move.

But it is an interim control, not a cure. The mechanism still depends on a human completing an action, so a determined attacker who has a user on the phone can still read them the number and talk them through approving it. Number matching raises the effort; it does not remove the person from the loop.

The hierarchy, and the endgame

CISA places the durable fix above it. The hierarchy runs from phishing-resistant methods at the top - FIDO/WebAuthn and PKI-based authentication, where CISA calls phishing-resistant MFA the "gold standard" and push bombing simply does not apply - down through app-based push with number matching in the middle, to SMS and voice at the weakest end. The endgame is migrating to phishing-resistant passkeys, and the shift is well underway: the FIDO Alliance estimates 5 billion passkeys are now in use worldwide, with 75% of people having enabled a passkey on at least one account. Where number matching removes the blind tap, a passkey removes the approvable prompt entirely.

The bottom line

MFA fatigue works only because a real person is in the loop to tap approve. That single dependency is also the whole defense. Make the tap mean something with number matching, number challenge, or Verified Push; watch for the denial events the attempts leave in your logs; and plan the move to phishing-resistant passkeys, which take the approvable prompt off the table.

Three concrete steps follow from that. Check your identity provider's push-denial logs for the events above and set an alert on a burst. Turn on number matching, the Okta number challenge, or Verified Duo Push, and confirm the settings against your edition. And put the passkey migration on the roadmap, because it is where the attack stops being possible rather than merely harder.