Who is accountable when an MFA fatigue attack succeeds?

Why This Matters for Security Teams

An mfa fatigue attack is not just a user-awareness problem. It is a governance failure that exposes gaps in identity design, approval workflows, and escalation handling. When push prompts can be spammed until someone approves, the control is predictable enough for attackers to automate and repeat. NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now shows how identity abuse becomes operational damage once credentials or approvals are treated as durable trust signals.

Security teams often assume MFA is a hard stop, but fatigue attacks exploit the space between authentication and actual intent. That gap matters because the environment may still accept repeated prompts, weak number matching, or inconsistent escalation paths. External guidance from CISA cyber threat advisories consistently points to credential theft and social engineering as active intrusion paths, not edge cases. In practice, many organisations discover this failure only after an attacker has already persisted through a prompt loop and moved laterally.

How It Works in Practice

Accountability follows control ownership. The user may have clicked approve, but the underlying responsibility sits with the identity programme owner, the application owner, and the security team that allowed a fatigue-prone control to remain in place. The key operational question is whether the system was designed to resist repeated approval abuse, not whether the human on the other end made a perfect decision.

In mature environments, the response chain is straightforward:

• Identity teams own MFA policy, conditional access, and challenge design.
• Application owners own how the app requests step-up authentication and whether the workflow supports secure alternatives.
• Security teams own monitoring, alerting, and incident response for repeated prompt abuse.
• GRC or risk owners own whether the control design meets policy expectations for phishing-resistant authentication.

Current guidance suggests moving away from approvals that depend on reflexive user action toward stronger factors such as phishing-resistant MFA, device binding, and risk-based access decisions. That aligns with the broader NHI governance view in Ultimate Guide to NHIs — Key Challenges and Risks, where excessive trust in static credentials and repetitive workflows creates a durable attack surface. Where feasible, teams should pair MFA with alerting for prompt floods, enforce number matching or stronger factors, and revoke sessions quickly after suspicious behaviour. NIST’s CISA cyber threat advisories are a practical reference point for hardening identity workflows against active abuse.

This guidance tends to break down in legacy environments that still rely on push-only MFA for high-value access because those systems cannot separate legitimate access intent from attacker-driven prompt spam.

Common Variations and Edge Cases

Tighter authentication controls often increase user friction and support load, so organisations have to balance phishing resistance against operational usability. That tradeoff is real, but it does not remove accountability when the control is known to be vulnerable. Where best practice is evolving, many teams now treat repeated approval prompts as a signal to lock accounts, terminate sessions, or require step-up review rather than assume the user is simply distracted.

Edge cases matter. In helpdesk-driven resets, shared service access, or high-privilege admin workflows, the accountability chain broadens because multiple teams influence the control path. If the application cannot support stronger authentication, the risk still belongs to the owner of that application and the programme that accepted the exception. NHIMG’s 52 NHI Breaches Analysis is useful here because it shows how identity failures often compound when weak controls, delayed response, and excessive privilege occur together. For active threat context, Anthropic — first AI-orchestrated cyber espionage campaign report and MITRE ATLAS adversarial AI threat matrix both reinforce the same operational lesson: attackers exploit predictable human and system reactions at scale.

When executives ask who is accountable, the answer is rarely a single person. It is the owners who approved the control design, the teams that failed to harden it, and the organisation that tolerated a known-abusable authentication path.

Related resources from NHI Mgmt Group

• Who is accountable when account takeover succeeds despite verification controls?
• Who is accountable when fraud happens after authentication succeeds?
• Who is accountable when a supplier account is used in an attack?
• Who is accountable when phishing succeeds despite zero-trust controls?