TL;DR: MFA fatigue attacks exploit repeated push prompts, stolen credentials, and user annoyance to turn multi-factor authentication into a weak approval gate, with the source article outlining number matching, adaptive checks, phishing-resistant MFA, and monitoring controls. The real lesson is that human approval is not a reliable security boundary when attackers can force the decision loop.
At a glance
What this is: MFA fatigue attacks are a social engineering technique that overwhelms users with repeated authentication prompts until one is approved, turning MFA into an attack path rather than a barrier.
Why it matters: IAM teams need to treat MFA as a governed control, not a user habit, because the attack combines identity compromise, human pressure, and weak escalation handling across both human and non-human access flows.
👉 Read WorkOS' article on understanding MFA fatigue attacks and defences
Context
MFA fatigue attacks happen when an attacker repeatedly triggers authentication prompts until the user approves one out of frustration or confusion. The weakness is not the MFA mechanism itself, but the assumption that human approvers will reliably distinguish legitimate prompts from attack traffic.
For IAM programmes, this is a governance problem as much as an authentication problem. Controls built around user attention, off-hours judgment, and manual approval do not hold up well when attackers can script repeated login attempts and manipulate the response path.
Key questions
Q: How should security teams stop MFA fatigue attacks?
A: Security teams should combine stronger authentication with behavioural controls. Number matching, phishing-resistant factors, prompt rate limits, and alerting on repeated denials all reduce the attacker’s ability to wear down users. The key is to treat prompt flooding as an attack pattern, not a user support issue.
Q: Why do MFA fatigue attacks still work in mature IAM programmes?
A: They work because many programmes assume a user will reliably reject suspicious prompts. Once an attacker can trigger enough notifications, the control becomes dependent on attention, timing, and judgment. That makes it vulnerable even when the underlying MFA mechanism is correctly configured.
Q: What signals show that an MFA fatigue attack is underway?
A: Look for repeated MFA requests in a short period, a long series of denials, and then one unexpected approval. Off-hours approvals, unfamiliar device context, and login bursts from unusual geographies are also strong indicators that the approval flow is being abused.
Q: What should organisations do when repeated MFA prompts appear on an account?
A: Treat the event as potential compromise, not normal friction. Suspend the prompt loop, verify the user through a stronger channel, review recent password activity, and check for lateral movement from the account. Fast containment matters because the approved session may already be active.
Technical breakdown
Credential theft as the entry point for MFA fatigue
MFA fatigue usually begins after the attacker already has a valid username and password. That credential pair lets the attacker trigger repeated MFA challenges without needing to break the second factor directly. In other words, the attack is not a bypass of MFA delivery, but an abuse of the login workflow that follows password compromise. Once the prompt flood starts, the attacker is no longer trying to defeat cryptography, only human judgment under pressure.
Practical implication: treat password exposure as the precondition for MFA fatigue and monitor for repeated challenge bursts tied to valid accounts.
Why push notification approval becomes a weak trust signal
Push-based MFA is convenient, but simple approval buttons create a low-friction trust signal that attackers can exploit. If a user sees enough prompts, they may approve one to clear the noise, especially when distracted or outside normal working hours. Number matching and other phishing-resistant methods raise the cognitive cost for the attacker because the approver must verify a value tied to the login attempt rather than reacting to a generic notification.
Practical implication: move away from blind approve/deny prompts and require user verification that is bound to the specific login session.
Detection depends on prompt velocity and approval patterns
The best detection signals are behavioural, not just authentication success or failure. Security teams should look for repeated MFA requests in short windows, many denials before a single approval, approvals after a burst of failures, and prompts that arrive from unusual locations or at odd hours. Correlation across identity provider logs and SIEM telemetry helps separate routine user friction from active prompt bombing.
Practical implication: build alerts around MFA request rate, denial streaks, and approval timing so prompt flooding is visible before compromise spreads.
Threat narrative
Attacker objective: The attacker’s objective is to convert stolen credentials into authenticated access by wearing down the human approval boundary.
- Entry begins with credential theft through phishing, brute force, or credential stuffing, giving the attacker a legitimate username and password.
- Escalation happens when the attacker repeatedly triggers MFA prompts until the user approves one request out of annoyance, confusion, or fatigue.
- Impact follows when the approved session lets the attacker access the account, move laterally, or escalate privilege inside connected systems.
Breaches seen in the wild
- Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
- Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Human approval is not a dependable control boundary when attackers can turn login attempts into a harassment loop. MFA fatigue works because the defence assumes the user will act as a rational verifier at the moment of challenge. That assumption collapses when the attacker controls prompt volume, timing, and pressure. The implication is that approval-based MFA should be treated as a fragile trust signal, not as proof of strong identity assurance.
Push-based MFA creates an identity workflow that is easy to instrument, but also easy to weaponise. Repeated prompts are not merely noise; they are a measurable attack condition that should be governed as such. Organisations that rely on generic MFA success rates miss the deeper issue, which is that the control can be socially bypassed without technical compromise of the factor itself. Practitioners should interpret prompt flooding as an authentication abuse pattern, not a usability edge case.
Number matching and phishing-resistant factors matter because they change the attacker’s economics, not because they eliminate identity risk. The point is to remove blind approvals and force proof tied to the live session, which raises attacker effort and lowers success rates. That still does not solve stolen credential exposure upstream, so MFA fatigue should be read as part of a broader credential compromise chain. Teams should govern it as an identity assurance problem with both human and technical failure modes.
Credential theft plus approval fatigue is a hybrid failure mode that crosses human IAM and broader identity hygiene. The login starts as a human account issue, but the same pattern can later affect privileged accounts, delegated access, and service paths where users are asked to confirm actions under pressure. The field should stop treating these events as isolated phishing incidents. They are governance failures in how identity approval, alerting, and trust thresholds are designed.
MFA fatigue is a reminder that identity controls must be resilient to behavioural manipulation, not just protocol abuse. The deeper lesson for the IAM discipline is that a control can be technically sound and still fail operationally if it depends on exhausted people making the right call at the right moment. Practitioners should consider this a boundary condition for any approval-based control model.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- For a broader view of how identity failure patterns compound across machine access, see 52 NHI Breaches Analysis.
What this signals
Approval fatigue is a signal problem, not just an authentication problem. The operational question is whether identity teams can detect prompt abuse early enough to stop the attacker before the user gives in. That requires identity telemetry to be treated as a control surface, not an audit afterthought, especially where privileged access is involved.
Human IAM and NHI governance are converging around the same failure mode: trust that persists longer than it should. In one case, a person approves too many prompts; in the other, a credential or token outlives its intended trust window. The programme implication is that identity assurance now depends on shortening the period in which any trust decision can be exploited.
Zero Trust only works here when the approval path is continuously verified, not assumed to be safe after enrollment. As attackers increasingly chain credential theft with behavioural pressure, teams should connect authentication policy, anomaly detection, and privileged session controls into one response model. The difference between a nuisance event and a compromise is often the speed of containment.
For practitioners
- Replace blind approvals with number matching Require the user to confirm a code shown on the login screen so a prompt alone cannot be approved reflexively. This breaks the simplest form of fatigue-based abuse and makes the session-specific challenge visible to the user.
- Rate-limit repeated MFA prompts Set thresholds for prompt bursts, repeated failures, and rapid re-challenges. Accounts that cross the threshold should be temporarily blocked or stepped up to stronger verification before more prompts are sent.
- Correlate prompt storms with identity logs Join IdP events, SIEM telemetry, and user context so analysts can see failed logins, denials, and eventual approvals in one sequence. This is the fastest way to distinguish ordinary login friction from active fatigue abuse.
- Adopt phishing-resistant authentication for high-risk users Use passkeys, platform authenticators, or hardware security keys for privileged staff and exposed remote access paths. These factors remove the remote approval loop that MFA fatigue attacks depend on.
Key takeaways
- MFA fatigue attacks succeed by converting repeated prompts into a human error condition, not by breaking the MFA factor itself.
- The scale of the problem is visible in prompt bursts, failed approvals, and off-hours logins, which makes behavioural detection essential.
- Number matching, phishing-resistant MFA, and prompt rate limits reduce exposure by removing the attacker’s easiest approval path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | MFA assurance and authenticators are central to this attack pattern. | |
| NIST CSF 2.0 | PR.AC-7 | Access verification and authentication resilience map directly to MFA fatigue. |
| NIST Zero Trust (SP 800-207) | AC-7 | Continuous verification helps prevent trust in a single approval event. |
Treat login approval as one signal among many, not a stand-alone trust decision.
Key terms
- MFA Fatigue Attack: An MFA fatigue attack is a social engineering technique that overwhelms a user with repeated authentication prompts until one is approved. The control fails because the attacker targets attention and habit rather than the factor itself, making the human approval step part of the attack surface.
- Phishing-Resistant MFA: Phishing-resistant MFA uses authenticators that are bound to the session or device, such as passkeys, hardware security keys, or platform authenticators. These methods reduce remote approval abuse because the user must verify a live, context-specific challenge instead of reacting to a generic prompt.
- Prompt Storm: A prompt storm is a burst of repeated MFA requests sent to the same account in a short period. In practice, it is both a user experience issue and a detection signal, because excessive prompts often indicate that someone is trying to wear down the approver or automate credential abuse.
- Number Matching: Number matching is an MFA method that requires the user to enter or confirm a number shown on the login screen. It reduces blind approvals by linking the approval to the specific session, which makes random taps or reflexive acceptance far less effective.
Deepen your knowledge
MFA fatigue attacks and phishing-resistant authentication are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to harden approval-based login flows, it is worth exploring.
This post draws on content published by WorkOS: Understanding MFA fatigue attacks: how they work and how to defend against them. Read the original.
Published by the NHIMG editorial team on 2025-10-09.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org