Who is accountable when push MFA fatigue leads to unauthorised access?

Why This Matters for Security Teams

Push mfa fatigue is not just an authentication nuisance. It is a control failure that exposes gaps in governance, ownership, and escalation. When an attacker can repeatedly trigger prompts until a user approves one, the question becomes less about the button press and more about who accepted a weak control for the access being protected. NHI Management Group’s Ultimate Guide to NHIs shows why this matters across identity programs: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

That same pattern appears in human access decisions. If a team allows push MFA for privileged or high-impact systems without stronger compensating controls, accountability is shared across the control owner, the application owner, and the security leaders who approved the risk. OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev. 5 Security and Privacy Controls both reinforce the broader principle: authentication strength must match access sensitivity, and the organisation must be able to show who accepted the residual risk. In practice, many security teams discover MFA fatigue only after a privileged account has already been used for unauthorised access, rather than through intentional review of the control design.

How It Works in Practice

Accountability starts with control ownership, not incident blame. The identity team is usually responsible for configuring MFA policy, challenge frequency, number matching, number of retry attempts, and escalation rules. The application owner is responsible for deciding whether push MFA is appropriate for the data or actions the application protects. Security leadership owns the risk decision when push is used for elevated access, because that decision sets the organisation’s tolerance for social engineering and prompt bombing.

In mature programs, the decision is documented in an access standard and mapped to risk tiers. High-risk access often requires phishing-resistant authenticators, step-up checks, or conditional access rather than push alone. This is where policy discipline matters. If the control is weak, the organisation should be able to point to a named approver, a justified exception, and a review date. If those are missing, accountability is diffuse even if the compromise is technically initiated by the attacker.

• Use stronger authenticators for admin, finance, production, and identity-plane access.
• Log MFA prompts, rejects, and repeated challenges so fatigue patterns can be detected early.
• Require explicit approval for exceptions and time-bound risk acceptance.
• Review whether the same control is being reused across user, service, and agent access without revalidation.

This issue is especially relevant when push policies are applied broadly to accounts that also manage NHIs or automation tokens. NHI governance breaks down when human MFA assumptions are copied into machine-access workflows, which is why the Ultimate Guide to NHIs — Key Challenges and Risks stresses visibility, lifecycle control, and privilege reduction. These controls tend to break down when emergency access is frequent and approval trails are informal, because teams then normalise weak authentication for convenience.

Common Variations and Edge Cases

Tighter authentication often increases friction and help desk load, requiring organisations to balance user experience against the risk of unauthorised access. That tradeoff is real, but current guidance suggests it should be resolved by tiering access, not by weakening standards for everyone.

There is no universal standard for every environment, but several edge cases recur. Shared admin accounts create ambiguity because no single user can be held accountable for approving a push. Legacy applications may only support push MFA, forcing compensating controls such as network restrictions, session limits, or privileged access management. Third-party support access is another weak point, because an external technician may be outside the organisation’s normal enforcement and monitoring model.

For service accounts and AI agents, push MFA is usually the wrong control entirely. Those identities need workload identity, short-lived secrets, and policy-based authorisation instead of human approval workflows. The practical lesson is simple: if a control can be worn down by repeated prompts, it should not be the only gate protecting privileged access. When a compromise occurs, accountability often traces back to an exception that was approved long before the incident, not to the final prompt that happened to be clicked.

Related resources from NHI Mgmt Group

• Who is accountable when business associates access ePHI without strong MFA?
• Who is accountable when middleware bypass leads to unauthorised access?
• Who is accountable when an exposed DevOps secret leads to unauthorised access?
• Who is accountable when a control failure leads to fraud or unauthorised access?