6 MFA Fatigue Defenses That Stop Push Bombing Attacks
MFA fatigue, the attack also known as push bombing, is stopped by removing the one-tap approval from your identity stack: turn on number matching for every push-based authenticator, migrate privileged users to phishing-resistant methods such as FIDO2 security keys, cap how many prompts an account can generate, and alert whenever approval requests pile up. The attack only works because approving costs the user a reflex rather than a decision. CISA ranks phishing-resistant MFA as the control to build toward and treats number matching as the interim mitigation to enable while that migration runs, and the six defenses below follow that same ordering.
How Push Bombing Works
The attacker already has a valid password, bought from an infostealer dump or replayed from a breach. The password alone is not enough because the second factor blocks the login, so the attacker scripts repeated sign-in attempts, and every attempt pushes an approval notification to the victim’s phone. MITRE ATT&CK documents the pattern as Multi-Factor Authentication Request Generation, and records that both LAPSUS$ and Scattered Spider have run it against real targets, which places this technique in the commodity threat landscape rather than the theoretical one.
The canonical case is Uber’s September 2022 incident. In the company’s own incident update, an attacker repeatedly tried to log in to a contractor’s Uber account, and each attempt generated a two-factor approval request on the contractor’s phone, which initially blocked access; the account fell only when the contractor finally accepted one of the prompts. From there the attacker reached internal tools and wider permissions, which is the standard blast radius when a fatigue win lands on an account with standing access.
Turn On Number Matching
Number matching changes the approval from a tap into a proof: the sign-in screen shows a number, and the authenticator app will not submit an approval until the user types that number back. A user receiving a midnight flood of notifications cannot approve any of them by accident or annoyance, because the numbers exist only on the login screen the attacker is looking at. Microsoft now keeps number matching explicitly enabled for all Microsoft Authenticator users as default behavior, a change made in direct response to fatigue attacks, so Entra tenants start from this baseline without an opt-in project. Duo ships the same control as Verified Push, Okta as its verified TOTP flow, and CISA’s fact sheet lists those vendor implementations as the same mitigation under different brand names.
Move to Phishing-Resistant MFA
Number matching removes the accidental tap, but the notification channel is still phishable: an adversary-in-the-middle page can relay the number along with the password, because the user is still approving something a website showed them. Phishing-resistant methods break that relay. FIDO2 security keys and passkeys bind the authentication ceremony to the legitimate origin, so a proxy domain cannot present the challenge and collect the result. Start the migration where fatigue damage is largest — break-glass accounts, privileged cloud consoles and identity administrators — and treat push approval as the tier below. The migration effort is real: key inventory, recovery procedures and enrollment campaigns all need owners, which is exactly why the interim control matters while the work is underway.
Throttle and Monitor Prompts
Platform controls cut the supply of prompts; detection covers what remains. Conditional access policies that block sign-ins from unexpected countries or non-compliant devices stop the flood before it starts, and identity providers let you cap the number of MFA requests per session or per hour, which turns a bombardment into a handful of notifications followed by a lockout window. On the monitoring side, alert when a single account generates repeated approval requests, repeated denials, or approvals that do not match the sign-in origin — those are the signals MITRE lists for detecting this technique. A denied prompt after a satisfied password is a compromised-password indicator, not noise, so route those events into the same review workflow you use for your audit log integrity checks. If alerts travel through chat automation, apply the same hardening you already enforce on webhook security controls, because a notification pipeline is an identity-adjacent attack surface of its own.
Six Defenses at a Glance
| Defense | What it stops | Effort |
|---|---|---|
| Number matching | Accidental or annoyed approvals; bulk prompt spam | Low |
| Phishing-resistant MFA | Fatigue and adversary-in-the-middle phishing | High |
| Conditional access policies | Prompts from unexpected locations or devices | Medium |
| Prompt rate limits | Notification floods per session or hour | Low |
| Alerting on prompt anomalies | Undetected attacks; converts floods into detections | Medium |
| User reporting drill | Slow response and unreported prompt storms | Low |
Order matters more than inventory: number matching and rate limits are same-week changes on most platforms, conditional access is a sprint, and phishing-resistant enrollment is a longer program with recovery design. Run the reporting drill in the first week too, because a user who treats an unsolicited prompt as a compromised-password report is your earliest sensor, and the fastest path to shutting the flood off at the source.