MFA Fatigue: Stop Push-Bombing Attacks

An attacker with a stolen password may still need a second factor. MFA fatigue, also called push bombing, tries to turn that security control into social pressure: send repeated approval requests until the user accepts one by mistake, habit or exhaustion.

The attack is rarely just a notification problem. It often combines credential theft, help-desk impersonation, real-time calling and rapid session persistence. Defense must connect the identity events into one incident.

How Push Bombing Works

The attacker submits valid credentials to the real login page, generating a push on the victim’s enrolled device. They repeat the attempt or call the user while posing as IT. Once approved, they may register another factor, steal tokens, create mailbox rules or access cloud applications.

CISA guidance on phishing-resistant MFA explicitly identifies push bombing as a threat to weaker MFA methods.

Detect the Sequence, Not One Prompt

High-value signals include:

• many denied or expired prompts for one account;
• pushes from new countries, ASNs or device contexts;
• a successful approval after a burst of failures;
• factor enrollment or password reset immediately afterward;
• help-desk contact during the authentication burst;
• session use from an IP unrelated to the user’s normal history;
• new OAuth grants, mailbox rules or privileged actions.

One denied prompt may be a mistake. Twenty prompts followed by a new device registration is an incident.

Reduce the Attack Surface

Move to phishing-resistant authentication

FIDO2, WebAuthn, passkeys and hardware security keys bind authentication to the legitimate origin. They prevent an attacker on another site from replaying a captured approval or code.

Use number matching as an interim control

Number matching makes blind approval harder. Show application and location context, and prohibit approval when the user did not initiate a login.

Rate-limit authentication requests

Limit prompt generation per account, device and source. Apply backoff without creating an easy denial-of-service path against the user.

Protect enrollment and recovery

Require strong reauthentication for adding a factor. Alert on recovery-method changes and prevent the same weak help-desk process from bypassing the controls.

SOC Detection and Automation

Send identity-provider events to the SIEM with account, source IP, device, application, factor, result and correlation identifier. Enrich source addresses with IP reputation and compare against known user history.

Automate only reversible actions at first: raise risk, require reauthentication, revoke suspicious sessions and open an incident. A broad account lockout during every burst can let attackers disrupt users.

Link identity detections to session-token theft guidance. An approved prompt can be the start of a longer token-abuse chain.

The User and Help-Desk Playbook

Users should deny unsolicited prompts and contact support through a known channel. Support must never ask a user to approve a push. When a report arrives:

1. disable or risk the active sessions;
2. verify the user through an approved process;
3. reset compromised credentials;
4. remove unknown factors and devices;
5. inspect grants, forwarding, rules and privileged changes;
6. preserve source IPs and timeline.

Train help-desk staff against pressure and authority cues. Attackers may call repeatedly or claim an executive emergency.

Metrics

Track prompt bursts, approvals after denial, time from user report to session revocation, new-factor events, accounts on phishing-resistant MFA and incidents involving help-desk contact. Measure migration coverage by privilege, not only total users.

Conclusion

MFA fatigue succeeds when a security decision becomes a reflex. Replace approval-only pushes with origin-bound authentication, detect the whole sequence and give users a simple reporting path. Combine identity evidence with real-time IP reputation so a notification burst becomes an early warning, not the final barrier.