An MFA fatigue attack is a social-engineering technique in which an attacker sends repeated multi-factor authentication requests to a user, hoping the user will eventually approve one.
The attack is also known as:
- MFA push bombing
- Push fatigue
- MFA bombing
- Push notification spam
- MFA request generation
- Approval fatigue
The attacker usually needs the victim’s username and password before the attack begins. After submitting those credentials to a real login system, the attacker repeatedly triggers authentication notifications on the victim’s registered device.
The victim may reject the first few requests. As the notifications continue, however, they may approve one accidentally, assume it was generated by an application they were using, or accept it simply to stop the interruptions.
That single approval can complete the attacker’s login and create a valid authenticated session.
CISA describes push bombing as repeatedly bombarding a user with authentication notifications until they press the approval button. CISA’s phishing-resistant MFA guidance recommends stronger authentication methods that do not depend on simple one-touch approval.
How Does an MFA Fatigue Attack Work?
A typical MFA fatigue attack follows this pattern:
- The attacker obtains or guesses the victim’s password.
- The attacker signs in to the legitimate service.
- The password is accepted.
- The service sends an MFA approval request to the victim’s device.
- The victim rejects or ignores the unexpected request.
- The attacker repeats the login attempt.
- More notifications appear on the victim’s device.
- The victim eventually approves one intentionally or accidentally.
- The attacker receives an authenticated session.
- The attacker attempts to expand or preserve access.
The repeated requests are not usually random notifications created by the attacker. They are genuine authentication prompts generated by the legitimate service because someone is repeatedly entering the correct primary credentials.
This is why an unexpected MFA request is a serious warning sign. It may mean the password is already compromised.
Why Is It Called MFA Fatigue?
The attack attempts to exhaust the user’s attention and patience.
A person who receives one unexplained approval request may reject it. A person who receives dozens—possibly late at night or during a busy workday—may become confused, frustrated, or careless.
Attackers take advantage of several human reactions:
- Notification fatigue
- Distraction
- Curiosity
- Habitual approval
- Fear of losing access
- Desire to stop interruptions
- Confusion about which login triggered the request
Some attackers combine repeated prompts with a phone call, text message, or chat message. They may impersonate technical support and tell the user that approving the notification will fix an account problem or stop the requests.
The repeated prompts create pressure, while social engineering provides a false explanation.
What Does the Attacker Need Before Push Bombing?
In many cases, the attacker already possesses the correct password.
It may have been obtained through:
- Credential stuffing
- Password spraying
- Brute-force guessing
- Phishing
- Information-stealing malware
- A data breach
- Password reuse
- Social engineering
- An infected browser
- Exposed credentials in source code
- A compromised password manager
- Previous access to the account
The failed part of the login is the second factor—not the password.
This means an organization should investigate both the MFA activity and the source of the compromised primary credential.
Why Are MFA Fatigue Attacks Dangerous?
MFA is designed to prevent a stolen password from being enough to access an account. Push bombing attempts to turn the user into the final part of the bypass.
If the user approves the request, the attacker may gain access to:
- Cloud applications
- Internal documents
- Customer data
- Collaboration platforms
- VPN services
- Administrative tools
- Source-code repositories
- Financial systems
- Identity-management portals
- Remote desktops
- Sensitive business applications
After authentication, the attacker may:
- Read private messages
- Download files
- Send internal phishing emails
- Register another MFA method
- Add a trusted device
- Create API tokens
- Change recovery information
- Modify conditional-access rules
- Reset other passwords
- Escalate privileges
- Move through the network
- Deploy malware
- Steal data
- Establish persistent access
MITRE ATT&CK tracks this behavior as T1621: Multi-Factor Authentication Request Generation. MITRE’s T1621 entry describes attackers generating repeated MFA requests and recommends monitoring anomalous prompts, unusual login locations, and suspicious authentication patterns.
Is MFA Fatigue the Same as MFA Bombing?
Yes. The terms are commonly used for the same basic attack.
MFA bombing emphasizes the large number of authentication requests sent to the user.
MFA fatigue emphasizes the user’s eventual exhaustion, confusion, or accidental approval.
Push bombing is another common term because the requests are delivered through mobile push notifications.
MITRE uses the broader name multi-factor authentication request generation.
MFA Fatigue vs. Credential Stuffing
Credential stuffing tests username-and-password combinations stolen from another service.
MFA fatigue may occur after a credential-stuffing attempt successfully identifies a reused password.
The sequence can look like this:
- A password is exposed in an unrelated breach.
- The attacker tests it against the victim’s workplace account.
- The password works.
- MFA blocks the login.
- The attacker repeatedly sends approval requests.
- The victim approves one.
- The attacker gains access.
Credential stuffing defeats the password layer. MFA fatigue targets the approval layer.
MFA Fatigue vs. Password Spraying
Password spraying tests one likely password against many user accounts.
If one password works, the attacker may trigger push notifications for that user.
The password-spraying campaign provides the correct primary credential, while push bombing attempts to complete the second step.
MFA Fatigue vs. Phishing
Phishing attempts to trick a user into revealing credentials or approving a harmful action.
MFA fatigue is itself a form of social engineering, but it may not require a fraudulent website.
The attacker can use the legitimate authentication system to send real prompts. However, phishing and push bombing are often combined.
For example, the attacker may call the victim while pretending to be from the IT department and instruct them to approve the next prompt.
MFA Fatigue vs. MFA Interception
MFA interception attempts to steal a code, token, or authentication response.
MFA fatigue does not necessarily intercept anything. It attempts to convince the legitimate user to authorize the attacker’s session.
Both attacks target the additional authentication step, but the mechanism is different.
MFA Fatigue vs. SIM Swapping
SIM swapping transfers control of the victim’s telephone number to an attacker-controlled device.
It can be used to intercept SMS codes or recovery messages.
MFA fatigue generally targets push-based approval notifications sent to a registered authenticator application.
Both attacks demonstrate why not all MFA methods provide the same level of security.
Why One-Tap Push Approval Can Be Risky
A simple approval prompt may ask only:
- Approve
- Deny
The request may not clearly explain:
- Which application is requesting access
- Where the login originated
- Which device initiated it
- Whether the user recently entered a password
- What action will be authorized
Users can also develop a habit of approving routine notifications without carefully reading them.
A one-tap prompt requires the user to recognize that the request is malicious. A phishing-resistant authenticator verifies more of the login context cryptographically and does not rely solely on the user’s judgment.
What Is Number Matching?
Number matching is a stronger push-authentication design.
Instead of tapping an approval button, the user sees a number on the login screen and must select or enter the matching number in the authenticator application.
An attacker logging in remotely sees the number, but the victim does not. An unsolicited notification without a matching login screen is therefore more obviously suspicious.
Number matching can reduce simple push-bombing attacks, although it is not equivalent to phishing-resistant authentication. An attacker may still attempt to persuade the victim to provide or select the number.
CISA recommends number matching when an organization cannot immediately implement phishing-resistant MFA. CISA’s MFA guidance identifies it as a practical way to reduce mobile push bombardment.
Warning Signs of an MFA Fatigue Attack
Users may notice:
- Repeated MFA notifications they did not initiate
- Prompts arriving late at night
- Several requests appearing within minutes
- Login approval requests from unfamiliar locations
- Notifications naming an application they were not using
- A request followed by a supposed IT-support call
- Text messages asking them to approve a prompt
- A request to share an authentication number
- Password-reset notifications
- An unexpected account-lockout message
- A successful-login alert after rejecting prompts
Security teams may observe:
- Excessive MFA challenges for one account
- Multiple denied or expired prompts
- Rapidly repeated push notifications
- Correct-password events followed by failed MFA
- Prompts originating from unusual IP addresses
- MFA requests from unexpected countries
- New devices generating repeated challenges
- A successful approval after numerous denials
- Authentication outside normal working hours
- Repeated prompts across multiple applications
- A new MFA method registered after approval
- New trusted-device enrollment
- Session creation from a suspicious network
- Attempts to modify authentication policies
MITRE recommends monitoring excessive or anomalous MFA push notifications, especially when they originate from unusual networks or do not correspond to a user-initiated session. MITRE’s detection guidance for T1621 also highlights repeated MFA failures followed by rapid challenges and abnormal cloud authentication activity.
What Should a User Do When an Unexpected MFA Prompt Appears?
If you receive an MFA request you did not initiate:
- Do not approve it.
- Select the option to deny or report the request when available.
- Do not provide an authentication number or code to anyone.
- Change your password through the official website or application.
- Use a trusted device.
- Sign out other active sessions.
- Notify your organization’s security or IT team.
- Review recent login activity.
- Check registered devices and MFA methods.
- Remove anything unfamiliar.
- Watch for calls or messages pretending to be technical support.
- Secure other accounts using the same password.
If notifications continue, place the device in a mode that limits interruptions only after reporting the incident. Simply ignoring the prompts without addressing the compromised password leaves the account under active attack.
How Can Organizations Prevent MFA Fatigue?
Use Phishing-Resistant MFA
The strongest defense is to replace simple push approval with authentication that is resistant to phishing and push manipulation.
Options include:
- FIDO security keys
- Passkeys
- Platform authenticators
- Smart cards
- Certificate-based authentication
- Device-bound cryptographic credentials
These methods verify the legitimate service and use cryptographic proof rather than asking the user to approve a generic remote request.
CISA recommends phishing-resistant MFA because it is not susceptible to common push-bombing and SIM-swapping techniques. Its guidance on Scattered Spider specifically recommends FIDO/WebAuthn-based authentication for high-value accounts.
Enable Number Matching
If push-based MFA must remain in use, enable number matching.
The authenticator should also display useful context, including:
- Application name
- Approximate location
- Device information
- Time
- Type of request
The goal is to make an unsolicited request difficult to mistake for a legitimate one.
Limit the Number of Push Requests
Authentication systems should not allow unlimited MFA notifications.
Controls can include:
- Maximum requests per time period
- Increasing delays
- Temporary suppression
- Risk-based blocking
- Account restrictions
- Security alerts
- Manual review
MITRE recommends placing limits on the maximum number of MFA prompts that can be generated within a period. MITRE’s MFA mitigation guidance also recommends replacing simple one-click approval with stronger methods.
Require a Fresh Primary Login
The service should not permit attackers to generate unlimited MFA requests using stale, partially authenticated, or replayed login attempts.
MFA challenges should be tied to:
- A recent password verification
- One specific session
- One device
- One application
- A limited lifetime
- A defined transaction
Repeated challenge generation should require the authentication process to restart and should be subject to rate limits.
Use Risk-Based Authentication
Organizations can evaluate each login based on:
- Device familiarity
- IP reputation
- Geographic location
- Impossible travel
- User behavior
- Application sensitivity
- Account privilege
- Request frequency
- Previous denials
- Signs of automation
A high-risk attempt can be blocked before an MFA push is sent.
This protects the user from receiving prompts that the authentication system already has good reason to distrust.
Apply Conditional Access
Conditional-access policies can restrict authentication to:
- Managed devices
- Approved applications
- Compliant operating systems
- Expected locations
- Trusted networks
- Supported authentication methods
MITRE recommends preventing MFA prompts from being initiated from suspicious locations or noncompliant devices. MITRE’s account-use mitigation describes using conditional access to restrict risky authentication requests.
Detect Repeated Denials
A sequence of denied or expired MFA requests should not be treated as ordinary user behavior.
The system should:
- Stop generating further prompts
- Alert the security team
- Notify the user
- Restrict the source
- Require password reset
- Revoke suspicious partial sessions
- Investigate the account
A later approval following numerous denials should be treated as high risk, not as proof that the user finally recognized a legitimate request.
Let Users Report Suspicious Prompts
MFA applications should provide a clear option such as:
- Report fraud
- This wasn’t me
- Block this sign-in
Selecting it should:
- Deny the request
- Inform the security team
- Record the event
- Restrict further attempts
- Guide the user through securing the account
A generic “Deny” button provides less information and may leave the campaign active.
Train Users Without Blaming Them
Users should understand that:
- Approve only requests they initiated
- Repeated prompts may mean the password is compromised
- IT staff should not ask them to approve unexpected logins
- Authentication codes should not be shared
- Suspicious prompts should be reported immediately
- Approval is equivalent to authorizing access
MITRE recommends training users to approve only MFA requests associated with logins they initiated and to report suspicious prompts. MITRE’s user-training guidance emphasizes reviewing login location and request context.
Training should be reinforced through intuitive product design. The user should not be the only barrier between the attacker and the account.
Protect Help-Desk and Recovery Workflows
Attackers may contact support after push bombing fails.
They may impersonate the user and request:
- Password reset
- MFA removal
- New device enrollment
- Recovery-code generation
- Phone-number changes
- Temporary bypass credentials
Support teams should follow strong, consistent identity-verification procedures. High-risk changes should require additional review, generate user notifications, and be logged.
Secure MFA-Factor Changes
Replacing or adding an MFA factor should require more than an active session.
OWASP recommends:
- Reauthentication with an existing factor
- Risk-based checks
- Notifications through a separate channel
- Delays or stronger verification for high-value accounts
OWASP’s Multifactor Authentication Cheat Sheet warns that attackers may exploit factor-replacement workflows to take over accounts and lock out legitimate users.
Protect Privileged Accounts First
Phishing-resistant MFA should be prioritized for:
- Administrators
- Executives
- Help-desk staff
- Security personnel
- Cloud administrators
- Developers
- Financial employees
- Remote-access users
- Identity-management teams
A compromised privileged account can be used to weaken authentication for many other users.
Eliminate Password Reuse
Push bombing often begins because the attacker already knows the password.
Organizations should:
- Block breached passwords
- Encourage password managers
- Support long passwords
- Provide passkeys
- Detect credential stuffing
- Monitor password spraying
- Disable default credentials
Preventing primary-credential compromise reduces the opportunity to trigger MFA requests.
Can CAPTCHA Stop MFA Fatigue?
CAPTCHA may reduce automated password attempts before an MFA request is generated, but it does not directly secure push approval.
An attacker with valid credentials may still reach the MFA stage. CAPTCHA can also be solved or bypassed.
It is a supporting anti-automation control, not a replacement for phishing-resistant authentication, number matching, request limits, and risk-based access.
Does MFA Fatigue Mean MFA Is Useless?
No.
MFA remains substantially safer than relying on a password alone. The attack specifically demonstrates that different MFA methods provide different levels of protection.
Simple one-tap push approval depends heavily on the user recognizing every malicious request.
Phishing-resistant MFA uses cryptographic verification and is designed to prevent the user from authenticating to the wrong service or authorizing an unrelated remote session.
The correct response is to improve MFA—not remove it.
Can Number Matching Be Defeated?
Number matching makes basic push bombing much harder, but attackers may still use social engineering.
An attacker might call the victim, impersonate support, and ask them to enter or select the displayed number.
Number matching should therefore be combined with:
- User training
- Request limits
- Login-context display
- Conditional access
- Risk detection
- Secure support procedures
Phishing-resistant MFA remains the stronger long-term solution.
How Should MFA Fatigue Defenses Be Tested?
Testing must be performed only with explicit authorization.
A security review should examine:
- MFA request limits
- Number matching
- Prompt context
- Fraud-reporting options
- Conditional access
- Risk-based blocking
- Push-notification logging
- Alert thresholds
- Factor enrollment
- Factor replacement
- Account recovery
- Help-desk procedures
- Session creation
- Session revocation
- Privileged accounts
- Legacy authentication routes
Testing should use controlled accounts and avoid overwhelming real users with notifications.
The review should confirm what happens after:
- Multiple denials
- Multiple expirations
- A suspicious approval
- A new device login
- A factor change
- A password reset
- A fraud report
What Should an Organization Do After an MFA Fatigue Attack?
Stop Further Authentication Requests
Temporarily restrict the targeted account or authentication source.
Possible measures include:
- Blocking the attacking IP addresses
- Disabling push requests temporarily
- Requiring phishing-resistant authentication
- Applying conditional access
- Resetting the password
- Requiring help-desk verification
Determine Whether a Prompt Was Approved
Investigators should review:
- Authentication logs
- Push-notification records
- Denials and expirations
- Successful approvals
- Source locations
- Device information
- Session creation
- Application access
- Conditional-access decisions
Do not assume the attack failed because most prompts were denied. One approval may have been enough.
Revoke Active Sessions
If a prompt was approved—or if the outcome is uncertain—revoke:
- Browser sessions
- Mobile sessions
- Refresh tokens
- Remembered devices
- Application tokens
- Suspicious OAuth authorizations
- Newly created API keys
Changing the password alone may not terminate an authenticated session.
Reset the Compromised Password
The password should be replaced with a unique value that does not appear in known breach data.
Investigators should identify how the password was obtained and whether it was reused elsewhere.
Review MFA Changes
Check for:
- New authenticator applications
- New phone numbers
- Added security keys
- Generated recovery codes
- Trusted-device enrollment
- MFA removal
- Conditional-access exclusions
Attackers may register their own factor after gaining access.
Review Post-Login Activity
Determine whether the attacker:
- Read email
- Created forwarding rules
- Downloaded files
- Accessed customer data
- Changed permissions
- Sent messages
- Created tokens
- Added accounts
- Modified security settings
- Reached other systems
Notify the User
Explain:
- What activity was detected
- Whether access succeeded
- Which sessions were revoked
- Whether the password was reset
- Which authentication method will now be required
- What activity the user should review
- How to contact official support
What Should a User Do After Accidentally Approving a Prompt?
Act immediately:
- Contact your organization’s security or IT team.
- Change the password from a trusted device.
- Sign out all other sessions.
- Review login activity.
- Remove unfamiliar devices.
- Check enrolled MFA methods.
- Revoke unknown connected applications.
- Review email-forwarding rules.
- Check sensitive transactions and files.
- Scan the device for malware.
- Replace reused passwords on other services.
- Enroll in a passkey or phishing-resistant MFA.
Reporting the mistake quickly gives defenders a better chance of ending the attacker’s session before significant damage occurs.
Can an MFA Fatigue Attack Happen Without Repeated Prompts?
A single unexpected push notification can still be dangerous.
Attackers may rely on timing rather than volume. They may send one request when they believe the victim is already signing in or is likely to approve notifications automatically.
“Fatigue” describes the common repeated-prompt technique, but users should reject and report any authentication request they did not personally initiate.
MFA approval should be treated like unlocking a door. The user should know exactly which login or action is being authorized before approving it.
