MFA fatigue attacks succeed by exhausting a user with repeated authentication prompts until one gets approved by mistake or out of frustration, so detection means watching authentication logs for volume and timing anomalies, not waiting for a single denied push to trigger anything. The signal that matters is a cluster of prompts sent to one identity in a compressed window, especially outside that user's normal login hours. A single rejected push tells you almost nothing on its own — the pattern only becomes visible when you correlate volume, timing, and device consistency together.
- You detect MFA fatigue attacks by tracking prompt-volume spikes to a single identity, not isolated denials.
- Number matching and phishing-resistant factors remove the prompt entirely instead of relying on detection after the fact.
- Secfolio pairs passwordless authentication with identity microsegmentation so a successful fatigue attack still cannot move laterally.
- Most detection programs fail because push-only MFA generates too much noise for SOC teams to triage in 2026.
Why this matters
Push-based MFA was built to stop credential replay, not to withstand an attacker who just keeps pressing send. Once an attacker has a valid username and password — usually from a prior phishing kit or credential dump — the push prompt is the only thing standing between them and the account. If a security team's only control is that the user has to say no every single time, that control fails the moment the user gets tired, distracted, or confused about which app sent the request.
This is why MFA fatigue, also called push bombing, keeps showing up in enterprise breach reports years after CISA and the FBI flagged it in a 2022 joint advisory. The attack needs no new malware and no zero-day. It needs patience and a phone tied to an identity with standing access, which is exactly the gap passwordless authentication at enterprise scale is designed to close. In 2026 the attack is cheaper to run than ever, because credential dumps and automated push loops are commodity tooling.
How to detect MFA fatigue attacks
Detection works in layers. Each step below narrows the window between the first prompt and the moment a SOC analyst sees an alert.
- Log every authentication attempt, not just successes. Denied pushes, timed-out pushes, and approved pushes all need to land in the same event stream so a pattern can form.
- Set a threshold for repeat prompts to one identity. One account receiving multiple prompts back to back is the core signal — tune the count and window to your organization's normal MFA volume.
- Cross-reference prompt timing against login history. A burst of prompts at 3 a.m. against an account that has never authenticated outside business hours is a far stronger signal than the same burst at 9 a.m.
- Check device and location on the approving session. An approval from a device or IP range the identity has never used, arriving moments after a denial from somewhere else, is close to a confirmed compromise.
- Route the alert to a human analyst in real time. Fatigue attacks play out in minutes; a report generated the next morning is a post-incident record, not a detection control.
The push-prompt volume signal
Volume is the cleanest signal available because it is the one thing an attacker cannot avoid generating. A legitimate user denies a push once, maybe twice, then stops and calls IT. An attacker running a fatigue campaign keeps sending, because the entire attack depends on the user eventually tapping approve. Any spike in repeated prompts to a single identity inside a short window should generate an alert, full stop — that rule belongs in every 2026 detection program regardless of which MFA vendor is in place.
The approval-timing signal
The second-most useful signal is what happens immediately before the approved prompt. Several denials followed by one approval is far more suspicious than an isolated approval with no denials in front of it. Correlating denial-then-approval sequences catches attacks that a raw volume threshold misses, particularly when an attacker paces prompts to stay under a count-based rule.
“The prompt count matters less than the pattern – a denied push followed by an approved one, minutes apart, is the tell.”
The device and geography mismatch signal
An approval from a new device fingerprint or an IP range outside the user's normal geography, in the same session as a fatigue burst, moves an alert from worth reviewing to treat as compromised now. This signal also ties detection to response: once device mismatch confirms compromise, the account needs a credential reset plus a sweep for stale or orphaned privileged accounts the session may have touched.
Why MFA fatigue attacks succeed
Detection gaps are rarely a tooling problem. They are a design problem in how push MFA was deployed.
- No number matching enabled. Without a code the user must read and type, every prompt looks identical, which removes the friction that forces a person to think before approving.
- Push-only MFA with no phishing-resistant fallback. Organizations that never rolled out FIDO2 keys or platform passkeys leave every identity dependent on a single fatigue-prone factor.
- No SOC correlation rules for prompt volume. Most identity providers log the data; far fewer enterprises alert on the pattern before the user caves.
- Analyst alert fatigue mirrors user alert fatigue. When every login generates noise, analysts start ignoring the same signal users are ignoring.
- Standing access with no segmentation. After a successful approval, an attacker with unrestricted lateral movement reaches far more than that one identity should ever touch.
- No real-time triage path. Detection that surfaces the next day does not stop an attack that finishes in minutes.
Is MFA fatigue the same as push bombing?
Yes, MFA fatigue and push bombing describe the same attack — repeated authentication prompts sent to a user until one is approved. Security teams and vendors use the terms interchangeably. Neither term implies a different technique or a different fix.
Does number matching stop MFA fatigue attacks?
Number matching reduces MFA fatigue attacks but does not eliminate them, because it forces the user to enter a code shown on the login screen instead of tapping a single approve button, which removes accidental approvals from confusion. It does not stop a user who is socially engineered into reading that number back to an attacker on a phone call, which is why phishing-resistant factors such as FIDO2 keys and passkeys close the gap number matching leaves open.
What happens after an MFA fatigue attack succeeds?
After an MFA fatigue attack succeeds, the attacker holds a valid authenticated session and moves immediately to expand access, probing for standing privileges, service accounts, and admin paths reachable from the compromised identity. Detection alone is not enough at this stage — containment decides the outcome, which is the job of identity microsegmentation that limits how far one approved login can reach.
Secfolio treats MFA fatigue as a credential-layer problem first: passwordless authentication removes the push prompt this attack depends on, and identity microsegmentation contains the blast radius when a prompt still gets approved. Neither control closes the gap alone. Together they turn a fatigue attack from a likely breach in 2026 into a contained, low-impact event.
Remove the push prompt entirely
See how enterprise passwordless authentication replaces the weak point MFA fatigue exploits.
FAQ
What is the best way to detect MFA fatigue attacks in real time?
The best way to detect MFA fatigue attacks in real time is correlating repeated push prompts to one identity with the timing and device of the eventual approval, then routing that alert straight to an analyst instead of a daily digest.
Is an MFA fatigue attack the same as push bombing?
Yes, MFA fatigue and push bombing are the same technique – repeated authentication prompts sent until the user approves one, by mistake or by exhaustion.
Does number matching stop MFA fatigue attacks?
Number matching reduces MFA fatigue attacks significantly but does not stop every case, since a determined social engineer can still talk a user through reading back the matching code over the phone.
Is passwordless authentication more resistant to MFA fatigue than push MFA?
Passwordless authentication is more resistant to MFA fatigue than push MFA because it removes the repeatable prompt the attack depends on, replacing it with a phishing-resistant factor bound to a key or device.
Can identity microsegmentation limit damage from a fatigue attack?
Identity microsegmentation limits damage from a fatigue attack by containing what a compromised identity can reach after approval, so one approved push does not open unrestricted lateral movement.
How do SOC teams triage MFA fatigue alerts?
SOC teams triage MFA fatigue alerts by comparing prompt volume against the user’s normal login pattern first, then confirming device and location before forcing a credential reset.
Should enterprises drop push notifications for phishing-resistant MFA?
Enterprises should move high-privilege and high-risk accounts off push notifications to phishing-resistant MFA first, because those accounts carry the most damage when a fatigue attack succeeds.
What happens after an MFA fatigue attack succeeds?
After an MFA fatigue attack succeeds the attacker holds an authenticated session and probes immediately for standing privileges and lateral paths, which is why containment matters as much as detection.
One last thing
Most enterprises will spend their 2026 identity budget tuning detection thresholds for an attack that phishing-resistant authentication removes outright. Detection buys time; it does not close the gap. The fastest way to stop losing this fight is to stop giving attackers a prompt to exhaust — move privileged and high-risk identities to passwordless authentication and let detection cover the push-only accounts still in transition.
Related guides
- How to stop credential theft in Active Directory environments
- How to detect shadow admin accounts in Active Directory
- How to monitor privileged access continuously
- How to reduce blast radius after credential compromise
