Skip to main content
Identity Authority
Category: Multi-Factor Methods

MFA Fatigue

Also known as: MFA Bombing, MFA Fatigue Attack, Push Bombing
Simply put

MFA fatigue describes two related ideas: the frustration users feel from repeatedly responding to multi-factor authentication prompts, and an attack that exploits that frustration. In the attack, a criminal who already has a user's password floods them with repeated approval prompts, hoping the user eventually accepts one out of habit or annoyance. A single accidental approval can hand the attacker access to the account.

Formal definition

MFA fatigue refers, in one sense, to user frustration from frequently having to satisfy additional authentication challenges, and in its more security-relevant sense to an attack technique (also called MFA bombing or push bombing) that targets push-notification-based MFA. In the attack, an adversary who already possesses valid primary credentials (typically a username and password, obtained separately) repeatedly triggers authentication attempts, flooding the victim with push approval prompts, often at inconvenient times such as the middle of the night. The goal is to induce the user to approve a prompt out of irritation or habit, thereby satisfying the possession-factor challenge and completing authentication for the attacker. Note that this attack undermines the authentication step and presupposes prior compromise of the knowledge factor; it is specific to push-approval MFA flows and does not generally apply to challenge-response methods such as number matching or phishing-resistant FIDO2/WebAuthn authenticators. Mitigations depend on configuration and vendor, and remediation guidance is out of scope for this definition.

Why it matters

MFA fatigue is significant because it demonstrates that adding a second factor does not, by itself, guarantee a secure authentication step. The attack presupposes that the knowledge factor (the password) has already been compromised, which means it typically appears at a later stage of an intrusion rather than as an initial foothold. By exploiting human behavior rather than a cryptographic weakness, it turns a legitimate possession-factor challenge into an avenue of compromise, an attacker never needs to defeat the MFA mechanism itself, only to persuade the user to approve one prompt.

The attack is particularly relevant to organizations that rely on push-notification approval as their primary MFA flow. Because a single accidental or exasperated approval can complete authentication for the attacker, the margin for error rests entirely on the end user, often at inconvenient times such as the middle of the night when prompts are flooded randomly. This makes MFA fatigue a useful illustration of why the specific MFA modality in use matters: the technique does not generally apply to challenge-response methods such as number matching or to phishing-resistant FIDO2/WebAuthn authenticators, though whether a given deployment is exposed depends on configuration and vendor.

For security teams, MFA fatigue is a reminder to evaluate MFA not as a binary control but by the resilience of the factor and flow chosen. It also highlights the interplay between the authentication step and prior credential hygiene, since the attack only becomes possible once primary credentials have been obtained separately.

Who it's relevant to

IAM Engineers and Security Architects
Those designing authentication flows should weigh the exposure of push-approval MFA against alternatives such as number matching or phishing-resistant FIDO2/WebAuthn authenticators. Understanding that MFA fatigue targets the possession-factor challenge, and presupposes a compromised password, helps in selecting factors and flows appropriate to a deployment's risk tolerance.
System Administrators
Administrators operating MFA services need to understand that push-notification approval can be abused through repeated prompts, and that the resilience of the configured flow varies by vendor and settings. This informs decisions about default MFA modalities and how prompts are surfaced to users.
Security Operations and Incident Responders
Because MFA fatigue typically follows prior credential compromise, a flood of authentication prompts against a single account can signal an intrusion in progress. Responders benefit from recognizing this pattern as an indicator that primary credentials may already be exposed.
End Users and Security Awareness Teams
Since the attack relies on a user approving a prompt out of habit or annoyance, user awareness is directly relevant. Understanding that unexpected or repeated approval requests, especially at odd hours, may indicate an attack helps users avoid the accidental approval that completes authentication for an attacker.

Inside MFA Fatigue

Push notification bombing
The core attack technique in which an adversary who already possesses valid primary credentials (typically knowledge factor, such as a username and password) repeatedly triggers push-based approval prompts to the legitimate user's registered device, relying on the possession factor being approved out of annoyance or confusion.
Approve/deny push authenticators
The MFA mechanism most susceptible to this attack, where the possession factor is satisfied by a single-tap approval rather than a transcribed or matched value. This design choice, common in many mobile authenticator deployments, is what makes accidental or fatigued approval possible.
Compromised primary credential
A precondition for the attack. MFA fatigue targets the second step of authentication only; the attacker must first defeat identification and primary authentication, typically through phishing, credential stuffing, or reuse, before the fatigue technique becomes relevant.
Human factor exploitation
The attack exploits user behavior rather than a cryptographic or protocol weakness. It is a social-engineering vector layered on top of an otherwise functioning authentication factor, which distinguishes it from a technical bypass of the MFA mechanism itself.
Rate and volume of prompts
The pattern of repeated, often high-frequency or persistent low-frequency prompts. Depending on configuration, unlimited or poorly throttled prompt generation enables the attacker to sustain pressure on the user until an approval is granted.

Common questions

Answers to the questions practitioners most commonly ask about MFA Fatigue.

Is MFA fatigue a sign that MFA itself is broken or ineffective?
No. MFA fatigue targets a specific weakness in how certain MFA factors are used, not the underlying principle of multi-factor authentication. The attack typically exploits push-notification approval flows, where a user can approve a prompt with a single tap and no additional context. MFA remains substantially stronger than single-factor authentication; the issue is that push approval is a weak possession-factor implementation because it relies on the user correctly rejecting unexpected prompts. Phishing-resistant factors and prompts that require additional interaction generally resist this attack far better, so the appropriate response is to strengthen the factor rather than abandon MFA.
Does MFA fatigue mean the attacker has defeated the second factor?
Not in the technical sense. In a typical MFA fatigue scenario the attacker already possesses valid primary credentials, often knowledge-factor credentials such as a username and password, and is attempting to satisfy the possession factor by inducing the legitimate user to approve a push. The second factor is not cryptographically broken; instead the human step in the approval flow is manipulated. This is why MFA fatigue is best understood as a social-engineering attack layered on a credential compromise, not as a defeat of the possession factor's cryptography.
How can number matching help reduce MFA fatigue?
Number matching requires the user to read a value displayed at the point of sign-in and enter or select it within the authenticator app, rather than simply tapping approve. This typically raises the effort and context required to approve a prompt, so a user who is receiving unexpected prompts cannot inadvertently approve one, because they do not have the number an attacker sees. Effectiveness depends on the vendor implementation and on the user actually being prompted for the value; it reduces but does not eliminate the risk, since a user could still be socially engineered into relaying the number.
What role does prompt rate limiting play in mitigating MFA fatigue?
Rate limiting and throttling of authentication prompts can limit the volume of push notifications an attacker can generate against a single account, which reduces the pressure and confusion that drive a user to approve. In many deployments this is configured alongside lockout or temporary blocking after a threshold of denied or unanswered prompts. The specific thresholds and behaviors vary by vendor and configuration, so the control should be tuned to balance security against legitimate users who may generate repeated prompts during normal sign-in difficulties.
Can moving to phishing-resistant authentication eliminate MFA fatigue?
Adopting phishing-resistant methods such as FIDO2/WebAuthn authenticators, which rely on cryptographic assertions bound to the origin rather than user-approved push prompts, generally removes the approval step that MFA fatigue exploits. Because there is no repeated prompt for the user to approve out of context, the fatigue vector is largely closed for accounts using these factors. The qualification is that this only applies where such factors are enrolled and enforced; accounts that retain push-based fallback methods may remain exposed through those fallback paths, depending on policy configuration.
How can monitoring and detection surface MFA fatigue attacks in progress?
Authentication logs typically record repeated push challenges, high rates of denied prompts, and prompts originating from unusual locations or paired with anomalous primary sign-in activity. Correlating a burst of unanswered or rejected prompts with a recent credential event can indicate an in-progress attack. Many deployments feed these signals into risk-based or conditional access evaluation and into SIEM alerting so responders can intervene, disable the affected factor, or force a credential reset. Available telemetry and alerting granularity depend on the identity provider and logging configuration.

Common misconceptions

MFA fatigue means the attacker broke or bypassed the MFA factor itself.
The MFA mechanism typically functions as designed; the user voluntarily approves the prompt. The attack succeeds through user behavior, not through a cryptographic or protocol compromise of the possession factor.
Having MFA enabled protects an account against this attack.
MFA fatigue specifically targets accounts that already have push-based MFA. Enabling MFA is not sufficient by itself; the resistance depends heavily on the type of factor and the prompt design. Number-matching, verified push, or phishing-resistant methods generally reduce exposure, though effectiveness varies by deployment.
MFA fatigue is only an authentication problem and unrelated to credential hygiene.
The attack presupposes that the attacker already holds valid primary credentials. In most cases it is enabled by an upstream failure such as phishing or password reuse, so credential hygiene and primary authentication strength remain relevant to preventing it.

Best practices

Where supported, replace simple approve/deny push with number-matching or code-matching prompts so that a single tap cannot satisfy the possession factor.
Consider migrating high-risk or privileged accounts to phishing-resistant authentication such as FIDO2/WebAuthn credentials or passkeys, which are generally not susceptible to prompt-bombing in the same way as push approval.
Configure prompt throttling, rate limiting, and lockout on excessive authentication attempts, so an attacker cannot generate unlimited prompts; exact controls depend on the vendor and deployment.
Add contextual and risk-based signals (such as location, device, or velocity) to trigger step-up or block prompts that originate from anomalous conditions, depending on the capabilities of your identity provider.
Because the attack depends on an already-compromised primary credential, strengthen upstream defenses through anti-phishing measures, credential-reuse detection, and monitoring for credential-stuffing patterns.
Educate users to deny and report unexpected prompts, and provide a low-friction reporting channel so that a burst of unrequested approvals is treated as a potential compromise signal rather than a nuisance.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide