What Is MFA Fatigue?
MFA fatigue, also called MFA bombing or push bombing, is the repeated generation of multifactor authentication prompts until a user finally approves one. MITRE tracks this technique as T1621, Multi-Factor Authentication Request Generation.
The mechanism is narrower than many teams describe it. In the common case, the attacker already has the victim's password and gets blocked only by the second factor. Instead of stopping there, the attacker repeatedly triggers push notifications to Microsoft Authenticator, Duo, Okta Verify, or a similar MFA service and tries to wear down the user.
For this article, the scope is Microsoft Entra ID and Microsoft Authenticator push-based MFA, with emphasis on operational detection and tenant hardening. MFA fatigue is not the same thing as password spraying, adversary-in-the-middle phishing, or SIM swapping, although those techniques are often used before or alongside it.
The key risk is simple: a push-based MFA control still depends on a user making the right decision under pressure. If the attacker can create repeated prompts, or pair those prompts with a social-engineering pretext, a control that looked strong in policy can fail in practice.
How MFA Fatigue Works
MITRE's definition is precise: adversaries may attempt to bypass MFA by generating MFA requests sent to users. If they already possess valid credentials, they may be unable to complete the login only because they do not control the second factor. To get around that, they abuse push notifications and hope the user grants access.
That matters because the attack is not a cryptographic break. It is an abuse of authentication workflow design and user approval behavior.
A typical Entra-focused sequence looks like this:
- the attacker obtains a valid username and password through phishing, password spraying, credential stuffing, or help desk social engineering
- the attacker starts an interactive sign-in that requires Microsoft Authenticator approval
- the user receives repeated push notifications
- the attacker keeps retrying, often at times chosen to create confusion or annoyance
- if the user eventually approves one prompt, the attacker gets a valid authenticated session
MITRE also notes a second path that defenders sometimes overlook: if the attacker does not yet have credentials, automatic push generation can also be abused in some self-service password reset scenarios when that workflow is configured to send push notifications.
MFA fatigue is not the same as other identity attacks
The differences matter because the mitigations are not identical.
- Password spraying tries one or a few passwords across many users to get the first valid credential. See Password Spraying: Detection and Prevention for Active Directory and Entra ID.
- MFA fatigue starts after the attacker already has, or has nearly obtained, a valid first factor and is trying to turn a blocked login into an approved one.
- Adversary-in-the-middle phishing proxies the sign-in flow to capture tokens or session context in real time. It does not depend on user annoyance in the same way.
- SIM swapping targets phone-based factors by taking control of the victim's mobile number.
MFA fatigue specifically targets the human approval step in push-based MFA.
Why MFA Fatigue Still Works
MFA fatigue remains effective when three problems overlap: the attacker has a valid first factor, the tenant still relies on prompt-based approvals for important accounts, and the user lacks enough context or friction to safely reject the request.
Microsoft's own phishing-resistant MFA guidance is explicit that traditional MFA methods such as SMS codes, email OTPs, and push notifications are becoming less effective against modern attackers. The document calls out user fatigue and MFA bombing as concrete examples of how attackers bypass legacy MFA patterns.
In practice, MFA fatigue works because:
Push approvals are easy to trigger repeatedly
The attacker does not need to crack a token or defeat a hardware key. They only need a login flow that keeps generating prompts.
Many users still see low-context approval prompts
If the notification does not clearly show the application name and geographic context of the sign-in, the user has less information to distinguish a legitimate login from an attack. Microsoft documents adding that context to Authenticator notifications as a way to improve sign-in security, but ships it turned off: the Microsoft managed default for both the application name and the geographic location is Disabled.
Users can be socially engineered while the prompts arrive
A push request is more likely to be approved if it arrives while the attacker is pressuring the user through a phone or messaging pretext, during a real password reset, or when the user is already expecting some legitimate sign-in activity.
High-value accounts are often protected only by standard MFA
If administrators still rely on standard push approvals instead of phishing-resistant MFA, the attacker's target list becomes much more valuable.
Preconditions for a Successful MFA Fatigue Attack
A successful MFA fatigue attack usually requires the following conditions.
1. The attacker has a valid first factor or can trigger a reset flow
MITRE's baseline assumption is that the attacker already has valid account credentials. In the Entra world, that usually means a stolen password, a password recovered from another intrusion, or a password obtained after Password Spraying: Detection and Prevention for Active Directory and Entra ID.
2. The target uses push-based MFA
The attack depends on the user receiving an approval request. If the target account is restricted to phishing-resistant methods, such as stronger authentication strengths for privileged sign-ins, MFA fatigue becomes much less useful.
3. The tenant has not reduced low-context approvals enough
If the prompt shows only a generic approval request, or if suspicious activity reporting is not enabled, users get less context and defenders get less high-confidence signal when abuse occurs.
4. The account is valuable enough to justify repeated attempts
Administrators, cloud operators, help desk staff, and application administrators are especially attractive because one approved prompt can produce broad follow-on access.
5. Response workflows are too slow
If repeated prompt denials are not investigated quickly, or if suspicious prompt reports do not trigger containment, the attacker can keep trying until a user approves or a second social-engineering step succeeds.
The Attack Chain
A practical MFA fatigue intrusion chain usually looks like this.
Step 1 - Obtain the password
The attacker first gets the password through phishing, password spraying, credential reuse, or social engineering.
Step 2 - Trigger the MFA challenge
The attacker attempts a sign-in to a Microsoft 365, Azure, or Entra-connected workload that requires Authenticator approval.
Step 3 - Repeat the prompt generation
Instead of accepting the failed login, the attacker keeps generating approval requests. This is the behavior MITRE captures in T1621.
Step 4 - Add social pressure
Attackers may pair the prompts with calls or messages that pressure the user to approve one request, often by pretending to be internal support or by exploiting a moment of confusion around a real sign-in or password reset.
Step 5 - Use the approved session immediately
Once the user approves one request, the attacker has what they wanted: a valid session in the target tenant. From there, the next actions depend on privilege and policy coverage. Common follow-on actions include reviewing the directory, discovering privileged roles, searching for application registrations, accessing mailboxes, or changing authentication settings.
The approved prompt is therefore not the incident's end state. It is the pivot point from blocked login to authenticated access.
Detection
There is no single Entra event that says "this was definitely MFA fatigue." The right model is sequence-based detection plus context.
Look for repeated MFA denials against the same user
The most obvious signal is a cluster of repeated sign-in attempts where the same user receives multiple MFA requests and denies or ignores them. In Entra sign-in logs, that often appears as repeated interrupted sign-ins with MFA failure details before any eventual success.
Treat user-reported suspicious prompts as high-confidence evidence
Microsoft's Report suspicious activity feature is the strongest native signal in this workflow. According to Microsoft Learn:
- users who report an unknown MFA prompt as suspicious are set to High User Risk
- the event appears in sign-in logs, audit logs, and risk detections
- in the sign-in logs, the authentication Result detail reads MFA denied
- in the risk detections report, the detection type is User Reported Suspicious Activity, the risk level is High, and the source is End user reported
- the
riskEventTypeisuserReportedSuspiciousActivity, and the reported account returnsriskLevel = highfrom theriskyUsersGraph API
That matters because it lets defenders move from guesswork to a specific, user-confirmed signal.
One documented exception belongs in your queries: Microsoft states that a user isn't reported as High Risk if they perform passwordless authentication. Where part of the population already signs in with passkeys or passwordless phone sign-in, the absence of a high-risk user is not proof that nothing was reported — check the audit log and the sign-in log too.
Correlate the MFA sequence with sign-in context
Investigations should correlate the prompt sequence with:
- source IPs and geographies the user does not usually use
- unusual applications initiating sign-in
- repeated attempts from the same source against one high-value account
- a pattern of denials followed by a single success
- follow-on activity immediately after the successful approval
Pay special attention to privileged identities
A single push-bombing event against an ordinary user is still serious. The same pattern against a Global Administrator, Conditional Access Administrator, or Privileged Role Administrator needs immediate containment.
This is one reason to review Azure Privileged Access: Too Many Global Admins and How to Audit Microsoft Entra ID Security (Azure AD): Practical Review Guide together with this attack pattern.
Avoid one-event conclusions
Users do sometimes deny legitimate prompts. Mobile network changes, sign-ins from a new device, or user confusion can also create noise. The better detector is not one denial. It is a repeated pattern, especially when paired with user-reported suspicious activity, unfamiliar sign-in context, or privileged follow-on actions.
Remediation
Stopping MFA fatigue is not about adding more generic MFA prompts. It is about making malicious approvals harder to trigger, easier to recognize, and less valuable when they do happen.
MITRE frames the same goal in three mitigations for T1621: replace simple push or one-click approvals with stronger mechanisms and implement limits on the maximum number of MFA request prompts a user can receive in a period of time (M1032), block sign-ins from suspicious locations or from locations that do not match the location of the MFA device (M1036), and train users to accept only prompts they initiated and to report the rest (M1017). The Entra controls below are how that translates into a tenant.
1. Verify that Authenticator push flows use number matching
Microsoft states that number matching is enabled for all Authenticator push notifications and describes it as a key security upgrade to traditional second-factor notifications. Users cannot opt out, and the behavior covers MFA, SSPR, and combined SSPR/MFA registration.
That matters because on a generic push prompt the attacker can no longer win with a single inattentive tap. The user must enter a number shown in the sign-in flow.
Two documented nuances stop this from being a complete answer on its own:
- Same-device sign-ins are still a Yes/No prompt. When the user signs in on the same device that runs Authenticator, to Microsoft mobile apps such as Teams or Outlook, Microsoft lets them reply Yes/No instead of typing the number. Microsoft's stated rationale is that there is no increased risk because the prompt only appears on the device that initiated the sign-in — which is exactly the case a remote attacker cannot reach. Sign-ins from Edge, Chrome, or Safari still require the number.
- Adjacent MFA integration paths do not all behave the same. The AD FS adapter only enforces number matching on patched Windows Server 2016, 2019, and 2022 builds; unpatched servers keep the Approve/Deny experience. The NPS extension does not support number matching at all — from version 1.2.2216.1 it prompts for a TOTP code instead, and only for users who have a TOTP method registered. Number matching is not enforced by the deprecated Azure MFA Server, and it is not supported on Apple Watch or Android wearables.
Validate those paths separately rather than assuming every push workflow has the same protection level as the current Entra plus Authenticator experience.
2. Enable sign-in context in Authenticator notifications
Microsoft documents this as a way to improve sign-in security: adding the application name and the geographic location of the sign-in to Authenticator push and passwordless notifications, and combining that additional context with number matching. MITRE's user-training mitigation points the same way — users are meant to review the source location of the login attempt that produced the prompt, which they can only do if the prompt shows one.
The trap is that this context is off until you turn it on. Both settings live in the Authentication methods policy under Microsoft Authenticator > Configure (displayAppInformationRequiredState and displayLocationInformationRequiredState in Microsoft Graph), and Microsoft's own table of Microsoft managed defaults lists Location in Microsoft Authenticator notifications and Application name in Microsoft Authenticator notifications as Disabled. Leaving either on Microsoft managed therefore leaves it off. Set the status explicitly to Enabled.
Two documented limits are worth knowing before you plan the rollout: only users already enabled for Authenticator in that policy see the extra context, and additional context is not supported for the NPS extension or AD FS.
A tenant that leaves push approvals too generic makes fatigue attacks easier. When the prompt shows an application or location the user does not recognize, rejection becomes much more likely.
This control is especially useful when the attacker has a real password and is trying to convert that password into an approved session.
3. Enable Report suspicious activity and wire it into response
This setting is one of the highest-value Entra controls for MFA fatigue.
Microsoft documents that when a user reports a suspicious MFA prompt:
- the user is marked High User Risk
- the event is visible in sign-in logs, audit logs, and risk detections
- tenants with a Microsoft Entra ID P2 licence can use risk-based Conditional Access on user risk = high to block the sign-in or force a password reset
- tenants with P1 still get the risk detection event, and remediate manually or through Microsoft Graph or PowerShell automation
Operationally, this means the user can do more than just hit Deny. They can create a defender-visible incident signal from the same prompt.
Two configuration details decide whether any of that happens. First, the setting is enabled from Authentication methods > Settings in the Microsoft Entra admin center, and Microsoft states plainly that the feature remains disabled if you choose Microsoft managed — the Microsoft managed default for Report suspicious activity is Disabled. Select Enabled, then scope it to all users or a specific group. Second, Report suspicious activity replaced the legacy Block/unblock users, Fraud alert, and Notifications features, which Microsoft removed on March 1, 2025; any runbook that still tells an analyst to check Fraud alert needs rewriting.
4. Move privileged users to phishing-resistant MFA
Microsoft's current guidance is clear: privileged administrative roles are frequent targets, and organizations should require phishing-resistant MFA for those roles.
For this article's topic, that point is central. A standard push approval can still be abused through fatigue or social engineering. A phishing-resistant authentication strength makes that path materially harder.
If you are hardening privileged access, pair this with Azure Identity Security: Why MFA Alone Is Not Enough and Azure Identity Protection: Blocking Leaked Credentials.
5. Reduce the number of passwords attackers can reuse in the first place
MFA fatigue usually starts after password compromise. If you cut down password theft and password spray success, you cut down the number of prompt-bombing opportunities.
That makes Entra ID Conditional Access Gaps: What Misconfigurations Leave Real Exposure and Azure Tenant Hardening: Fix Insecure Default Settings directly relevant. Stronger MFA approval flows matter, but they should sit on top of a tenant that is already reducing password-based initial access.
6. Review external and guest identities separately
Prompt-based MFA risk is not limited to employee accounts. External identities, B2B guest accounts, and partner access can also become noisy or under-reviewed approval paths if they are exempted from stronger controls or monitored less carefully. That is why Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant belongs in the same review.
7. Roll out stronger policies carefully
Microsoft's administrator guidance includes a real operational warning: before requiring phishing-resistant MFA broadly for administrators, confirm that those users are registered for the needed methods. Otherwise, you risk locking yourself out.
The same applies to Conditional Access changes more broadly:
- use report-only mode where available
- protect emergency access accounts intentionally
- review service accounts and workload identities separately
- validate that your help desk and identity recovery workflows still function
Good identity hardening is not only about stronger controls. It is also about avoiding self-inflicted outages.
Validation After Hardening
Do not close this issue because you turned on one setting in Entra. Validate the whole prompt-approval workflow.
- confirm the tenant actually presents number matching for Authenticator push scenarios you rely on
- confirm the prompt shows application name and geographic location where expected, and that both settings read Enabled rather than Microsoft managed
- confirm Report suspicious activity reads Enabled, not Microsoft managed, for the intended user population
- confirm suspicious prompt reports create the expected signals in sign-in logs, audit logs, and risk detections
- confirm your response workflow revokes sessions, investigates sign-ins, and resets credentials when a user reports a malicious prompt
- confirm privileged administrators are covered by stronger authentication requirements than ordinary users
The real test is not whether MFA is enabled in the tenant. The real test is whether a stolen password plus repeated push attempts still has a realistic path to approval.
How EtcSec Detects Related Exposure
MFA fatigue is an attack technique, not one single Entra misconfiguration. The closest catalogue findings are the control gaps that make prompt bombing more likely to succeed or harder to contain.
The most relevant related exposures are:
- missing risk-based sign-in response, which weakens containment after a user reports a suspicious prompt
- weak or incomplete protection for privileged identities, especially when administrative users are not moved to stronger authentication patterns
- conditional access designs that still lean too heavily on standard MFA prompts instead of stronger authentication requirements
That is why this topic sits next to Azure Identity Protection: Blocking Leaked Credentials, Azure Identity Security: Why MFA Alone Is Not Enough, and How to Audit Microsoft Entra ID Security (Azure AD): Practical Review Guide rather than existing as an isolated tenant setting.
Related Controls
If you are reviewing MFA fatigue, you should also review the controls that shape the same attack path: Azure Identity Security: Why MFA Alone Is Not Enough, Azure Identity Protection: Blocking Leaked Credentials, Entra ID Conditional Access Gaps: What Misconfigurations Leave Real Exposure, Azure Tenant Hardening: Fix Insecure Default Settings, How to Audit Microsoft Entra ID Security (Azure AD): Practical Review Guide, and Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant.
Primary References
- MITRE ATT&CK: Multi-Factor Authentication Request Generation (T1621)
- Microsoft Learn: Configure Microsoft Entra multifactor authentication
- Microsoft Learn: How number matching works in MFA push notifications for Authenticator
- Microsoft Learn: Use additional context in Authenticator notifications
- Microsoft Learn: Protecting authentication methods in Microsoft Entra ID (Microsoft managed settings)
- Microsoft Learn: Phishing-resistant MFA
- Microsoft Learn: Require phishing-resistant multifactor authentication for Microsoft Entra administrator roles
Explore the identity security pages that support this topic