MFA Fatigue & Push‑Bombing: How Scammers Bypass 2FA and How to Stop It Today

Introduction: What is MFA fatigue (push‑bombing) and why it matters

MFA fatigue—also called push‑bombing or push notification spamming—is a social‑engineering attack in which an adversary triggers repeated push approval requests ("Approve/Deny") to a victim’s mobile authenticator until the user, fatigued or distracted, approves one. A single accidental approval can grant the attacker full access to accounts protected only by push‑style MFA. This technique has been used in campaigns against critical infrastructure and enterprise accounts and is now a mainstream risk for consumers and businesses alike.

The attack exploits human psychology: frequent legitimate prompts, interruptions, and the desire to stop annoying notifications lower the bar for accidental approval. Because push notifications are convenient but not by design phishing‑resistant, attackers combine password theft, brute‑force credential attacks, and push spamming to bypass two‑factor protections.

How push‑bombing works (step‑by‑step) and real‑world trends

Typical push‑bombing attack chain:

1. Credential acquisition: The attacker obtains a username/password via phishing, credential stuffing, or a data breach.
2. Automated login attempts: The attacker repeatedly attempts to authenticate to the service that uses push‑based MFA, triggering thousands of push prompts to the legitimate user.
3. Fatigue or social engineering: The user, interrupted by many approvals, eventually taps “Approve” (or is tricked by a vishing call impersonating IT support), which completes the login.
4. Access and persistence: The attacker uses the session to access accounts, modify MFA settings, register new authenticators, or move laterally within an organization.

Recent government and industry guidance now treat push‑only MFA as insufficient at high assurance levels and recommend phishing‑resistant options or mitigations such as number matching. NIST and U.S. federal playbooks require phishing‑resistant authentication for higher assurance services, and CISA recommends number matching when stronger methods are not yet available.

Practical steps to stop push‑bombing today — immediate and strategic

Below are concrete actions for individuals and organizations. Follow the "quick wins" first, then plan a strategic migration to phishing‑resistant methods.

For individuals (quick actions)

• Don’t approve unexpected prompts: If you get a push approval you didn’t trigger, deny it and change your password immediately. Treat any unprompted MFA request as a red flag.
• Switch to passkeys or hardware security keys where possible: Use FIDO2/WebAuthn passkeys (platform authenticators) or a physical security key (for example, YubiKey or Titan). These methods require a deliberate physical action and are phishing‑resistant. If your service supports passkeys or security keys, enable them now.
• Use authenticator apps with number matching when available: If you must use push MFA, configure number matching so the app requires you to enter the code shown on the login screen—this prevents a blind “Approve” tap from granting access. CISA lists number matching as an interim mitigation.
• Harden your phone and accounts: Add a screen lock, biometric lock, and remove unused accounts from your device. Add a backup hardware key and store it separately.

For organizations (policy & technical controls)

• Require phishing‑resistant MFA for sensitive assets: Move high‑risk accounts (admins, remote access, privileged systems) to phishing‑resistant methods (FIDO2 / hardware keys / passkeys) to satisfy NIST AAL2/AAL3 guidance where applicable. Use the federal playbook and NIST SP 800‑63B as implementation references.
• Disable or limit push approvals for high‑privilege flows: Remove push as the only second factor for privileged logins and for new authenticator registration flows; require hardware keys or additional verification.
• Implement rate‑limiting and lockouts: Block rapid, repeated authentication attempts (account lockouts, CAPTCHA, IP throttling) and detect unusual push‑request volumes.
• Deploy contextual and device risk checks: Use conditional access to require stronger MFA when logins come from new devices, unusual locations, or risky networks.
• Educate users and test response plans: Train employees to treat unexpected push prompts like phishing emails; run tabletop exercises and provide an incident playbook to revoke and reissue credentials quickly when a compromise is suspected.

If you suspect a compromise

1. Immediately deny the push and change your password from a trusted device.
2. Revoke active sessions and logout all devices from the account security page.
3. Remove or reconfigure registered authenticators (unrecognized hardware keys, phone apps) and re‑enroll known good authenticators.
4. Report the attack to your service provider and, where appropriate, to your local cybercrime reporting body or to authorities (for U.S. critical infrastructure, follow CISA/FBI guidance).

Longer‑term strategy: Plan an organizational migration away from push‑only MFA toward passkeys, FIDO2 hardware authenticators, and stronger identity proofing. Maintain backups (secondary hardware keys stored securely) and build account recovery flows that don’t rely on easily‑compromised channels such as SMS or insecure email.

Bottom line

Push notifications improved usability, but attackers have turned that convenience into an attack surface. The most reliable way to stop MFA fatigue and push‑bombing is to remove approval‑style push as the sole factor for high‑risk access and adopt phishing‑resistant authenticators (passkeys or hardware keys). Where immediate migration isn’t possible, harden push flows with number matching, rate limits, device risk checks, and user training. These steps reduce the chance that an attacker will succeed simply by wearing a user down.