MFA Fatigue Attacks: Detection and Response
MFA fatigue attack detection correlates repeated prompts, password attempts, user denials, approval context, session creation, and downstream account use.
MFA fatigue abuses challenge generation and human context
MFA fatigue attack detection begins before approval. An attacker who has a password repeatedly starts authentication or recovery flows, causing the legitimate identity system to send push notifications, calls, or codes. The user may approve accidentally, from frustration, or after social engineering.
MITRE ATT&CK MFA request generation describes repeated challenges and recommends correlating unusual sources, prompt frequency, denials, timeouts, and approvals. The attack is not a cryptographic break; it exploits weak transaction binding and user uncertainty.
Scope the password event, challenge chain, registered factor, approval, token issuance, application session, and downstream actions separately. A successful MFA result does not prove the sign-in originated on the user’s device.
Preserve the challenge chain and originating sign-in
Capture user, authentication request and challenge IDs, application, source IP and device, password result, factor type, prompt creation, delivery, response, number-matching context, user-reported action, token issuance, conditional-access result, and resulting session.
This is authored and sanitized identity telemetry:
{"user":"[email protected]","request_id":"auth-71c...","app":"VPN",
"source_ip":"198.51.100.44","factor":"push","prompt_count_10m":12,
"responses":["deny","timeout","timeout","approve"],"number_matching":false,
"session_id":"s-8af...","user_initiated":false}
Do not collapse multiple challenges into one “MFA succeeded” record. Order and timing distinguish a normal retry from sustained pressure.
Detect prompt bursts and suspicious approval context
Alert on challenge bursts for one user, repeated denials or timeouts followed by approval, prompts without a recent user-initiated flow, password attempts from a new network, mismatched device and login location, multiple users targeted from one source, and approval followed by a new session or recovery change.
Join help-desk calls, factor re-registration, password reset, SSPR, federation, VPN, SaaS, and risk signals. Attackers may call the user while generating prompts, so an apparent support interaction can be part of the intrusion.
Travel, broken applications, retry loops, and network transitions generate benign repeats. Strong findings combine prompt behavior with anomalous origin, user denial or report, token creation, and downstream use.
Stop the sign-in chain and restore the user through a trusted route
Contact the user through a verified channel, block or challenge the initiating sign-in, revoke sessions and refresh tokens, reset the password when compromise is likely, and remove unexpected factors, recovery methods, app grants, or device registrations. Temporarily disable the account when active abuse outweighs availability impact.
Review actions performed through every resulting session. A denied prompt can still indicate a known password and should trigger credential investigation. Apply identity token and session detection rather than assuming password reset ends access.
Preserve the user report without blaming the user. Prompt design, support procedures, and factor choice shape the outcome; recovery should improve the system as well as the account.
Replace unbound approval with phishing-resistant authentication
CISA phishing-resistant MFA guidance recommends FIDO/WebAuthn or PKI-based methods for high-value access. These bind authentication to the legitimate relying party and remove unsolicited one-tap approval.
Where migration is incomplete, enable number matching, display application and location context, rate-limit prompts, suppress challenge storms, require managed devices, and let users report suspicious prompts directly. CISA number matching guidance treats number matching as an interim mitigation, not equivalent to phishing resistance.
Roll out by risk tier with tested recovery paths. A weak help-desk fallback can reintroduce the same phishable boundary that stronger MFA removed.
Test whether one unsolicited prompt becomes an incident
Next step: use an authorized test identity to generate a denied prompt from a controlled new network. Confirm challenge, denial, source, factor, and user report correlate without exposing the password. Do not bombard a real employee or test production alert thresholds without approval.
Verify that responders can revoke any resulting session and move the user to a trusted factor. Compare the exercise with OAuth device code phishing, where approval and token delivery are also separated. The durable outcome is transaction-bound authentication plus evidence that explains who initiated, who approved, and who used the session.
Frequently asked questions
Does an approved MFA prompt prove the user initiated the sign-in?
No. Approval proves interaction with the registered factor. Correlate the originating sign-in, device, network, application, number-matching context, user report, and resulting session.
Does number matching eliminate MFA fatigue attacks?
It substantially reduces blind one-tap approval but remains weaker than phishing-resistant MFA. Users can still be socially engineered into entering an attacker-supplied number.
