Multi-Factor Authentication Fatigue Attacks: How Push-Bombing Actually Works

This attack does not try to break multi-factor authentication cryptographically at all. It targets something far less technical: how many push notifications a tired, annoyed person will tap "approve" on just to make them stop.

A dozen push prompts in ten minutes is not a glitch. It is a deliberate attempt to exhaust your judgment.

In this post

1. The prerequisite: how the attacker already has your password
2. The attack itself, step by step
3. Why this specifically targets push-based 2FA
4. Documented real-world incidents
5. Why this counts as social engineering, not a technical exploit
6. Defenses that actually close the gap

MFA fatigue, commonly called push-bombing or MFA bombing, is one of the more consequential authentication attacks to emerge in recent years, precisely because it sidesteps the cryptographic strength of MFA entirely and targets the human approving it instead. Several high-profile corporate breaches in recent years have traced back specifically to this technique, which is part of why it deserves a more detailed explanation than a passing mention.

The prerequisite: how the attacker already has your password

This attack requires one thing to already be true before it starts: the attacker has valid, correct login credentials, typically obtained through a previous credential stuffing attempt, a phishing page, or a prior data breach, covered in more depth in an earlier post on this blog about credential stuffing specifically. MFA fatigue is not a way to guess or bypass a password, it is what an attacker does once they already have one that works, and hits the second factor as the remaining obstacle.

The attack itself, step by step

1. The attacker enters the victim's valid, already-obtained username and password into the legitimate login page
2. This triggers a genuine, real push notification to the victim's authenticator app, asking them to approve or deny the login attempt, exactly as it would for the account owner's own legitimate login
3. The victim, not having attempted to log in themselves, denies or ignores the request
4. The attacker repeats the login attempt again, and again, sometimes dozens of times over minutes or hours, generating a continuous stream of push notifications
5. Eventually, out of confusion, annoyance, or an assumption that it must be a glitch or a legitimate system issue, the victim taps approve on one of the repeated prompts, simply to make the notifications stop
6. The attacker now has a fully authenticated session, having never needed to defeat MFA technically at any point in the process

Why this specifically targets push-based 2FA

This attack works specifically against MFA methods that present a simple approve or deny decision with no additional context, most commonly basic push notifications. It does not work against time-based one-time codes from an authenticator app, since those require the victim to actively read and type a specific code, an action that does not happen accidentally or out of fatigue the way tapping a single approve button can. It also does not work against hardware security keys, which require physical possession and a deliberate physical action, making repeated remote prompts functionally impossible to generate in the same way. This distinction is precisely why security guidance has increasingly recommended number matching, a specific additional step covered further below, or moving to phishing-resistant methods entirely for higher-risk accounts.

Documented real-world incidents

This is not a theoretical attack. It has been directly attributed to several significant, publicly disclosed corporate breaches in recent years, where attackers combined previously obtained credentials with a sustained push-bombing campaign against a single employee until the notifications were approved. The CISA cybersecurity advisories archive has documented this pattern as part of broader guidance on MFA implementation weaknesses, worth reviewing for anyone responsible for an organization's authentication policy specifically.

Why this counts as social engineering, not a technical exploit

It is worth being precise about the categorization here, since it changes what an effective defense actually looks like. This is not a cryptographic weakness in MFA, and it is not a software vulnerability in any conventional sense. It is a social engineering attack that happens to route itself through a technical channel, exploiting a predictable human response to repeated, disruptive interruption, the same underlying principle behind other fatigue and pressure-based social engineering techniques, just automated and applied specifically against an authentication prompt rather than a phone call or email.

Why blaming the victim here misses the point: a person receiving a dozen unexpected push notifications at an inconvenient moment, sometimes deliberately timed for late at night or during a busy period, approving one out of confusion or fatigue is a predictable human response to a deliberately engineered situation, not a personal failure of judgment. The fix belongs primarily at the policy and technology level, not as an expectation that every employee will perfectly resist a sustained, deliberately disorienting pressure campaign every single time.

Defenses that actually close the gap

• Number matching. Requiring the user to enter a specific number displayed on the login screen into the authenticator app, rather than a simple approve or deny tap, which closes off the "accidentally tap approve" failure mode almost entirely, since it requires actively viewing and matching a specific value
• Rate limiting on authentication attempts. Restricting how many MFA prompts can be generated within a given time window, which directly limits an attacker's ability to run a sustained push-bombing campaign in the first place
• Phishing-resistant methods for high-risk accounts. Hardware security keys or passkeys, covered in more depth elsewhere on this blog, structurally prevent this attack entirely, since there is no remote push prompt to bombard in the first place
• User education specifically naming this pattern. Simply knowing this technique exists, and that unexpected repeated prompts should be reported rather than dismissed as a glitch or approved out of fatigue, meaningfully changes how someone responds to it in the moment
• Immediate credential reset upon suspicious approval. Treating any approved login the user does not recognize as a full incident, including an immediate password reset, not just a revoked session

MFA fatigue is a reminder that authentication security is not purely a cryptographic problem, the strongest possible technical implementation still routes through a human decision at some point, and that decision point is exactly where this attack aims. The most effective response is not asking people to be more vigilant indefinitely, it is removing the simple, accidental-approval failure mode from the system design itself, through number matching or a phishing-resistant method that does not offer that failure mode at all.