MFA fatigue attacks: how push bombing works and how to stop it
MFA fatigue, also called push bombing, is an attack where someone who already has a stolen password floods the account owner with approval prompts until one is accepted. It works because tapping Approve is a weak signal of intent. Number matching, richer context and phishing-resistant methods such as FIDO2/WebAuthn close most of the gap.
What is an MFA fatigue attack?
Many organisations protect accounts with a password plus a push notification sent to a phone app. The user taps Approve and the sign-in completes. That design assumes a prompt only appears when the real user is signing in. An MFA fatigue attack breaks that assumption.
The attacker first obtains a valid password. Common routes include phishing, reuse of credentials leaked elsewhere, or password guessing. The password alone is not enough, so the attacker repeatedly attempts to sign in. Each attempt triggers a new push to the victim’s device. The goal is to wear the user down, or to confuse them, until they approve a prompt.
How push bombing works in practice
The attack needs very little skill once a password is in hand. The attacker can automate sign-in attempts and let the identity provider do the rest by sending prompts. Several patterns make approval more likely:
- Volume. A burst of prompts, especially at night or at a busy time of day, can push a user to approve just to make the notifications stop.
- Timing. A prompt that arrives when the user expects to sign in, such as the start of the working day, looks plausible.
- Social engineering. The attacker may contact the user by message or phone, pose as IT support, and ask them to accept the prompt to resolve a supposed problem.
- Habit. Users who approve prompts all day learn to tap without reading, so a single stray request can slip through.
Once a prompt is approved, the attacker has a fully authenticated session and may be able to register their own device or method, which gives them lasting access.
Why approving a push is a weak signal
A simple approve-or-deny prompt carries almost no information. It does not tell the user where the sign-in is coming from, which application is asking, or whether they started it. It also gives the user no way to prove that the request matches something they did. The only evidence is a tap, and a tap can be coaxed out of a tired or distracted person.
This is an analysis of design, not a claim about any specific incident. The weakness is that the approval step is not cryptographically tied to the sign-in the user is looking at, so a prompt triggered by an attacker looks the same as one triggered by the user.
Which MFA methods resist this attack
Methods differ in how well they hold up against prompt flooding:
- Simple push approval is the most exposed, because a single tap completes the sign-in.
- Push with number matching asks the user to enter a number shown on the sign-in screen into the app. An attacker who only has the password cannot see that screen, so a blind approval no longer works. Showing additional context, such as the application and approximate location, helps users spot requests they did not start.
- One-time codes avoid the approve-a-prompt flow, but a user can still be tricked into reading a code to an attacker, and codes can be captured on a fake sign-in page.
- Phishing-resistant methods such as FIDO2/WebAuthn do not use approve-a-prompt flows. The authenticator checks the real site it is talking to, so a fake page or a remote attacker cannot complete the sign-in, and there is nothing to spam.
CISA publishes guidance on multifactor authentication, and NIST’s digital identity guidelines describe authenticator types and their strength. Both are listed under further reading.
Why this matters
This section is analysis, not new facts. Stolen passwords are cheap and common, so for many organisations the second factor is the control that actually stands between an attacker and a mailbox or VPN. If that factor can be defeated by persistence alone, the protection is much weaker than it appears. The practical risk is highest for accounts that reach email, remote access and cloud administration, and for users who receive frequent legitimate prompts.
Treat the issue as one of prioritisation. Moving administrators and remote access users to phishing-resistant methods first gives the biggest reduction in exposure, in the same spirit as fixing the most exploitable weaknesses first. For that way of thinking, see Patch prioritization with CVSS, EPSS and KEV.
How to detect MFA fatigue attempts
Identity logs usually hold the evidence. Useful signals to hunt for include:
- Repeated denied or unanswered MFA prompts for one account in a short period.
- A successful sign-in that follows a run of failed or denied prompts.
- Sign-ins from unusual locations, networks or devices for that user.
- New authentication methods or devices registered soon after an unusual sign-in.
- Users reporting prompts they did not trigger, which is often the earliest warning.
Decide in advance what happens when the alert fires: who looks at it, how the account is locked or its sessions revoked, and how the password is reset.
What defenders can do
- Enable number matching and context. Turn on number matching and show the application and location in prompts wherever your MFA product supports it.
- Move high-risk accounts to phishing-resistant MFA. Start with administrators, remote access and email, and use FIDO2/WebAuthn security keys or passkeys where you can.
- Limit prompt volume. Apply rate limits or lockouts so that repeated prompts for one account stop quickly, and block further attempts after repeated denials.
- Alert on the patterns above. Send repeated denials, approval after denials and unusual sign-in locations to the team that can act on them.
- Protect method registration. Require strong verification before a new device or authentication method can be added, since attackers use this to stay in.
- Train users to deny and report. Tell people that an unexpected prompt means someone has their password. They should deny it, report it and change the password, and never approve a prompt to make it stop. Make reporting quick and blame-free.
- Reduce legacy gaps. Retire older protocols and fallback methods that bypass the stronger factor, such as weaker secondary options.
- Respond fast. If a prompt was approved by mistake, revoke sessions, reset the password, review registered methods and check for mailbox rules or other changes.
Related explainers on this site that help with prioritising work: What is the CISA KEV catalog? and What is a CVE?.
Further reading
- CISA: multifactor authentication guidance, an overview of MFA and why to use it.
- NIST SP 800-63B: Digital Identity Guidelines, Authentication and Lifecycle Management, describing authenticator types and assurance levels.
Related free tool: test how long a password would take to crack with our Password Strength Checker. It runs entirely in your browser and nothing you type is sent or stored.
Explainers on Cyber Strike News
- What is CVSS? – how severity scores are built and what they miss
- What is EPSS? – the probability a flaw will be exploited soon