Notifications
Clear all
Topic starter
12/06/2026 10:13 pm
TL;DR: MFA fatigue attacks exploit repeated push prompts, and Expel found that 80% of successful business account compromise attacks already occurred in environments with MFA in place. The failure is not MFA itself but the assumption that users can reliably distinguish legitimate prompts from attacker-driven noise.
NHIMG editorial — based on content published by Axiad: The Growing Problem with MFA Fatigue Attacks (And What You Can Do About It)
Questions worth separating out
Q: What breaks when push-based MFA is exposed to repeated notification attacks?
A: The control breaks when approval becomes automatic instead of deliberate.
Q: Why do organisations still get compromised even after deploying MFA?
A: Because MFA is not a single control, it is a control design.
Q: How can security teams know whether their MFA programme is too easy to fatigue?
A: Look for repeated prompt acceptance, high retry volumes, and users who report notification storms as routine.
Practitioner guidance
- Reduce push notification volume and rate-limit retries Set hard limits around repeated MFA requests, add lockout logic for abnormal prompt bursts, and make repeated approvals visible to security operations so they are not treated as background noise.
- Require phishing-resistant authenticators for privileged access Prioritise public key based authenticators for administrators, finance users, and other high-value accounts so approval depends on cryptographic proof rather than a fatigue-prone push prompt.
- Apply step-up controls to sensitive applications Treat access to critical applications as a separate trust event and add contextual checks when a user reaches systems holding sensitive data, especially after a successful primary login.
What's in the full article
Axiad's full blog post covers the operational detail this post intentionally leaves for the source:
- Practical examples of how MFA fatigue unfolds across real login flows and notification patterns
- Specific mitigation ideas for tightening push controls, user prompts, and authentication method selection
- The article's recommended balance between user training and technical controls for reducing prompt abuse
👉 Read Axiad's blog post on MFA fatigue attacks and identity controls →
MFA fatigue attacks: are your push prompts helping attackers?
Explore further
13/06/2026 12:50 am
MFA fatigue is an authentication governance failure, not a user problem. The article shows that the weakest point is the human approval loop, not the presence of MFA itself. When attackers can train users to normalise repeated prompts, the organisation has built a control that depends on fatigue resistance rather than identity assurance. The practitioner implication is that prompt-based MFA should be treated as a limited control surface, not a final trust decision.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which leaves identity teams blind to much of the machine and workflow surface according to Ultimate Guide to NHIs.
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 expose the limits of push-based MFA
