Warning signs include repeated MFA prompts in a short period, unexpected push notifications, requests appearing when the user is not logging in, and users reporting fatigue from multiple approvals. These patterns can indicate MFA bombing or credential compromise. Teams should train users to approve prompts only during a genuine login attempt and to report unusual requests immediately so defenders can investigate quickly.
What MFA abuse looks like in practice
MFA abuse usually shows up as a mismatch between the authentication event and the user’s intent. The clearest signals are repeated approvals in a short window, prompts arriving when the user is not signing in, and repeated denials followed by a sudden success. Those patterns matter because they often mean an attacker already has a password and is trying to coerce, fatigue, or trick the second factor.
Look for the context around the prompt, not just the prompt itself. Abuse is more likely when the device, location, time, or application is unfamiliar, when the user cannot connect the prompt to a login they started, or when several accounts receive similar prompts at once. Prompt volume by itself is not proof of compromise, but it is a strong indicator that the authentication flow is being manipulated.
Push-based approval fatigue is especially important to distinguish from normal friction. A few failed login attempts may be harmless, but a sustained sequence of prompts, especially after the user has already denied them, suggests an active attempt to wear down the user or exploit inattentive approval behaviour. That is materially different from an ordinary failed sign-in.
Why repeated prompts and unexpected approvals are a warning sign
Repeated MFA prompts can indicate that the attacker has already satisfied the first factor and is testing the human response at the second factor. In practice, that means the abuse path is often credential theft, session theft, or social engineering rather than a direct bypass of the MFA technology itself. The user becomes the control point the attacker is trying to overcome.
Unexpected approval requests are also a sign that the authentication boundary is being crossed out of band. If a user receives a prompt while not actively logging into the system, the organisation should treat it as suspicious until the source is explained. A real login should have a traceable initiating action, and a lack of that context is often what separates a normal event from an abuse attempt.
This is where attackers benefit from confusion. They rely on users assuming the request is routine, especially if the prompt looks familiar or arrives during a busy period. Once one approval is granted, the attacker may immediately move to mailbox access, VPN access, SaaS access, or other higher-value systems. For context on a real-world fatigue-style compromise, see Uber Breach.
How defenders separate nuisance from compromise
The most useful test is whether the prompt sequence is explainable by a legitimate login journey. If the user did not initiate the sign-in, if the same account receives multiple prompts in rapid succession, or if approvals occur after prior denials, treat the event as an investigation trigger. Correlate the MFA event with identity provider logs, device posture, source IP, geolocation, and recent password resets or phishing activity.
Abuse analysis should also consider whether the organisation is seeing a broader campaign rather than a single user issue. Multiple users receiving prompts for the same application, the same identity provider, or the same time window can indicate a coordinated credential attack. That changes the response from user coaching to containment, because the attacker may still be actively trying to enter through other accounts.
For practitioners, the important distinction is between isolated annoyance and an active access path. If there is evidence that the prompt sequence is part of an attempted sign-in without user intent, the event belongs in incident triage, not just helpdesk handling. Phishing-resistant authentication reduces this risk; see NIST SP 800-63 Digital Identity Guidelines and the authentication requirements in OWASP ASVS.
Risk and Threat Considerations
MFA abuse is dangerous because it turns a protective control into a pressure point. Once attackers have a password or other first factor, repeated prompts can be used to fatigue users, create alert noise, or exploit weak approval habits until one approval is obtained. That can lead to account takeover even when MFA is technically enabled.
Failure mechanism: The attacker initiates repeated sign-in attempts or approval requests until the user accepts one, or until an inattentive approval path is triggered. The control fails when the organisation relies on user vigilance alone and does not detect the abnormal prompt pattern quickly enough.
Impact: A successful approval can expose email, SaaS applications, internal tools, and downstream secrets or sessions. From there, an attacker may pivot to persistence, privilege escalation, or additional account compromise, so the prompt itself can be the first observable step in a wider intrusion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-63 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Guidance on authenticators and phishing-resistant MFA directly fits MFA abuse signs. |
| Recommendation — Adopt phishing-resistant authenticators and investigate prompt anomalies as sign-in abuse. | ||
| OWASP ASVS | V6 — Authentication | Authentication verification requirements apply to detecting abnormal MFA prompt behaviour. |
| Recommendation — Validate authentication flows for prompt abuse and require user-initiated sign-in context. | ||
| MITRE ATT&CK | T1621 — Multi-Factor Authentication Request Generation | Covers adversary use of repeated MFA requests to fatigue or coerce users. |
| Recommendation — Map repeated prompt patterns to T1621 and alert on MFA fatigue behaviour. | ||
Practitioner Guidance
What to verify: Confirm that every MFA prompt can be tied to a legitimate, user-initiated login attempt. If the user cannot explain the request, treat it as a security event and review the associated sign-in telemetry before assuming it is benign noise.
Decision rule: If the pattern includes repeated prompts, post-denial prompts, or requests outside a normal login session, escalate as suspected credential compromise or MFA fatigue attack. Do not wait for a confirmed approval to act, because the repeated prompt pattern is often the strongest early indicator.
Practitioner takeaway: The key judgement is whether the prompt sequence is consistent with a real login journey. If it is not, the organisation should treat the event as a live access attempt, not a user-support issue.
Related resources from NHI Mgmt Group
- How should teams reduce the risk of exposed AI credentials being abused?
- What are the signs that an organisation is falling behind on phishing resistant authentication?
- What are the signs that password-based authentication is failing in an organisation?
- What are the signs that API authentication is being abused during an account compromise?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
