MFA Fatigue in Entra ID: Detection and Prevention

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 now explicitly recommends providing that context in Authenticator notifications.

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.

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
the riskEventType is userReportedSuspiciousActivity

That matters because it lets defenders move from guesswork to a specific, user-confirmed signal.

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.

1. Verify that Authenticator push flows use number matching

Microsoft states that number matching is enabled for current Authenticator push notifications and describes it as a key security improvement over the old Approve/Deny experience.

That matters because the attacker can no longer win with a single inattentive tap on a generic push prompt. The user must enter a number shown in the sign-in flow.

If your environment still depends on older or adjacent MFA integration paths, validate their behavior separately rather than assuming every push workflow has the same protection level as the current Entra + Authenticator experience.

Microsoft explicitly recommends showing the application name and geographic location in Authenticator notifications so users can make informed approval decisions.

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
organizations with the right licensing can use risk-based Conditional Access to block or force secure remediation
organizations without that automation still get a concrete signal they can investigate and contain

Operationally, this means the user can do more than just hit Deny. They can create a defender-visible incident signal from the same prompt.

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 Azure Conditional Access: MFA Bypass With Stolen Passwords 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
confirm Report suspicious activity is enabled 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.

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.

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, Azure Conditional Access: MFA Bypass With Stolen Passwords, 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.

MFA Fatigue: Detection and Prevention for Microsoft Entra ID