In the last two managed detection and response (MDR) evaluations I've run, I asked each vendor to show me what its security operations center (SOC) analysts saw in the hour before the last multi-factor authentication (MFA) fatigue victim tapped approve. Most vendors answered with their push-flood threshold: five denials in ten minutes, alert fires, analyst picks it up.
One walked me through an infostealer detection from days earlier that their team had tied to the same account before the first push ever went out. That vendor made the shortlist.
The difference matters because the push flood is often a late, highly visible stage, not the first detectable one. By the time an Okta tenant starts emitting deny events, the attacker often already has a viable authentication path, commonly a stolen password but sometimes a reset, recovery-flow, or support-channel compromise.
A push-only analytic can miss the earlier evidence of credential compromise and account probing.
In brief:
- MFA fatigue attacks often progress through credential theft and validation before the push flood, and each stage leaves different telemetry. Many programs I review instrument the push-flood stage heavily and correlate the earlier signals less consistently.
- Okta teams should test whether denied and unanswered prompts follow different telemetry paths in their tenant; otherwise denial-based detections may miss prompts that simply expire.
- Number matching can shift attackers toward vishing rather than blind flooding. CrowdStrike reported that vishing operations increased 442% from the first half to the second half of 2024.
- A password reset may leave active sessions intact, so explicit session and token revocation is still required.
MFA fatigue usually follows a longer attack chain
The textbook definition is simple: an attacker holding valid credentials triggers repeated MFA push notifications until a worn-down or confused user approves one. MITRE ATT&CK's MFA request generation technique maps that request-generation and related credential-access behavior.
For detection engineering, though, that definition captures only the final minutes of the attack, which makes it a weak anchor for a detection program.
For operations, I use a four-stage model as a common investigation path, not the universal one: credential exposure, account probing, MFA-request generation, and social engineering.
Phishing and infostealers acquire credentials, which may be sold on dark web markets. Attackers then validate them through spray or stuffing before the push flood, and follow up with social engineering when the flood alone doesn't land.
Depending on the identity provider and tooling, each stage can produce telemetry a SOC can query, and rules that watch only the flood miss the earlier signal.
The password was stolen days before the first push
Credentials may be stolen from unmanaged endpoints, personal devices, browser stores, phishing kits, or infostealer infections. From there, an attacker often combines repeated approval requests with impersonation of trusted support staff.
In those cases, credential theft preceded the flood and happened beyond the visibility of the corporate SOC, so the devices the SOC can see are the detection opportunity.
The 2025 Verizon DBIR found that 46% of compromised systems with corporate logins in infostealer logs were non-managed devices hosting both personal and business credentials. So an infostealer hit on a machine with corporate logins should trigger a high-priority identity investigation, with severity set by the accounts, token material, and browser data exposed.
The validation stage is observable too. Password spraying often shows up as a single source IP, ASN, or device fingerprint generating a few invalid-password attempts across many accounts. Credential stuffing looks different, with repeated attempts against a smaller set of accounts from more distributed infrastructure. Tune either hunt for service accounts, NAT gateways, VPN egress, and legacy protocols.
If your correlation stops after the endpoint detection and response (EDR) alert is closed and the malware is removed, the attacker's next appearance in your telemetry may be the flood.
Denial-based rules can have a timeout blind spot
Try this. In Okta, test three paths separately: a prompt sent, a prompt explicitly denied, and a prompt left unanswered until the transaction ends. Event names and outcome fields can vary between Classic Engine and Okta Identity Engine, so don't assume a denial-based rule also covers abandoned prompts.
A stream of sends with no matching denials may otherwise let a denial-based rule stay silent through the whole flood. A useful alternative is counting push sends and checking whether those events carry origin information that can identify anomalous push locations.
Treat Entra ID as a separate implementation, and test the underlying outcomes before adapting a rule across identity providers (IdPs). Check whether sign-in records in your tenant distinguish declined and unanswered prompts well enough for a detection to separate those paths.
For Okta, test whether the equivalent detection must use unanswered sends or abandonment outcomes for each tenant and identity-engine path. Same technique, different implementations, and a coverage review should test both paths separately.
Threshold numbers are arbitrary; the sequence is what matters
Repeated prompts can come from a flaky phone or a dead spot in coverage, while access-policy loops can generate phantom prompts. Treat the event counts and time windows used in MFA-bombing rules as tuning choices meant to balance those false positives.
Sequence and context do the separating. I prioritize denials followed by a successful authentication in the same window as a high-confidence pattern. Other useful approaches compare the origin of the push with the origin of the completed authentication, or compare activity against a historical baseline of known IPs and locations.
Grouping counts by session keeps the real user's coincidental login from skewing the tally. In every vendor demo I've sat through, the threshold rule is on the slide; the sequence rule is the one I ask to see run against live data.
Number matching shifts the attack toward vishing
Number matching genuinely raises the cost of blind flooding, but it doesn't inherently end the attack. Test its coverage across sign-in flows, including the same-device Microsoft Authenticator flow where users can approve with a Yes/No prompt rather than enter the number.
When choosing factors, prefer phishing-resistant methods like FIDO2/WebAuthn security keys and passkeys over push approval. In Okta environments, assess FastPass and FIDO2/WebAuthn coverage; in Microsoft Entra environments, verify how Microsoft Authenticator number matching behaves across each flow.
Vishing can defeat number matching by having the caller tell the victim which number to enter. CrowdStrike found that vishing operations grew 442% from the first half to the second half of 2024, while attackers used help desk impersonation to reset single sign-on (SSO) passwords and MFA.
Scattered Spider has also used help desk social engineering as part of this identity-focused playbook.
Device code phishing bypasses push-specific detections
The OAuth device authorization flow gives attackers a path to valid tokens with no push at all. The attacker initiates a legitimate device authorization flow, persuades the victim to enter an attacker-provided code at the legitimate Microsoft sign-in page, and obtains tokens for the attacker-initiated device session after the victim completes authentication.
Storm-2372 device-code phishing has been linked to a suspected Russian nation-state actor. Microsoft reported that 93% of the device-code phishing events it observed across its 2024-to-2025 reporting year occurred in the second half of that window, and that both cybercriminal and nation-state actors used the technique.
A program built only around push-send, denial, and approval telemetry won't detect the core device-code interaction, which resembles a user completing a legitimate device flow.
Covering it needs device-code sign-in and OAuth telemetry, client and application context, IP and device anomalies, Conditional Access outcomes, and, where applicable, unexpected device-registration events.
A password reset alone doesn't complete containment
A password reset alone is not enough. In Entra, revoking sign-in sessions invalidates refresh tokens and browser session cookies, but already-issued access tokens can remain usable until they expire, typically about an hour by default. The sequence is to disable the account, revoke sign-in sessions and refresh tokens, then disable suspicious registered devices.
In Okta, session termination and OAuth-token revocation are separate controls, so revoking one token doesn't automatically revoke its paired token, and logging a browser out doesn't clear issued tokens.
Clear the user's sessions and revoke associated OAuth tokens through the tenant's session and token-revocation controls.
Then review activity after revocation, so a persistent actor is caught rather than assumed gone: check for new MFA enrollments, new app registrations, remote-management tools, and mailbox rule changes, because the approved push may have started a longer persistence effort.
Run the timeout test this week
Simulate a push flood where the victim ignores every prompt, and watch whether anything fires. If your Okta detection counts only explicit deny events, test whether it stays silent, because a silent detection has a timeout blind spot. Then take the question I now open every MDR evaluation with and point it at your own program: what would we have seen before the click?
I'd rather buy, or build, the pipeline that answers with a timeline than the one that answers with a threshold.
Frequently asked questions about MFA fatigue
How do you detect MFA fatigue attacks in Okta?
Use push-send events per user and session as the primary count, and test how ignored or abandoned pushes appear in your tenant. A high-confidence pattern is multiple denials or failures followed by a successful authentication in a short window. Enrich the push-send event with origin context so unfamiliar IPs and locations raise the signal's confidence.
What Entra ID sign-in log fields indicate MFA push bombing?
Look for strong-authentication failures, and inspect the authentication-step details available in your tenant to determine whether they distinguish a user declining the request from failing to respond to a mobile notification. Also check identity-protection and audit telemetry for user fraud reports or suspicious-activity detections.
Does number matching stop MFA fatigue attacks?
It raises the cost of blind push flooding, but the vished variant remains effective when the caller relays the displayed code to the victim over the phone. Test coverage across same-device and legacy integration flows, and prioritize phishing-resistant factors such as FIDO2 and FastPass over number challenges.
Treat number matching as a floor and keep monitoring for vishing and device code abuse.
What should the SOC do after a user approves a malicious MFA push?
Disable the account and revoke active sign-in sessions and refresh capabilities, then disable suspicious registered devices. Treat previously issued access as potentially usable for a limited period. Review post-approval activity for new MFA enrollments and app registrations, and check mailbox rule changes as well.
How should the SOC map MFA fatigue in MITRE ATT&CK?
Use the MFA request generation technique (T1621) to map repeated MFA request generation separately from post-access changes to authentication mechanisms. Keeping those behaviors distinct helps teams test both the initial credential-access path and later persistence activity.