MFA fatigue attacks: why users approve the push that lets an attacker in

MFA fatigue — also called push bombing — is an attack against approval-based second factors. The attacker already has the password. What they lack is the second factor, so they send push notifications over and over until the user taps "Approve" to make it stop.

It is not a flaw in the phone; it is a flaw in the design of "approve with one tap".

How the attack runs

1. Get a valid password. Phishing, credential stuffing, a reused password from a breach.
2. Start signing in. Each attempt triggers a push notification to the user's phone.
3. Bombard the user. Dozens of prompts in a short window, often at night.
4. Wait for the mistake. The user approves to stop the noise, or approves believing it is a glitch.
5. Use the session. The attacker is in, with a legitimate login and a valid second factor.

Variations add a phone call or a message posing as IT support: "we're seeing suspicious activity, please approve the prompt."

Why users approve

• The prompts are indistinguishable and endless.
• The application gives no context: no location, no application name, no way to say "this wasn't me" except "Deny".
• Denying feels like it might lock the account.
• Users are trained to unblock themselves.

The fix is not more training. It is changing what the prompt shows and what the system accepts.

Controls that work

1. Number matching. The sign-in page shows a number that the user must type into the authenticator. A blind "Approve" no longer completes the login, and the attacker has to know the number.

2. Context in the prompt. Show the application, the approximate location and the IP. A prompt with context is a decision; one without is a reflex.

3. Rate limiting and lockouts. Suppress repeated pushes, cap the number per hour, and lock the account after several denials instead of re-prompting forever. NIST SP 800-63B calls for verifier throttling for exactly this reason.

4. Phishing-resistant MFA. Passkeys and hardware security keys bind the credential to the origin, so there is nothing to approve and nothing to bomb. CISA's guidance is explicit that phishing-resistant MFA is the target state, not an optional upgrade.

5. Risk-based step-up. If a login comes from a new country or an unusual device, require a stronger factor — or block it — instead of sending another push.

6. Detection. Alert on many MFA prompts for one account in a short window, and on repeated denials. That pattern is the attack in progress.

What does not work well enough

• SMS codes. Not push-bombable in the same way, but vulnerable to SIM swap and interception; NIST classifies SMS as restricted.
• "Just train users." Awareness helps, but fatigue is the point of the attack.
• Longer push timeouts. Only delays the approval.
• Hiding the Deny button. Makes the problem worse: users cannot report the attack.

A deployment order

1. Turn on number matching for every push-based factor.
2. Add context to the prompt.
3. Add rate limits and lockouts on the identity provider side.
4. Move administrators and high-risk users to passkeys or security keys first.
5. Roll passkeys out to everyone, keeping TOTP as the fallback.
6. Wire alerts for push storms and repeated denials.

How Casdoor handles it

Casdoor supports TOTP, SMS, email and RADIUS second factors plus WebAuthn/passkeys as a primary or additional factor, configured per organization. That means administrators can require passkeys for privileged accounts while allowing TOTP for the rest — and retire push-style approvals where they add risk without adding much security.

See the MFA documentation.

Related reading: MFA vs 2FA, what MFA covers and passkey vs password.

Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.