Home / Knowledge hub / MFA fatigue
Knowledge hub
MFA fatigue
Spamming approval prompts until a tired user taps accept.
What it means
MFA fatigue, also called push bombing or prompt bombing, is an attack on push-based multi-factor authentication. The attacker already has the user's password, and keeps trying to sign in so the user's phone fills with approval requests until they accept one, to make it stop or by mistake. The attacker only needs one mistake.
Nothing is broken in the code. The attack targets a person at a bad moment, often at night. MITRE lists it as a technique for gaining access: generating repeated requests so a user eventually accepts one.
Why it matters
It beats a control you may be relying on. A stolen password from a data leak or [[phishing]] page normally gets nowhere against MFA, but a single tap on a prompt hands the attacker the session. After that they look like the real user.
It is cheap, needs no special tools, and can be repeated without limit if your service does not stop it. It also raises an awkward question for audits: the factor was used, yet the person did not intend to approve it.
How it shows up
You meet it wherever the second step is a plain "Approve / Deny" push, in company sign-in, VPNs and the apps that use them. The signs are bursts of prompts for one account, requests from odd places, and users who report prompts they did not start.
Defences: show a number on the sign-in screen that the user must enter on their phone (number matching), show where and what the request is for, limit how many prompts can be sent and lock the account after a few denials, alert on repeated prompts, and move to phishing-resistant factors such as [[passkeys]] or security keys, which have no prompt to approve.
Questions people ask
MFA fatigue, answered
Is MFA fatigue the same as phishing?
No, though both aim for the same result. Phishing tricks the user into giving a code or session. Fatigue wears the user down to approve a real prompt. Both can follow a stolen password.
Does number matching stop it?
It makes blind approval much harder, since the number appears only on the screen where the sign-in began, and the user must enter it on their phone. Someone who did not start the sign-in has no number to enter. It is a strong step but not a complete fix.
Do codes from an app (TOTP) have this problem?
Not in the same way, because there is no prompt to accept. They can still be phished in real time, so they are weaker than hardware keys or passkeys.
What should we do when a user reports unexpected prompts?
Treat it as a sign their password is exposed. Deny the prompts, reset the password, end their sessions and check the account's recent activity.
How do we test our exposure?
Check whether prompts are limited per account and per time, whether repeated denials cause a lock or an alert, and whether the prompt shows context. Review sign-in logs for bursts.
Sources
Where this comes from
Related
Terms that sit next to this one
MFA
A second proof beyond the password, usually a code or a hardware key.
Passkeys
Phishing-resistant sign-in using a key on your device instead of a password.
Phishing
Persuading someone to hand over credentials by posing as a trusted sender.
2FA bypass
Getting past a second sign-in step by exploiting how it is built or enforced.
Adaptive authentication
Asking for more proof when a sign-in looks unusual.
How many prompts before it stops?
We test whether your sign-in limits repeated attempts and prompts, and prove what we found with the requests we sent. If we did not break it, we do not report it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.