# MFA fatigue and push bombing

Source: https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

## How it works

Push-based MFA sends a notification to the user's phone asking them to approve or deny a sign-in. It was designed to be faster and friendlier than typing a code. An attacker who already holds a valid password, usually from a breach dump, a phishing kit, or an infostealer, signs in repeatedly, which fires a push prompt each time. The victim's phone buzzes, once, then again, then again, often late at night or during a meeting. Some campaigns pair the barrage with a message or a call posing as IT, telling the user to approve the prompt to make it stop, or claiming a legitimate system issue caused it. Eventually a tired, annoyed, or trusting user taps approve, and the attacker is authenticated.

## Why it works

Approve or deny push MFA outsources a security decision to a person under manufactured pressure, with almost no context to make it well. The default prompt on many systems shows nothing more than an app name and a timestamp, no location, no device, no reason. A user has no way to tell a legitimate re-authentication from an attacker's replay, and the interface offers a one-tap escape from an annoying, repeating interruption. This is not a cryptographic weakness in MFA; the factor itself works exactly as designed. The control assumption that fails is that a human under repeated pressure will reliably make a correct security judgment with no supporting information, which is not a safe assumption at any scale.

## How to detect it

- A burst of MFA push requests to the same user within a short window, especially several denied or ignored prompts followed by one approval.
- MFA approvals immediately following failed password attempts against the same account.
- Approvals occurring at unusual hours relative to the user's normal activity pattern.

Be honest about the limits: users legitimately mistype passwords and re-trigger prompts, and a genuine device switch or app reinstall can also generate a burst of pushes. Volume and timing alone are suggestive, not conclusive, so pair this with an interview step or automated context (location, device) before treating a burst as confirmed compromise.

## How to stop it

- **Turn on number matching** so the user must enter a code shown on the login screen into the phone app, which removes blind, one-tap approval.
- **Show context in the prompt**: application name, approximate location, and device, so a user has real information to judge against.
- **Rate-limit and alert on repeated prompts** to the same user in a short window, and consider automatically locking the account after a threshold rather than leaving it to the user.
- **Move high-value and privileged accounts to [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/)**: FIDO2 security keys and [passkeys](https://startwithidentity.com/glossary/passkey/) have no approve-or-deny prompt to wear a user down with.
- **Train help desks and users** on the specific social-engineering script ("this is IT, please approve") rather than generic phishing awareness, since this attack has no fake login page to spot.

## Seen in the wild

- [MFA fatigue and push bombing: defeating MFA without breaking it](https://startwithidentity.com/breaches/mfa-fatigue-push-bombing/), covering the 2022 Uber breach and the pattern's evolution

## Sources

- [MITRE ATT&CK T1621: Multi-Factor Authentication Request Generation](https://attack.mitre.org/techniques/T1621/)
- [CISA: Implementing Phishing-Resistant MFA](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf)