Push-based MFA became popular because it is simple: users tap “Approve” and move on. That simplicity is also the weakness. Push prompts turn authentication into a human decision under interruption and pressure, which attackers can manipulate at scale.

MFA fatigue attacks, also called “prompt bombing” or “push bombing”, exploit predictable behavior: when users receive repeated prompts, some will eventually approve one to make it stop, or approve under stress and confusion. This is not a rare edge case. It is a natural outcome of how push MFA is used in real organizations.

This article explains how MFA fatigue works, why it succeeds, and what enterprise teams can do instead.

Related: Types of MFA for Corporates: What Works, What Fails, and How to Recover Securely

What is MFA fatigue (prompt bombing)?

MFA fatigue is an attack pattern where an adversary triggers repeated push prompts for a target account until the user approves one. The attacker usually has already obtained:

• A username (often email).
• A password or another first-step credential.
• The ability to repeatedly initiate login attempts.

The attacker’s goal is not to “crack” MFA. It is to get one human approval.

Why push MFA is vulnerable by design

Push MFA is vulnerable because it depends on:

• User attention at the right moment.
• User understanding of context.
• User willingness to refuse and report.
• Consistent policy controls that limit repeated prompts.

In practice, these assumptions fail:

• Users are busy or distracted.
• Prompts arrive at night or during meetings.
• Users assume “IT is testing something”.
• Repeated prompts normalize approval behavior.
• Reporting paths are unclear or slow.

Push MFA becomes less of a security control and more of a “user training problem”, and training does not scale against automation.

How attackers run MFA fatigue attacks

A typical flow looks like this:

1. Attacker obtains a password (phishing, reuse, breach data).
2. Attacker attempts login repeatedly, generating push prompts.
3. User receives multiple prompts and eventually approves.
4. Attacker enters the session and escalates access or steals tokens.
5. Attacker may add a new factor, set persistence, or trigger recovery changes.

This is why “strong MFA” can still fail if the second factor is a prompt that can be spammed.

Signals that you are vulnerable

Many organizations discover vulnerability only after an incident. You can detect risk earlier by looking for:

• high volume of push prompts per user.
• Repeated prompts clustered in short time windows.
• Approvals after multiple denies.
• Approvals from unusual geographies or device contexts.
• High helpdesk volume related to MFA confusion.
• Users who report “random prompts” without a clear response path.

If you see these patterns, push MFA is already being tested or will be.

What to do instead: enterprise-grade alternatives

You do not have to abandon push MFA overnight, but you should move high-risk access away from approval prompts as the primary control.

1) Prefer phishing-resistant MFA for high-risk access

Phishing-resistant authenticators reduce the attacker’s ability to turn a login into a spammed approval decision. They shift authentication toward cryptographic proof and user presence.

2) Use step-up for sensitive actions, not constant approval prompts

If your program relies on push prompts for every login, fatigue becomes inevitable. A better model is:

• Low friction for normal, low-risk sessions.
• Step-up for privileged operations and high-risk events.
• Stronger factors for Tier 0 and Tier 1 access.

3) Strengthen policies around push prompts (if you must keep them)

If push MFA remains in the stack, apply controls that reduce spam and confusion:

• Rate limit repeated prompts.
• Block repeated attempts after a small number of denies.
• Enforce number matching (where available).
• Require additional context for high-risk prompts.
• Trigger alerts for prompt bombing patterns.

These controls reduce abuse, but they do not eliminate the fundamental weakness: the control is still a human approval under interruption.

4) Fix recovery and factor enrollment so fatigue doesn’t lead to persistence

After a successful push-fatigue approval, attackers often try to add persistence by changing factors or abusing recovery.

That is why recovery must be treated as a high-risk control surface, with clear evidence, rate limits, and audit trails.

How passwordless changes the fatigue equation

Passwordless authentication can reduce reliance on push prompts by removing the password and replacing the primary flow with cryptographic proof. That does not automatically prevent all compromise, but it reduces the number of situations where attackers can repeatedly trigger “approve/deny” prompts as the main barrier.

Conclusion: push MFA is a brittle control at scale

MFA fatigue is not just a user problem. It is a design problem. Push MFA turns authentication into a spammed approval workflow, and attackers exploit that at scale.

If you want resilience, move high-risk access toward phishing-resistant methods, use step-up intelligently, monitor prompt patterns, and ensure recovery and enrollment cannot be abused after a single mistaken approval.