Look for repeated prompts, unusual login timing, multiple failed attempts followed by one success, and support calls that reference unexpected authentication requests. Those signals often indicate an attacker is trying to exhaust or confuse the user rather than break the factor directly. Monitoring should tie those events to account risk, not just authentication volume.
How to recognise push-based MFA abuse
Push-based MFA abuse is usually visible as an attempt to wear the user down, not as a clean technical compromise. Repeated approval prompts, prompts appearing at odd hours, and a burst of failed sign-in attempts followed by one success all fit the same pattern: someone is trying to make the user approve out of fatigue, confusion, or a mistaken belief that the request is legitimate.
In practice, the strongest sign is repetition across time and across the same account. A single unexpected prompt can be a mistake or a misrouted login flow; repeated prompts, especially after the user has already denied them, suggest the account is being actively targeted.
What telemetry and user reports usually line up together
The signal is strongest when authentication logs and help desk data tell the same story. Support calls that mention unexpected authentication requests, “I am not trying to sign in,” or “I keep getting prompts I did not start” often align with the identity logs showing multiple attempts from unusual locations, unfamiliar devices, or a sequence of denials followed by one acceptance.
That combination matters because push abuse is often a social and operational event before it becomes an account takeover event. If the prompt stream is happening while the account is also seeing password resets, new device enrollment, or recovery attempts, the risk is no longer just noisy MFA traffic. It is a sign that the attacker may be building a path to eventual approval or fallback access.
How to separate abuse from normal sign-in noise
Normal users can trigger a stray push by reopening a session, changing devices, or hitting a token expiry. Abuse looks different because it tends to cluster: many prompts in a short period, repeated denials, sign-ins at times the user does not usually work, and access attempts that continue even after the user says no. That pattern is easier to see when teams review authentication volume together with account risk and user context, not as isolated login events.
One useful test is whether the prompt has a clear user action behind it. If the user cannot explain why the request occurred, and the system records a pattern of retries or failures around the same period, treat it as suspicious until proven otherwise.
Risk and Threat Considerations
Push MFA abuse matters because it targets the weakest part of the control, the human decision to approve. Once an attacker gets a single approval, the factor may be bypassed without ever defeating the authenticator itself.
Failure mechanism: The attacker repeatedly triggers push prompts until the user approves one, or the user confuses the request with a legitimate session. That approval can then be used to complete sign-in, establish persistence, or move toward broader account compromise.
Impact: Successful abuse can lead to account takeover, session theft, lateral movement, and help desk fraud if the attacker pairs MFA fatigue with recovery or reset requests. The operational impact is often larger than the authentication event itself because the compromised account may still appear “MFA protected” on paper.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Repeated push abuse is an authentication weakness that ASVS V6 addresses. |
| Recommendation — Require stronger, phishing-resistant authentication and rate-limit repeated approval prompts. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User sign-in abuse and prompt fatigue fall under organizational-user authentication controls. |
| IA-5 — Authenticator Management | Push abuse often succeeds when authenticators and recovery paths are weakly managed. | |
| Recommendation — Enforce MFA protections, lockout logic, and sign-in anomaly review for user accounts. Manage authenticators tightly and rotate or revoke credentials tied to suspicious push activity. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authenticators and authenticator assurance levels directly inform push-MFA hardening. |
| Recommendation — Adopt phishing-resistant authenticators and align assurance level to account risk. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The question centers on authentication abuse and account-risk response. |
| Recommendation — Review sign-in risk signals and strengthen authentication controls for targeted accounts. | ||
Practitioner Guidance
What to verify: Correlate prompt frequency, denial counts, login geography, device fingerprint, and help desk contacts for the same account before deciding the activity is benign. If the same user is also seeing reset or recovery requests, escalate immediately rather than waiting for a second confirmed login.
What to measure: Track denied prompts per account, time between prompt bursts, and the percentage of push events followed by successful sign-in from a new device or location. Those measures are more useful than raw MFA volume because they expose targeted abuse patterns.
Decision rule: If the account is high value, the prompts are repeated, and the user did not initiate the sign-in, treat it as an active attack path, not an authentication inconvenience. Consider step-up review, session invalidation, and stronger phishing-resistant sign-in for that account class.
Practitioner takeaway: Push MFA abuse is best handled as a correlated account-risk signal, not a standalone authentication alert, because the key question is whether the prompts are being used to drive a human approval failure.