How do you detect MFA fatigue attacks?

Detect MFA fatigue by counting denied and unanswered strong-authentication results per user over a short window and then looking for a success that follows. In Entra SigninLogs, result type 500121 captures failed strong authentication, and in Okta the push deny, push send and MFA success event types give the same shape. Add user-reported fraud events as a high-confidence tripwire and check for newly registered MFA methods after any success. Prevent the attack by enabling number matching and moving privileged users to phishing-resistant factors.

Detecting MFA Fatigue and Push Bombing

MFA fatigue turns a stolen password into access by flooding the user with push prompts until they approve one, often reinforced by a phone call or message posing as IT. The attack leaves a very regular footprint: many failed or denied strong-authentication results for one account in a short window, followed by a single success. That shape is easy to query in both Entra and Okta logs.

Signals at a Glance

Signal	Where	ATT&CK
Several denied or unanswered MFA prompts for one user in an hour	SigninLogs, Okta System Log	T1621
Successful sign-in shortly after the prompt burst, often from a new IP	SigninLogs, Okta System Log	T1078.004
User-reported suspicious activity or fraud alert	AuditLogs, Okta events	T1621
New MFA method registered right after the successful sign-in	AuditLogs	T1556.006
Prompts arriving outside the user’s normal working hours	SigninLogs	T1621

Entra ID: Prompt Bursts

In SigninLogs, result type 500121 means authentication failed during the strong authentication request, which covers denied and timed-out prompts. Count them per user, then check for a success inside the same window:

// Microsoft Sentinel (KQL) - MFA prompt burst followed by a success
let window = 1h;
let failures = SigninLogs
    | where TimeGenerated > ago(1d)
    | where ResultType in ("500121", "50074", "50076")
    | summarize Failures = count(), FirstFail = min(TimeGenerated), LastFail = max(TimeGenerated),
                FailIPs = make_set(IPAddress, 5)
              by UserPrincipalName, bin(TimeGenerated, window);
failures
| where Failures >= 5
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(1d) and ResultType == 0
    | project SuccessTime = TimeGenerated, UserPrincipalName, SuccessIP = IPAddress, AppDisplayName
  ) on UserPrincipalName
| where SuccessTime between (LastFail .. LastFail + 30m)
| project UserPrincipalName, Failures, FirstFail, SuccessTime, FailIPs, SuccessIP, AppDisplayName
// tune/validate: 50074 and 50076 also appear in normal flows; start with 500121 only if noisy

Require number matching and additional context in Microsoft Authenticator so a blind tap cannot approve a prompt.
Alert on the user-reported fraud operation in AuditLogs immediately; it is rare and high confidence.
Follow every suspected case with a check of newly registered authentication methods for that account.

Okta: Push Denials and Verifies

Okta System Log records each push challenge and its outcome. The same burst-then-accept pattern appears as repeated denied or timed-out pushes followed by a successful verify:

# Splunk SPL - Okta push denial burst then success (validate field names for your add-on)
index=okta sourcetype="OktaIM2:log"
  (eventType="user.mfa.okta_verify.deny_push" OR eventType="system.push.send_factor_verify_push"
   OR eventType="user.authentication.auth_via_mfa")
| eval outcome=coalesce('outcome.result', "UNKNOWN")
| bin _time span=1h
| stats count(eval(eventType="user.mfa.okta_verify.deny_push")) AS denies
        count(eval(eventType="system.push.send_factor_verify_push")) AS pushes
        count(eval(eventType="user.authentication.auth_via_mfa" AND outcome="SUCCESS")) AS successes
        values(client.ipAddress) AS ips
        by actor.alternateId _time
| where (denies >= 3 OR pushes >= 8) AND successes >= 1
# tune/validate: thresholds vary by tenant; confirm event types against your System Log

Move high-risk users to phishing-resistant factors (FIDO2, passkeys); push approval cannot be fatigued out of a user who has no push.
Rate-limit push prompts per user where the platform allows, and treat any limit breach as an alert.

Vetted sources

Use Microsoft Entra guidance on MFA fatigue and number matching, Okta security documentation on push abuse, Splunk ESCU analytics for excessive MFA failures, and SigmaHQ identity rules. Baseline your own environment: mobile users with poor connectivity generate legitimate prompt timeouts.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Entra ID: Prompt Bursts

Okta: Push Denials and Verifies

Build Detections That Fire

Identity & Cloud Attack Detection

Detection Hub

Okta Attack Detection

Token Theft and AiTM Detection