MFA fatigue is an attack on push-based multi-factor authentication (MFA). An attacker who already has a user’s password triggers sign-in after sign-in, sending a stream of approval prompts to the user’s authenticator app, often late at night, until the user taps approve by mistake, out of annoyance or because the attacker contacts them pretending to be IT. It is also called push bombing or MFA prompt bombing. It turns a convenient MFA method into a social engineering target.
At a glance
- Requires a stolen password first; the attack targets the second step.
- Works against simple approve/deny push prompts; often combined with a call or message impersonating IT support.
- Number matching and showing sign-in details make blind approval much harder.
- Phishing-resistant MFA, such as FIDO2 security keys and passkeys, removes the prompt the attack depends on.
- Repeated or denied prompts are a useful warning sign that a password has been compromised.
What problem it solves
Understanding MFA fatigue helps buyers see a gap that “we have MFA” hides. Push approvals are popular because they are easy for users, but the same ease makes them abusable: one careless tap hands the attacker a valid session. Several widely reported breaches have involved attackers wearing users down with prompts or talking them into approving.
Defending against it means changing how push MFA is configured, training users to treat an unexpected prompt as an incident, monitoring for prompt floods and moving high-risk users to methods that don’t depend on approvals.
How it works
Getting the password. The attacker obtains a valid password through phishing, a breach of another site, infostealer malware or password guessing.
Flooding prompts. The attacker attempts to sign in repeatedly, each attempt sending a push notification. Some attackers send a few prompts over a long period, others dozens in quick succession, often at night when users are tired.
Adding pressure. The attacker may call, text or message the user pretending to be the help desk, saying the prompts will stop once they approve one.
Getting in. Once a prompt is approved, the attacker has a signed-in session and may immediately register their own MFA device to keep access.
Defenses.
- Number matching. The user must enter a number shown on the sign-in screen, so they can’t approve without seeing that screen. US government guidance (CISA) recommends it as an interim measure where phishing-resistant MFA isn’t yet in place. Many identity providers support it, and some enable it by default.
- Sign-in context. Showing the application, location and device in the prompt helps users spot requests that aren’t theirs.
- Rate limits and lockouts. Limiting how many prompts can be sent in a period, and alerting on repeated denials.
- Conditional access. Blocking or challenging sign-ins from unmanaged devices or unusual locations before any prompt is sent.
- Protecting enrollment. Requiring strong verification before a new MFA device can be added.
- Detection. Identity threat detection and response (ITDR) and security monitoring tools can flag prompt floods and suspicious approvals.
When it matters for buyers
- When reviewing MFA settings. Confirm number matching is on and plain approve/deny push is off where possible.
- When protecting high-risk users. Administrators, executives and finance staff are prime targets; consider security keys or passkeys.
- At cyber insurance renewal. Some applications ask how MFA is protected against bypass, including push fatigue; wording varies by insurer.
- After a peer or vendor incident. MFA fatigue is a common technique in published breach reports; check your exposure.
- When choosing security monitoring. Ask whether your managed detection service watches identity signals such as prompt floods.
Questions to ask vendors
- Do you support number matching and sign-in context on push prompts, and can we require them?
- Can you limit or throttle repeated push requests and alert on them?
- How do you report denied or unexpected prompts so we can investigate?
- What verification is required to register a new MFA device?
- Can we require phishing-resistant methods for specific users and block push for them?
- Does your monitoring or MDR service detect MFA fatigue patterns, and how quickly?
How it differs from phishing
Phishing tricks a user into handing over credentials, usually through a fake message or login page. MFA fatigue usually starts after that: the attacker already has the password and attacks the approval step. The two often combine, since phishing supplies the password and an impersonation call supplies the pressure to approve. Phishing-resistant MFA addresses both, because there is no code to type into a fake page and no prompt to approve. To teach staff to report unexpected prompts instead of approving them, see our security awareness training overview.