MFA Fatigue Attacks Explained: Never Approve an Unexpected Login Prompt
Your phone displays a login approval request. You reject it. Seconds later, another appears. Then another. Perhaps someone calls claiming to be from IT and says approving the next prompt will stop the problem.
This is not a harmless notification glitch. It may be an MFA fatigue attack—also called push bombing or MFA prompt bombing.
The attacker is trying to turn annoyance, confusion, or routine behavior into the final key needed to enter your account.
The short answer
An MFA fatigue attack floods a person with authentication prompts or sends a carefully timed request, hoping they will eventually approve a sign-in they did not start. The attacker may already know the account password, although some passwordless or recovery flows can generate approval prompts in other ways.
If an unexpected prompt appears, deny it. Do not approve it to make the notifications stop. Go directly to the real account, change the password if one is used, review recent sign-ins and active sessions, remove unfamiliar authentication methods, and contact your organization’s security team when the account belongs to work or school.
Number matching makes blind approval harder. Phishing-resistant passkeys and FIDO security keys provide stronger protection because they cryptographically bind authentication to the legitimate service.
What is an MFA fatigue attack?
Multi-factor authentication requires more than one distinct factor to complete a sign-in. A common setup combines a password with a notification sent to a registered phone. The user taps Approve or Deny.
That second step blocks an attacker who only has the password—unless the attacker convinces the account owner to approve the request.
In an MFA fatigue attack, the criminal repeatedly attempts to sign in, generating a stream of push notifications. The goal is psychological rather than cryptographic. The victim may approve because they:
Assume the prompt belongs to a legitimate background sign-in.
Tap the wrong button while clearing notifications.
Believe approval will stop the interruptions.
Become tired of rejecting repeated requests.
Respond to a phone call or message from someone impersonating support.
Approve out of habit without checking the sign-in context.
The authentication system may work exactly as designed. The attacker succeeds by manipulating the human approval step.
How MFA push bombing works
1. The attacker identifies the account
An email address, username, or employee identity may be public, exposed in a breach, obtained through phishing, or collected from company information.
2. The attacker obtains or tests the password
The password may come from credential stuffing, phishing, information-stealing malware, password reuse, or guessing. When a correct password reaches the MFA step, the attacker knows the first barrier has been cleared.
This connects directly to credential stuffing: a stolen password can be tested on another service, and repeated MFA prompts may follow when the reused credential works.
3. The service sends an approval request
The legitimate authentication system contacts the victim’s registered device. Because the notification comes from a real authenticator app, it can look trustworthy even though the sign-in was initiated by an attacker.
4. The requests continue
The attacker may trigger prompts rapidly, spread them across a longer period, or choose a time when the person is likely to be signing in. A more targeted campaign may include a call from a fake help-desk agent.
5. One approval completes the sign-in
If the victim approves, the service treats the second factor as satisfied. The attacker may receive a valid session and immediately search for sensitive information, register another authentication method, change recovery settings, or move into connected systems.
Why the notification looks legitimate
The prompt often is legitimate in a narrow technical sense: it was created by the real service and delivered by the real authenticator app. What is fraudulent is the sign-in behind it.
This creates a dangerous mental shortcut. People are taught to distrust misspelled messages and fake websites, but an MFA prompt may use the correct app, colors, and account name. The safest question is not “Does this notification look real?” It is “Did I personally start this sign-in right now?”
If the answer is no, reject it.
MFA fatigue vs phishing
MFA fatigue and phishing can work together, but they use different pressure points.
| Attack | What the attacker wants | Typical technique |
|---|---|---|
| MFA fatigue | Approval of an attacker-initiated sign-in | Repeated or carefully timed push prompts |
| Credential phishing | Passwords, codes, or session access | Fake login page or deceptive message |
| Voice phishing | Information or direct approval | Caller impersonates support, a bank, or an employer |
| Credential stuffing | A valid reused login | Stolen username/password pairs tested automatically |
| SIM swapping | Control of phone-number-based authentication | Mobile number is transferred to an attacker-controlled SIM |
An attacker may phish the password first, push MFA requests second, and call the victim third. Security advice must account for the combined sequence rather than treating each attack as isolated.
What is number matching?
Traditional push MFA may present a simple choice: Approve or Deny. Number matching adds context. The sign-in screen displays a number, and the authenticator app asks the user to enter or select that same number.
Someone who did not initiate the sign-in normally cannot see the number on the attacker’s screen. This makes accidental or reflexive approval more difficult.
Microsoft’s documentation describes number matching as a security improvement over traditional second-factor push notifications. CISA guidance presents it as an interim protection for organizations that cannot immediately deploy phishing-resistant MFA.
Number matching is safer, not magical. An attacker may call the victim and ask them to enter a specific number, or use another social-engineering story. Never complete a number match unless you just started the associated sign-in and recognize its context.
Why passkeys and security keys are stronger
Phishing-resistant authentication does not rely on a transferable approval or code that can be supplied to the wrong sign-in.
FIDO passkeys and hardware security keys use public-key cryptography. The authenticator produces a response associated with the legitimate website or application. A fake site cannot normally obtain a response that works for the real domain.
This is stronger than asking the person to judge whether an approval prompt is safe. The protocol helps enforce the connection.
A passkey unlocked with a local PIN or biometric can also operate as a multi-factor cryptographic authenticator: the device represents something the user has, while local activation provides another factor. For the broader comparison, see Passkeys vs Passwords vs MFA.
What to do when an unexpected MFA prompt appears
1. Deny the request
Reject the prompt. If the app offers Report fraud, This wasn’t me, or a similar option, use it.
2. Stop interacting with repeated prompts
Do not approve to silence notifications. Do not enter a number supplied by a caller, text message, email, or chat contact.
3. Open the service directly
Use the official app, a trusted bookmark, or a manually entered address. Avoid links included in unexpected warnings about the account.
4. Change the password
If the account uses a password, replace it with a new, unique password. A prompt appearing after an attacker reaches the MFA stage may indicate that the password is already known.
If that password was reused, change it everywhere. A password manager can generate and store a different credential for each service.
5. Review sessions and activity
Look for unfamiliar devices, locations, successful sign-ins, connected apps, email-forwarding rules, security changes, or newly registered authentication methods. Sign out other sessions when the service provides that control.
6. Secure recovery settings
Verify recovery email addresses, phone numbers, backup codes, passkeys, and security keys. Remove anything you do not recognize.
7. Report the event
For a work or school account, contact the real IT or security team through a known channel. Early reporting can help them block sessions, investigate related accounts, and identify a wider campaign.
What if you accidentally approved the request?
Treat the account as compromised. Speed matters, but use a trusted device if you suspect malware on the one you normally use.
Contact your organization’s security team immediately when applicable.
Change the password from the legitimate service.
Revoke active sessions and remembered devices.
Remove unknown authentication and recovery methods.
Review mailbox rules, connected apps, account delegates, and API access.
Check recent messages, files, purchases, and security changes.
Secure accounts connected through the affected email address.
Record the approximate time and details of the prompts for investigation.
Changing the password may not automatically invalidate every active session. Session revocation is a separate and essential step.
Warning signs that the attack is targeted
Take extra care when repeated prompts are accompanied by:
A call from someone claiming to be IT or security support.
A message containing a number to enter into the authenticator.
Pressure to act urgently or secretly.
A request to install remote-access software.
Instructions to disable MFA or register a replacement device.
A claim that approval is required to cancel or block a login.
Knowledge of your employer, role, account name, or recent activity.
Legitimate support staff should not need you to approve a sign-in you did not initiate.
How organizations can reduce MFA fatigue risk
User awareness helps, but organizations should not place the entire burden on users. Safer system design reduces the opportunity for a tired or distracted person to make one costly mistake.
Move to phishing-resistant authentication
Passkeys and FIDO security keys should protect administrators, remote-access systems, email, identity platforms, and other high-value accounts first.
Require number matching and show context
When push MFA remains necessary, display the application, approximate location, and sign-in details. Require the user to match information from the sign-in screen instead of tapping a context-free approval.
Limit repeated prompts
Detect and throttle repeated authentication requests. A large sequence of denied or unanswered prompts should trigger investigation rather than continuing indefinitely.
Monitor authentication events
Alert on unusual geography, impossible travel, unfamiliar devices, repeated failures, correct-password-plus-failed-MFA patterns, and sudden changes to authentication methods.
Make fraud reporting simple
Provide a clear denial-and-report option. Ensure the report creates a meaningful security event rather than only dismissing the notification.
Protect enrollment and recovery
An attacker should not be able to register a new phone, passkey, or recovery method using a weaker process than normal sign-in. Authentication recovery is part of the security boundary.
Train with one memorable rule
The core message should be simple:
If you did not start the sign-in, do not approve it.
Authentication intent matters
NIST defines authentication intent as evidence that the claimant deliberately participated in the authentication process. A button press, device interaction, or other explicit action can help prevent malware or another actor from authenticating without the subscriber’s knowledge.
MFA fatigue exploits the gap between an action and an informed intention. The victim presses Approve, but not because they intended to authorize the attacker’s session. Better authentication design provides context and makes accidental authorization more difficult.
This is why friction is not automatically bad. A small, well-designed verification step can prevent a much larger recovery process.
Frequently asked questions
Does an MFA prompt mean someone knows my password?
It may. In many password-plus-push systems, the prompt appears after the correct password is entered. Some passwordless, recovery, or misconfigured flows may behave differently. Treat an unexplained prompt as a security warning and review the account.
Should I approve a prompt to stop repeated notifications?
No. Approval may complete the attacker’s sign-in. Deny and report the request, then secure the account through the official service.
Can number matching stop MFA fatigue?
It makes blind and accidental approval much harder because the user needs information shown during the original sign-in. It does not prevent every social-engineering attempt, so only complete a match for a sign-in you personally started.
Are authenticator-app codes vulnerable to MFA fatigue?
Time-based codes do not normally generate repeated approval prompts, so they are not vulnerable to push bombing in the same way. They can still be stolen through real-time phishing.
Is SMS vulnerable to push bombing?
SMS generally sends a code rather than an approve/deny prompt, so the fatigue pattern differs. Attackers can still trick users into sharing the code or target the phone number through other methods.
What is the strongest practical MFA option?
For phishing resistance, prefer a properly implemented passkey or FIDO hardware security key. The right choice also depends on account recovery, device management, and the service’s implementation.
The takeaway
MFA fatigue attacks turn a protective notification into a pressure tool. The attacker does not need to break the second factor if the user can be rushed, confused, or exhausted into approving it.
Remember one rule: If you did not start the sign-in, deny the prompt. Then change any exposed password, review sessions and security methods, and report the event when it involves an organization.
For stronger long-term protection, move from simple push approvals to number matching—and from phishable methods to passkeys or FIDO security keys wherever possible.
Explore further: Discover interactive science and technology explainers at ExploreSims.com.