Attackers succeed because controls can be technically enabled but still fail at the human decision point. In this report, users were tricked into approving repeated MFA prompts until one was accepted. That means the control did not break at policy design, but at user fatigue and trust. Identity defenses must assume social engineering will target the approval step, not just passwords or tokens.
Why MFA and conditional access still fail at the approval step
MFA and conditional access raise the cost of compromise, but they do not stop every attack path. When the attacker can repeatedly prompt a user, spoof urgency, or exploit attention drift, the control becomes a trust test rather than a cryptographic one. That is why repeated approval fatigue remains effective even when the policy stack looks strong on paper.
The important distinction is that the policy may be correctly designed and still be defeated in the final user interaction. In a real-world fatigue attack, the weakness is not token generation or access policy syntax, it is the human tendency to normalise repeated prompts and approve the one that finally feels routine. That is also why phishing-resistant authentication matters more than prompt volume alone, as described in NIST SP 800-63 Digital Identity Guidelines.
Attackers also benefit from the fact that many MFA implementations are still interactive and context-light. If the approval request does not expose enough detail about device, location, application, or session intent, the user is left making a risk decision without enough signal. Controls that depend on the user recognising an unusual prompt will always be weaker than controls that reduce the chance of a meaningless prompt reaching the user in the first place.
How attackers turn policy into user fatigue and trust abuse
The common success pattern is not a single clever bypass, but repeated pressure. Attackers may spray prompts, combine them with help-desk impersonation, or use a second channel to create urgency so the victim treats the prompt as a legitimate login event. The control is then working as designed technically, while the attacker attacks the decision point that the design still depends on.
This is why the issue is often framed as trust abuse. The attacker is not breaking MFA in the cryptographic sense, they are exploiting the assumption that a legitimate user will reliably distinguish the genuine request from the malicious one. NHIMG’s Uber Breach is a clear example of MFA fatigue being used as the opening move for broader access. The same pattern also appears in major account compromise cases where the first successful approval becomes the gateway to higher-value systems and secrets.
Conditional access can narrow the attack surface, but it cannot by itself remove social engineering from the loop. If the attacker already has a valid username, a stolen session context, or enough timing to trigger approval requests, the policy can still route the event to the very person under pressure. That is why approval-based MFA should be treated as one control layer, not the control that ends the threat model.
For broader identity compromise patterns and control failures, the Microsoft Midnight Blizzard breach shows how identity weaknesses can be chained into deeper compromise once an initial trust boundary is crossed.
What practitioners should verify before they trust MFA as a real barrier
Good practice is to verify whether the MFA method meaningfully resists unsolicited approval, not just whether it is enabled. Push approval with no number matching, weak device binding, or limited context is materially easier to fatigue than a phishing-resistant method that binds the user, the device, and the session challenge more tightly. The right question is whether the control still holds when the attacker has already captured attention.
What to verify:
- Whether the MFA flow exposes enough session context for the user to make a credible decision.
- Whether repeated prompts are rate-limited, detected, and escalated as suspicious activity.
- Whether help-desk and recovery workflows can be abused to reinforce the prompt with false legitimacy.
- Whether high-risk accounts, admins, and support users have stronger authentication than standard users.
What practitioners underestimate: a control can be fully deployed and still be operationally weak if the attacker only needs the user to say yes once. That is why stronger authentication and tighter session controls should be paired with monitoring for prompt abuse, impossible travel, token misuse, and unusual approval bursts. The attacker objective is often persistence after the first approval, not merely one login.
Practitioner takeaway: Treat MFA success as a trust-and-visibility problem, not just an authentication problem, and assume the attacker will aim for the weakest human decision in the chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Phishing-resistant authenticators — Phishing-Resistant Authentication | The question is about MFA being defeated through approval abuse, which this guidance addresses directly. |
| Recommendation — Prefer phishing-resistant authenticators that bind the user to the session and reduce prompt-based approval abuse. | ||
| CIS Controls v8 | 6 — Access Control Management | Repeated prompt abuse is an access-control failure that needs account, session, and privilege governance. |
| Recommendation — Harden access control workflows so high-risk approvals, recovery paths, and elevated accounts receive stricter enforcement. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Identity compromise often escalates after a successful approval into credential or token abuse. |
| Recommendation — Reduce the blast radius of a compromised identity by limiting token lifetime, reuse, and exposure. | ||
| MITRE ATT&CK | T1621 — Multi-Factor Authentication Request Generation | MFA fatigue attacks rely on generating repeated authentication prompts to coerce approval. |
| Recommendation — Detect repeated MFA request generation and correlate it with suspicious login attempts or new-session activity. | ||
Related resources from NHI Mgmt Group
- Why do cloud native attackers often succeed even when perimeter controls are in place?
- Why do identity-first programmes still fail even when SSO and MFA are in place?
- Why does cloud access governance still fail even when SSO and MFA are in place?
- Why does remote work increase identity risk even when MFA is in place?
