Push approval fatigue happens when an attacker with a stolen password triggers sign-in prompts until a tired user taps Approve. The fixes, in order of strength, are phishing resistant MFA such as FIDO or passkeys, number matching as an interim step, and a habit of reporting any prompt you did not start.
What the problem looks like
You are cooking dinner. Your phone buzzes with "Approve sign-in?" You did not sign in. It buzzes again. After a few rounds, or one at a bad moment, you tap Approve to make it stop.
That is the whole attack. The attacker already has your password, perhaps from a breach or a phishing page. The second factor is the only thing left, and a plain push prompt asks a tired human a yes or no question with no way to check it.
What CISA recommends
CISA's MFA guidance calls phishing resistant MFA the standard that organizations should strive for, while noting that any MFA is better than none. It names FIDO and WebAuthn as the widely available phishing resistant option, because the login fails on a fake site even when the user is fooled into visiting it. For organizations that cannot move yet, CISA suggests number matching as an interim step to block mobile push bombardment. The page is archived, so check CISA's current publications for any updated wording.
How number matching changes the prompt
With number matching, the sign-in screen shows a number. To approve, you type that number into your authenticator app. A person who did not start the sign-in has no number to type, so a blind tap no longer works.
It helps, but it is not phishing proof. If a user is on a fake login page that relays the real number to them in real time, they can still type it in. That is why FIDO ranks higher.
Why FIDO and passkeys are different
A passkey is a FIDO based credential stored on a phone, computer or hardware security key. Sign-in uses public key cryptography in a challenge and response exchange, and each passkey is unique to a site or app. According to the FIDO Alliance, passkeys are designed so that there are no shared secrets, which means a server breach does not expose reusable passwords. See our guide to passkeys for developer accounts.
What to do this week
For you:
- Treat any prompt you did not start as an attack, and report it.
- Change the password for that account, because the prompt means someone has it.
- Where a service offers number matching, switch it on.
- Where it offers a passkey or security key, add one.
For a team:
- List which systems still rely on plain push approval. Source control, cloud consoles and the CI system come first.
- Move those systems to number matching, then to FIDO.
- Remove SMS codes as a fallback where you can, since a fallback is what attackers ask for.
- Make reporting a prompt easy and blame free.
A short script for users
Give people one sentence to follow: "If you did not just try to sign in, tap Deny and message security." Put it on a card or in the sign-in help page. A clear rule beats a vague warning at the exact moment someone is tired.
Quick check
Is number matching enough?
It is a real improvement over plain push prompts, and CISA suggests it as an interim step. It is weaker than FIDO or passkeys, which fail on a fake site by design.
I tapped Approve by mistake. What now?
Report it straight away, change the account password, revoke active sessions and review recent activity on the account. Treat it as a possible compromise until you have checked.
Sources
Last reviewed: 19 October 2026.
