An MFA fatigue attack is an attempt to make a user approve a real multifactor authentication request that the user did not initiate. In this push fatigue attack, the attacker repeatedly triggers push notifications, mixes them with calls or messages, or waits for the victim to accept by mistake, from annoyance, or because the request looks like part of an ordinary sign-in.

The critical prerequisite is that the attacker can reach the MFA challenge. They may already know or have reset the password, possess a valid first factor, or be interacting with a live sign-in flow. The repeated prompts are not random spam; they can be evidence that someone is trying to complete authentication. CISA has recommended number matching as a mitigation for push-bombing attacks because it requires more context than a simple approve button.［1］

Key Takeaways

Never approve an MFA request unless you started the exact sign-in and can match its context.

Denying one prompt is useful, but repeated prompts mean you should secure and report the account.

Number matching reduces accidental approval; it does not make every sign-in or social-engineering request trustworthy.

If you approved by mistake, treat it as a possible account compromise and revoke sessions, reset exposed factors, and investigate activity.

How does an MFA fatigue attack, also called MFA bombing, work?

The attacker first obtains or guesses enough information to pass the initial authentication step. Reused passwords exposed in another breach can enable credential stuffing. A phishing page may capture a password in real time. Help-desk manipulation or recovery abuse can also move the attacker close to the MFA challenge.

Next, the attacker submits sign-in attempts. A push-based system sends a real notification to the registered device. One request may be rejected quickly, so the attacker repeats it at inconvenient times or in rapid bursts. They may call while pretending to be IT, claim that the prompts are part of a security update, or ask the victim to approve a request to make the notifications stop.

If the victim approves, the provider may complete the attacker's sign-in. What happens next depends on the account and controls: the attacker might establish a session, register another factor, access mail or files, change recovery settings, create application grants, or target other services. MFA fatigue describes this approval-pressure technique; it is not a label for every MFA bypass, stolen session, SIM swap, or one-time-code theft.

How do push, TOTP, number matching, and passkeys differ?

Authentication methods present different decisions to the user. A plain push prompt asks whether to approve. A time-based one-time password (TOTP) requires typing a short changing code into the sign-in that the user is viewing. Number matching displays a number in the sign-in and requires entering or selecting the corresponding number in the authenticator. A passkey uses cryptographic authentication bound to the requesting site and requires local user verification or presence.

Method	User action	Fatigue-specific strength	Important limit
Approve/deny push	Tap approve or deny	Low friction, but easy to approve without context	Repetition and social engineering can exploit habit
TOTP	Type a rotating code into the active sign-in	No unsolicited approve button to tap	A phishing proxy can ask for and relay the code
Number matching	Match a number shown by the sign-in	Links the prompt to a visible interaction and reduces blind approval	A caller can still manipulate a user who is viewing an attacker-started flow
Passkey/FIDO2	Use a site-bound credential with local verification	Resists credential replay and many phishing proxies	Enrollment, recovery, device coverage, and fallback methods still matter

Microsoft's number-matching flow shows a number during sign-in and requires the user to enter it in the authenticator to complete approval.［2］ This forces an extra comparison and makes an unexplained push harder to accept, but the user still must verify that they initiated the sign-in. A criminal on the phone can show or read a number if the victim follows the criminal's instructions.

Passkeys and FIDO2 security keys aim at a stronger property: the credential is cryptographically associated with the legitimate site, so it is not a reusable code that a phishing page can simply collect. Microsoft includes passkeys and FIDO2 approaches in its phishing-resistant MFA direction while noting deployment and platform considerations.［3］ Phishing-resistant does not mean incident-proof; recovery channels, legacy methods, malware, and authorized-session abuse still require controls.

What should you do when an unexpected MFA prompt appears?

Do not approve it, and do not enter a number supplied by another person. If the authenticator offers a deny or report option, use it. Close any sign-in pages you did not intentionally open. Then independently inspect the account through the official app or a bookmark.

One accidental notification can result from your own delayed session, a second device, or a service retry. Match the time, location, application, and device information with what you were doing. If there is no clear match, treat it as suspicious. Several requests, a request at an unusual hour, or a simultaneous “IT support” call increases urgency.

Situation	Likely exposure	Immediate action
One prompt during your own sign-in	Possibly legitimate	Compare app, number, location, and device before approving
One prompt with no sign-in by you	Attempt reached the MFA step	Deny/report; review recent activity and secure the password
Repeated prompts or accompanying call	Active pressure attack	Stop engaging; contact support/security independently
Prompt approved by mistake	Possible successful sign-in	Start account recovery and incident review immediately

For a personal account, change the password from a trusted device if the first factor may be known, especially when it was reused. Check recent sign-ins and recovery methods. For a work account, contact the security team or help desk using a known number or internal portal; include the prompt times, displayed location, application, and any caller details. Do not call a number supplied in the suspicious message.

What should you do after approving an MFA prompt by mistake?

Assume the approval may have completed someone else's authentication until evidence shows otherwise. Use the provider's official security page to revoke unfamiliar sessions or sign out other devices. Change the password if it may be compromised. Review registered MFA methods, passkeys, security keys, phone numbers, recovery email, trusted devices, and application connections; remove anything you cannot verify.

Then inspect the resources behind the identity. Check mailbox forwarding and rules, sent messages, cloud-file shares, account delegates, payment settings, developer tokens, and recent changes. An attacker may use a newly established session without generating another MFA prompt. The recovery sequence in Someone Logged Into My Account helps organize these checks.

Exposure level	Response priority	Evidence to preserve
Denied all prompts	Protect the first factor and report the attempts	Times, app names, locations, caller or message details
Approved, no activity yet found	Revoke sessions and reset exposed factors	Sign-in and audit records before they age out
Approved, account changes found	Restore recovery/MFA settings and contain affected services	Before/after settings, new factors, rules, grants, IP/device data
Sensitive work, money, or regulated data exposed	Escalate to the responsible team and follow incident procedure	Provider logs, transaction records, data-access scope, communications

Do not rely on another push prompt to “cancel” the first one. Do not delete evidence before the security team can use it. If financial accounts or payments are involved, contact the institution through a trusted channel. If an attacker persuaded a help desk to modify factors, tell responders so they examine the recovery process rather than only the password.

How can organizations reduce MFA fatigue attacks?

Replace context-free approve/deny prompts with number matching or, where feasible, phishing-resistant methods. Disable weak and unused fallback methods. Apply rate limits, risk-based controls, impossible-travel and unfamiliar-device signals carefully, and alerts for repeated denials or prompt bursts. A control that endlessly resends prompts can amplify the attack.

Give users a visible way to report an unexpected request from the authenticator and a separate trusted way to contact support. Support staff should never ask a user to approve an unexplained prompt or disclose a one-time code. Help-desk verification and factor-reset workflows need protection because attackers may shift to the recovery path when sign-in is harder.

Monitor the whole authentication sequence: password validation, MFA challenges, approvals and denials, factor enrollment, session creation, OAuth grants, and sensitive activity. Correlation matters more than counting prompts alone. Repeated failures followed by one approval and a new device is more meaningful than an isolated retry.

Finally, maintain a tested recovery path. Organizations moving to passkeys or hardware keys should plan enrollment, loss, replacement, accessibility, travel, offline use, and emergency access without silently falling back to a phishable method for everyone. The broader online security guide covers password, device, and recovery layers that remain necessary.

Frequently asked questions

Is an unexpected MFA prompt proof that my password was stolen?

Not absolute proof, but it can mean someone reached the MFA step. Secure the account and review activity rather than assuming the notification was harmless.

Should I deny or ignore the prompt?

Deny and report it when the app supports that option. Then inspect the account independently. Ignoring repeated requests without securing the account leaves the first-factor problem unresolved.

Can number matching stop every MFA fatigue attack?

No. It reduces blind and accidental approval by tying the prompt to a displayed number. Social engineering can still manipulate a user, and other account-recovery paths may remain exposed.

Is TOTP immune to phishing?

No. TOTP avoids an unsolicited approve button, but a real-time phishing site can ask for the code and relay it before it expires.

Are passkeys the same as push MFA?

No. A passkey uses a cryptographic credential bound to a site and local device verification. Push MFA asks a registered app to approve a separate authentication attempt.

What if the prompt appeared while I was signing in?

Match the service, device, location, timing, and number. Reject it if the context does not match the sign-in you started.

Does changing my password end an attacker's approved session?

Not always. Revoke unfamiliar sessions and review factor and recovery changes in addition to changing an exposed password.

Why should I report a denied prompt?

The organization can correlate your report with sign-in attempts, protect other targeted users, block infrastructure, and detect a campaign before someone approves.

This article provides general security education. Authentication options and revocation behavior differ by provider; follow the current recovery instructions for the affected account and your organization's incident process.

Sources

CISA — Implement Number Matching in MFA Applications — https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf
Microsoft Learn — How number matching works in MFA push notifications for Authenticator — https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match
Microsoft Learn — Phishing-resistant MFA — https://learn.microsoft.com/en-us/security/zero-trust/sfi/phishing-resistant-mfa

Sources checked 28 August 2026.

What Is an MFA Fatigue Attack?