Notifications
Clear all
Topic starter
02/08/2026 11:28 am
TL;DR: MFA fatigue attacks work by flooding users with repeated push prompts until one is approved, turning valid passwords into account access and often leading to rapid follow-on persistence actions, according to Prophet. The real failure is not authentication strength alone, but the human approval loop that permissive MFA designs still depend on.
NHIMG editorial — based on content published by Prophet: How MFA Fatigue Attack Works and How to Fight Back
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams reduce the risk of MFA fatigue attacks?
A: Security teams should remove approval-based MFA from high-risk access paths, replace it with cryptographic authentication, and reduce the privileges attached to any successful session.
Q: Why do push-based MFA prompts still get approved during attacks?
A: Because repeated prompts create annoyance, confusion, and habitual clicking, especially when the user thinks the requests are legitimate IT activity.
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.
Practitioner guidance
- Adopt phishing-resistant MFA for privileged access Move high-value accounts to FIDO2 security keys or passkeys so the user must complete a bound authentication step rather than approve a blind push prompt.
- Enable number matching across all push MFA flows Require the user to enter a displayed number from the login screen, and verify that legacy tenants have not silently kept permissive approve or deny prompts.
- Rate-limit repeated MFA challenges Cap prompt frequency within a short window and suspend or lock the account after repeated failures so a prompt storm cannot continue indefinitely.
What's in the full article
Prophet's full post covers the operational detail this analysis intentionally leaves for the source:
- A step-by-step explanation of the attack flow from stolen password to successful prompt approval.
- Detection heuristics for prompt bursts, geo-impossible travel, and suspicious re-enrolment activity.
- Prevention guidance on number matching, phishing-resistant MFA, and push rate limiting.
- Practical SOC triage considerations for separating user error from active takeover attempts.
👉 Read Prophet's analysis of MFA fatigue attacks and defensive controls →
MFA fatigue attacks: are your push approvals actually safe?
Explore further
02/08/2026 12:44 pm
Human approval loops are the real control surface in MFA fatigue attacks. The second factor is not what fails first. What fails is the assumption that an alerting user will reliably distinguish a legitimate login from a malicious prompt storm under pressure. That makes permissive push MFA a governance problem as much as an authentication problem, because the control depends on attention, not just possession.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and a further 47% having only partial visibility, 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.
A question worth separating out:
Q: Who is accountable when an MFA fatigue attack succeeds?
A: Accountability sits with the identity programme owner, the application owner, and the security team that allowed the control to remain vulnerable to prompt abuse. The answer is not simply user error. If the environment still depends on fatigue-prone approval loops, governance has to absorb part of the failure.
👉 Read our full editorial: MFA fatigue attacks exploit human approval loops, not crypto
