Prevent MFA Fatigue Attacks: 2026 Push-Bombing Guide
Prevent MFA fatigue attacks with number matching, rate limits, and phishing-resistant MFA. Step-by-step 2026 guide for MSPs securing client accounts.
DefendWise
DefendWise
MFA fatigue attacks — also called push-bombing — work by flooding a user's phone with authentication requests until they tap "approve" just to make the notifications stop. Here's the exact sequence to shut that attack down before it reaches your end clients in 2026.
TL;DR
- Number-matching MFA stops push-bombing cold — DefendWise recommends it as the first fix, not an afterthought.
- Uber's 2022 breach started with an MFA fatigue attack; the pattern hasn't changed by 2026, only the volume of attempts has grown.
- Rate-limiting push requests to 3 per 10 minutes cuts off the flood attackers rely on.
- Training that simulates real push-bombing scenarios beats generic phishing awareness for this specific threat.
- Verdict: pair phishing-resistant MFA with simulation-based training — Buy this combination, Skip push-only MFA in 2026.
Why this matters
Push-bombing doesn't exploit a software bug — it exploits exhaustion. An attacker with a stolen password triggers dozens of MFA push notifications in a row, betting that a tired employee will hit "approve" on the fifteenth ping just to silence their phone. Cisco's 2022 breach and Uber's 2022 incident both trace back to this exact pattern, and by 2026 the technique remains one of the cheapest ways to bypass MFA because it requires zero malware and zero exploit development.
The fix isn't more training slides about "strong passwords." It's a specific combination of MFA configuration changes and targeted simulation that teaches employees to recognize and report the pattern instead of clicking through it.
What you'll need
- Admin access to your identity provider (Entra ID, Okta, Duo, or similar) to change MFA push settings
- A list of accounts still using push-only MFA, especially privileged and finance accounts
- A phishing simulation and awareness platform that can run push-bombing scenarios, not just email phishing
- 30-45 minutes to reconfigure MFA policies per tenant
- A short incident response note so end users know exactly who to call when the pings start
The steps
1. Turn on number matching for every push-based MFA app
Number matching forces the user to type a code shown on their login screen into the push notification, instead of tapping a single "approve" button. This single change removes the one-tap failure point that makes push-bombing work at all. Microsoft Authenticator, Duo, and Okta Verify all support this — enable it at the tenant level, not per-user, so no account slips through. Expected outcome: a flood of push requests becomes useless to the attacker because each one now requires the correct on-screen code. Common mistake: enabling it only for admin accounts and leaving regular staff on tap-to-approve, which is exactly where most push-bombing attacks land first.
2. Rate-limit push notifications per account
Cap authentication attempts at roughly 3 requests per 10-minute window, then auto-lock the account and alert an admin past that threshold. This directly starves the attack of its main weapon — volume. Most identity providers support this as a conditional access or risk policy; if yours doesn't, this is a strong signal to reconsider vendors during your next security review. Expected outcome: an attack that used to generate 20-30 push notifications in a sitting now gets shut down after 3. Common mistake: setting the threshold too high (10+) because it feels safer for legitimate users who mistype passwords — that gap is exactly what attackers exploit.
3. Move privileged accounts to phishing-resistant MFA
FIDO2 security keys and platform passkeys can't be push-bombed because there's no approval prompt to spam — the cryptographic handshake either happens on the physical device or it doesn't happen at all. Prioritize domain admins, finance approvers, and anyone with wire-transfer authority first. Expected outcome: your highest-value accounts become immune to the entire attack category, not just harder to hit. Common mistake: buying keys and never actually enforcing them — audit enrollment weekly for the first month.
4. Add a mandatory "stop and report" step to MFA training
Employees need one instruction, repeated until it's automatic: unexpected push requests get denied and reported, never approved out of frustration. Run this through a simulation platform that can trigger a realistic burst of push prompts, not just a phishing email test — see how to test employees against spear phishing and BEC for the broader testing framework this fits into. Expected outcome: measurable drop in approval-under-pressure behavior within one training cycle. Common mistake: treating this as a one-time email instead of a repeated simulation, since push-bombing muscle memory fades fast without reinforcement.
5. Build a fast reporting path for MFA anomalies
Employees who get bombed need a one-click way to flag it — Slack channel, hotline, or a button inside your ticketing tool — that reaches IT in under five minutes. Slow reporting is why so many push-bombing incidents escalate; the attacker only needs a few minutes of confusion. Expected outcome: IT can lock the account and rotate credentials before the attacker moves laterally. Common mistake: burying the reporting instructions in a policy PDF nobody reads after onboarding.
6. Review sign-in logs for repeated denied MFA attempts weekly
A pattern of denied pushes on the same account, even without a successful breach, is a leading indicator someone has that user's password. Set a SIEM or identity-provider alert for 3+ denied attempts within an hour and route it to a human, not a dashboard nobody checks. Expected outcome: you catch credential compromise before the attacker finds a tired employee on a bad day. Common mistake: only reviewing logs after an incident instead of on a fixed weekly cadence.
7. Simulate a push-bombing scenario at least once per quarter
Generic phishing simulations don't test this behavior — you need a scenario that specifically fires repeated authentication prompts and measures who approves versus who reports. Tie results back to your incident response documentation, covered in how to build a phishing incident response plan, so the simulation and the real response process match. Expected outcome: a documented, improving approval-rate metric you can show clients or auditors. Common mistake: running the same scenario every quarter — vary the pretext or employees stop reacting realistically.
Troubleshooting
- Users complain number matching is slower — it adds maybe 5 extra seconds per login. Frame it as the cost of not getting breached; the alternative is a single tap away from compromise.
- Rate limits are locking out legitimate users — check if the threshold is too aggressive for staff with unreliable networks who retry logins. Adjust the window, don't disable the control.
- Employees still approving unexpected pushes despite training — the simulation frequency is too low. Move from annual to quarterly cadence and track individual repeat-offenders for a direct conversation.
- No visibility into denied MFA attempts — this usually means log retention or alerting isn't configured in the identity provider. Fix the alert rule before doing anything else on this list.
- Privileged accounts still on push-only MFA months later — enrollment isn't the same as enforcement. Set a hard deadline and block sign-in for non-compliant accounts past that date.
Train clients against push-bombing now
Flat $399/month, unlimited seats, deploy once and it runs itself.
Tools and resources
- Your identity provider's conditional access or risk policy settings (Entra ID, Okta, Duo)
- FIDO2 security keys or platform passkeys for privileged accounts
- A simulation platform that supports push-bombing and MFA-specific scenarios, like DefendWise
- Your documented phishing incident response plan with a specific MFA-anomaly branch
- Cyber insurance documentation — many carriers now ask directly about MFA controls; see security awareness training for cyber insurance requirements for what evidence they expect
What to do next
Once push-bombing is covered, widen the lens to adjacent social engineering tactics that target the same tired, distracted employees — deepfake voice and video calls impersonating executives are the next escalation attackers are already using in 2026. Read how to protect employees from deepfake executive impersonation scams for the follow-up controls MSPs are deploying alongside MFA hardening.
FAQ
What is an MFA fatigue attack?
An MFA fatigue attack, or push-bombing, is when an attacker with a stolen password triggers repeated MFA push notifications until the user approves one out of frustration. It requires no malware — only a compromised password and patience.
How do you prevent MFA fatigue attacks?
Enable number matching on push notifications, rate-limit requests to around 3 per 10 minutes, and move privileged accounts to phishing-resistant MFA like FIDO2 keys. Pair the configuration changes with simulation-based training so employees know to deny and report unexpected prompts.
Is number matching enough on its own?
Number matching removes the one-tap approval flaw but doesn't stop an attacker from calling the employee and coaching them through the code, which is why training on the pattern still matters. Configuration and training work together, not as substitutes.
What's the difference between MFA fatigue and vishing?
MFA fatigue relies purely on volume and annoyance, while vishing adds a phone call where the attacker impersonates IT to talk the victim through approving the request. Both target the same distracted employee under pressure.
How often should you simulate push-bombing scenarios?
Run push-bombing-specific simulations at least once per quarter in 2026, varying the pretext each time so employees don't just memorize one scenario. Annual testing is too infrequent for a tactic this cheap for attackers to repeat.
Does cyber insurance require MFA fatigue protections?
Many 2026 cyber insurance applications specifically ask about number matching and phishing-resistant MFA on privileged accounts, not just whether MFA exists. Carriers increasingly want evidence of configuration, not a checkbox.
Can rate-limiting lock out real employees?
A well-tuned rate limit, around 3 attempts per 10 minutes, rarely affects legitimate users since normal logins don't generate repeated authentication prompts. If lockouts spike, the threshold needs adjusting, not removing.
Are push notifications worse than SMS codes for MFA?
Push notifications are more convenient but more vulnerable to fatigue attacks unless number matching is enabled, while SMS codes carry their own SIM-swap risk. Phishing-resistant options like FIDO2 keys outperform both for high-value accounts.
One last thing
The Uber breach in 2022 didn't need a zero-day — it needed one exhausted contractor and about 20 minutes of repeated push notifications. Number matching alone would have stopped it, and by 2026 there's no excuse left to run push-only MFA on any account that touches money or admin rights.