MFA fatigue attacks expose the limits of push-based MFA

At a glance

What this is: This is an independent analysis of MFA fatigue attacks and why repeated push notifications can turn MFA into an attack path.

Why it matters: It matters because IAM teams need controls that reduce prompt abuse, protect sensitive applications, and stop authentication from depending on user fatigue rather than policy.

By the numbers:

• 80% of successful business account compromise attacks occurred in environments already set up with MFA.

👉 Read Axiad's blog post on MFA fatigue attacks and identity controls

Context

MFA fatigue attacks are a form of push-notification abuse in which an attacker repeatedly triggers authentication prompts until a user approves one out of annoyance or confusion. In this case, the core identity governance problem is not whether MFA exists, but whether the organisation can still trust a user-driven approval step under adversarial pressure.

The article argues that many environments still rely too heavily on prompt-based approval and user vigilance. That creates a gap across human IAM and access governance, because the control is only as strong as the user's ability to recognise and reject malicious prompts in real time.

Key questions

Q: What breaks when push-based MFA is exposed to repeated notification attacks?

A: The control breaks when approval becomes automatic instead of deliberate. Repeated prompts can condition users to accept one just to stop the noise, which means the second factor no longer proves genuine intent. In that state, the attacker is no longer defeating MFA cryptographically. They are exploiting the approval workflow itself.

Q: Why do organisations still get compromised even after deploying MFA?

A: Because MFA is not a single control, it is a control design. If the factor relies on push approval, secret sharing, or user attention under pressure, an attacker can still manipulate the process after stealing credentials. Organisations remain exposed when MFA is treated as a checkbox instead of a trust model with risk-based enforcement.

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. Those are signs that the organisation has made approval too easy to normalise. A strong programme should make abnormal prompt patterns visible, uncommon, and actionable before an attacker can turn them into access.

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.

Technical breakdown

How MFA fatigue turns push prompts into an attack path

MFA fatigue works by overwhelming a user with repeated approval requests until one is accepted. The attacker usually starts with stolen credentials, then repeatedly authenticates so the legitimate user receives a stream of notifications. The weakness is procedural and behavioural: the second factor is no longer a deliberate verification step, but a nuisance event the user is conditioned to clear. In practice, this turns push MFA into a social engineering relay, where attacker persistence replaces cryptographic compromise. Practical implication: limit repeated prompts and make approval events unusual enough to stand out.

Practical implication: limit repeated prompts and make approval events unusual enough to stand out.

Why push MFA is weaker than phishing-resistant authenticators

Push approval, SMS, and similar secret-based factors are vulnerable because they depend on user recognition and response. Phishing-resistant authenticators use public key cryptography so the credential is bound to the device and the session, not to a reusable secret or a simple approve-or-deny action. That matters because the attacker can exploit behavioural friction in push MFA, but cannot easily replay or coerce a cryptographic challenge in the same way. The article's direction is clear: if MFA can be socially engineered, it is not strong enough for high-risk access paths. Practical implication: move high-value users and sensitive apps to phishing-resistant authentication.

Practical implication: move high-value users and sensitive apps to phishing-resistant authentication.

Why sensitive applications need stronger step-up controls

The article notes that MFA should not stop at login if the target application contains sensitive data. That is an important control-design point: initial authentication only proves that one session began correctly, not that every downstream action is equally safe. Access to a privileged or sensitive application should trigger additional checks based on risk, device state, or user profile changes. Otherwise, one successful push approval can become broad access across the session. This is where access governance, conditional checks, and application-specific policies need to work together. Practical implication: apply step-up controls at the application boundary, not only at sign-in.

Practical implication: apply step-up controls at the application boundary, not only at sign-in.

Threat narrative

Attacker objective: The attacker wants to convert stolen credentials into authorised access by coercing the user into approving a malicious MFA prompt.

1. Entry begins when the attacker obtains valid user credentials through phishing or another credential theft method.
2. Escalation occurs when repeated login attempts generate a flood of MFA push notifications that wear down the user’s resistance.
3. Impact follows when the user accepts one prompt and the attacker gains access to the account or device.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Prompt abuse creates a standing approval channel that attackers can exploit repeatedly. This is a governance issue because the approval mechanism remains live even after suspicious behaviour begins. The organisation is effectively leaving a decision path open until the user makes a mistake. That pattern should be recognised as an identity attack surface in its own right, especially where the same factor is used for every login.

Phishing-resistant authentication is the practical dividing line between tolerable and brittle MFA. The article’s recommendations point toward public key based authenticators and away from secret-sharing mechanisms that can be overloaded or socially engineered. That aligns with the broader shift in identity security: the more sensitive the access path, the less acceptable it is to rely on user-recognisable prompts. Practitioners should treat the authentication method itself as a control decision, not a convenience choice.

High-risk applications need step-up policy at the point of use, not only at login. A successful initial sign-in does not make every subsequent action equally safe, particularly when attackers are trying to ride an approved session into sensitive systems. That means access governance has to follow the session, the device state, and the application being reached. The practitioner implication is that sensitive apps should have their own trust threshold, separate from baseline sign-in.

Push fatigue exposes a broader assumption failure in modern IAM programmes. MFA was designed for a world where a second factor signalled genuine user intent. That assumption fails when an attacker can manufacture enough notification noise to turn intent into reflex. The implication is that programmes relying on user-mediated approvals must rethink where assurance actually comes from.

From our research:

• 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.
• For a broader view of how identity failures show up in real incidents, see 52 NHI Breaches Analysis and use it to pressure-test your own approval and recovery assumptions.

What this signals

Prompt fatigue is becoming a control-design problem, not just a phishing problem. Teams that still depend on repeated user approval should assume that attacker noise will eventually win. Where possible, move privileged access toward phishing-resistant methods and pair them with application-specific step-up checks so one compromised sign-in does not become broad session trust.

A better programme question is whether your MFA workflow still provides genuine assurance under sustained attack pressure. If the answer depends on user vigilance alone, the identity model is too brittle for high-value access.

For teams assessing broader identity hygiene, the relevant benchmark is not whether MFA exists but whether it can be coerced. That is why access governance, prompt suppression, and sensitive-app policies need to be measured together.

For practitioners

• 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.
• Train users to recognise MFA bombing patterns Teach employees to reject unexpected prompt bursts, report them immediately, and understand that repeated notifications can indicate an active compromise attempt rather than a system glitch.

Key takeaways

• MFA fatigue attacks succeed by turning a legitimate approval workflow into an attacker-controlled nuisance channel.
• The breach signal is not the existence of MFA but the brittleness of push-based approval under repeated prompting and social engineering pressure.
• Security teams should shift high-risk access to phishing-resistant authenticators and add step-up control at the application boundary.

Key terms

• MFA fatigue attack: An MFA fatigue attack is a social engineering technique that floods a user with repeated authentication prompts until one is approved. The attacker usually starts with stolen credentials and then tries to convert annoyance or confusion into access. The weakness is the approval workflow, not the cryptography alone.
• Phishing-resistant authenticator: A phishing-resistant authenticator is a login factor that binds authentication to a cryptographic challenge rather than a reusable secret or a simple yes-no prompt. It reduces the chance that an attacker can coerce, replay, or trick a user into approving access. This is especially important for privileged accounts and sensitive applications.
• Step-up authentication: Step-up authentication is a policy that requires additional verification when a user reaches a higher-risk action, app, or session state. It extends trust decisions beyond initial login and helps limit damage if the first factor is compromised. In mature IAM programmes, it is tied to context, sensitivity, and user risk.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or IAM programme maturity, it is worth exploring.

This post draws on content published by Axiad: The Growing Problem with MFA Fatigue Attacks (And What You Can Do About It). Read the original.