An MFA fatigue attack floods a user with repeated login approval prompts until they tap “approve” out of frustration or confusion. It only works because the attacker already holds the password. The second factor becomes the last line of defence, and that line depends on a tired person making the right call at the wrong moment.
This post explains how push bombing works, why standard push notifications fail against it, and which controls actually break the pattern. The focus is practical, written for IT managers running lean teams in the European mid-market, where a help-desk reset or a legacy SMS fallback is often the weakest link.
What is an MFA fatigue attack?
An MFA fatigue attack, also called push bombing or prompt bombing, is a social engineering technique where an attacker who already has valid credentials triggers a flood of multi-factor authentication prompts to a victim’s device, hoping they approve one to make the notifications stop.
Here is how push bombing works, step by step:
- The attacker obtains a valid username and password, usually through infostealer malware, phishing, or credential stuffing using passwords reused from earlier breaches.
- They enter those credentials on the corporate login portal, which triggers the organisation’s legitimate MFA workflow and sends a push prompt to the real user’s phone.
- They repeat the login attempt rapidly, often through automated scripts, generating a stream of push notifications in a short window.
- The prompts arrive at high-pressure moments, late at night or during a busy meeting, raising the user’s cognitive load and confusion.
- In more advanced cases, the attacker contacts the user through a side channel like WhatsApp or a phone call, posing as IT support and instructing them to approve the prompt to fix a “system error”.
- Once the user taps approve, the attacker has the session. They then register their own MFA device, change recovery settings, or generate long-lived tokens to keep access.
The technique does not rely on a software flaw. It targets human decision-making under pressure.
How push bombing actually works
The whole attack starts from one prerequisite: the attacker has the password. Without it, there is no login attempt and no prompt to spam. So the first question after any suspected fatigue attack is how the credential leaked.
Three sources dominate. Infostealer malware scrapes saved passwords from the browser on an unmanaged or personal device. Phishing harvests credentials through fake login pages. Credential stuffing replays username and password pairs from earlier breaches, betting that people reuse passwords. The Verizon 2025 Data Breach Investigations Report found that stolen credentials were the most common way into a breach, involved in 22 percent of all cases analysed, and that 88 percent of basic web application attacks used stolen credentials.
Once the attacker has working credentials, the spam begins. Each login attempt is technically legitimate, so your identity provider does what it is designed to do and sends a prompt. Automated, that becomes dozens of prompts in minutes.
Then comes the human part. The notifications keep coming. The phone keeps buzzing. The user assumes a glitch, or just wants the noise to stop, and approves one. In the polished version of the attack, a “helpful” caller claiming to be from IT removes the last doubt. Microsoft’s historical data from 2022 to 2023 suggested around 1 percent of users blindly approved the first unexpected prompt they received, a figure that climbed sharply with each additional prompt. Treat that as an order-of-magnitude indicator, but the direction is clear: persistence works.
When the approval lands, the attacker moves fast to make access permanent. They enrol their own authenticator, alter recovery options, or mint API and OAuth tokens that outlive a password reset.
Why standard push MFA fails, and what defeats it
Simple push MFA fails because it has no contextual validation and no cryptographic binding to the site the user is actually logging into. It hands the entire security decision to a human who may be stressed, tired, or distracted. The fix is not a single control. It is a set of technical barriers that remove the blind-approval reflex and make a stolen approval far less useful.
The table below maps the main controls to what each one actually stops.
| Control | What it stops | What it does not stop |
|---|---|---|
| Number matching | Blind approval of automated push bombing | AiTM proxy phishing that relays the number |
| FIDO2 / passkeys | Push bombing and AiTM phishing, by cryptographic domain binding | A weak fallback method left enabled alongside it |
| Conditional access | Logins from unknown or non-compliant devices | A managed device that is itself compromised |
| Device posture checks | Connections from the attacker’s own unmanaged machine | Approved access from a fully compliant endpoint |
| Rate limiting and lockout | The flood itself, by capping prompts per window | The underlying credential theft |
| Continuous evaluation | A hijacked session that changes behaviour mid-stream | The initial approved login |
Number matching is the quickest win. Instead of a yes/no tap, the login screen shows a two-digit number the user must type into their authenticator app. An attacker spamming prompts from their own machine has no way to know the number, so automated push bombing stops working. Microsoft Authenticator has enforced this by default since May 2023. It removes the reflex the attack depends on, but it is not a complete answer.
Phishing-resistant MFA is the stronger layer. FIDO2 and passkeys use asymmetric cryptography, where the private key stays in the device’s hardware enclave or on a physical security key and never leaves. During login the device runs a challenge-response bound to the exact domain open in the browser. On a lookalike site, the browser refuses to present the key. With no push prompt and no code to relay, the method is immune to both push bombing and adversary-in-the-middle phishing. The FIDO Alliance reported in its State of Passkeys 2026 survey that 68 percent of organisations had deployed passkeys or were rolling them out for their workforce.
Conditional access and device posture add a second test the attacker cannot pass from their own infrastructure. Even with a valid credential, the login is blocked unless it comes from a known, compliant device on a trusted path. Rate limiting caps how many prompts a device receives in a set window and alerts when the cap is hit. Continuous evaluation keeps checking risk across the session rather than once at login, forcing reauthentication or cutting the session if the IP, location, or behaviour shifts. For more on tying these signals together, see our guide to conditional access policies in 2026.
This is where the honest caveat belongs. No single control stops social-engineering pressure outright. Number matching can be relayed through a proxy. A determined caller can still talk a user through a passkey edge case. What layered identity, device posture, and least-privilege access do is limit what a single mistaken approval actually grants. The goal is a smaller blast radius, not a magic gate.
What a successful approval should and should not unlock
The controls above reduce how often a mistaken approval happens. The architecture behind them decides how much damage one does when it slips through. This is the part lean teams most often overlook.
In a traditional VPN setup, a single approved login drops the attacker onto the network with broad reach. They can scan for vulnerabilities, find domain controllers, and move laterally. The MFA check becomes an all-or-nothing gate, and once it is passed, trust is implicit.
Zero Trust Network Access changes that. Instead of network-level access, the authenticated user gets a tunnel to the specific applications their role needs, and nothing else. Domain controllers, finance systems, and OT environments stay invisible. Platforms like Jimber apply this per-application model so that one approved login under pressure does not expose the rest of the estate.
Device posture checks raise the bar further. Even if an employee approves a fraudulent prompt from home, the gateway refuses the connection when it comes from the attacker’s unmanaged machine, checking for disk encryption, current security software, and a corporate certificate first. Add continuous evaluation and a stolen session that suddenly changes geography or behaviour gets cut mid-stream.
For a closer look at why identity controls alone leave gaps that session theft can exploit, see our guide on why standalone ZTNA leaves identity exposed.
Why mid-market teams are more exposed
European organisations with 50 to 400 users carry specific weaknesses that make them attractive targets for identity attacks. The problem is rarely awareness. It is capacity and configuration.
Hardware security keys are the gold standard, but rolling FIDO2 tokens to every employee, handling loss and theft, and supporting hybrid staff is a heavy load for a small team. So many organisations stay on the easier but weaker push or SMS variants. That is the practical reason phishing-resistant MFA is still not the default in this segment.
The help desk is another soft spot. An outsourced or informal support desk is a frequent target for vishing, where an attacker calls claiming their phone broke and asks for a password reset and MFA re-enrolment. Without strict identity verification, like video confirmation or manager approval, the agent registers the attacker’s device. This path bypasses every technical control in front of the login.
Legacy fallbacks quietly undo good work. Many teams enable modern MFA but leave SMS or voice active as a backup. An attacker with the password can steer the login toward that weaker method, and the whole posture collapses to the weakest factor still switched on. If you deploy FIDO2, close the fallback path too.
Then there is SaaS sprawl. Without single sign-on, staff log into dozens of services a day, each with its own prompt. That density breeds real authentication fatigue and the habit of approving everything without thinking.
What European compliance now expects
Strong, phishing-resistant authentication has moved from best practice to legal expectation in much of Europe. Belgium transposed NIS2 into national law in April 2024, with the rules in force since October 2024, and the Centre for Cybersecurity Belgium (CCB) acting as the central authority. Board members and senior management can be held personally liable for serious negligence on security measures.
The CCB’s CyberFundamentals framework (CyFun) makes those obligations concrete. Under the Basic controls, which act as the baseline for smaller organisations, MFA is explicitly required for all external and remote connections. The Important and Essential levels go further, expecting blocking of known compromised credentials and phishing-resistant or continuous authentication mechanisms.
The gap between expectation and reality is wide. A CCB report from August 2025 found that only 46.4 percent of Belgian organisations actually enforce MFA on external connections, and most of those that do still rely on SMS or basic push, the exact methods vulnerable to fatigue attacks and proxy phishing. At the European level, the ENISA Threat Landscape 2025 report attributed 60 percent of initial network intrusions in the EU to phishing. For financial services, DORA mandates strict identity and access controls, and under GDPR, failing to implement adequate technical measures can carry penalties up to 20 million euro or 4 percent of global annual turnover.
Configuring MFA correctly is part of meeting these obligations. Our device posture checks for NIS2 guide covers how to build the evidence trail an auditor expects.
Frequently asked questions
What is the difference between an MFA fatigue attack and AiTM phishing?
MFA fatigue is a psychological attack. After stealing the password, the attacker sends repeated legitimate prompts until the user approves one out of frustration. Adversary-in-the-middle phishing is technical: a proxy site sits between the user and the real login, intercepting both the password and the live session token after a single MFA check. Our guide on how AiTM phishing works and what stops it covers that vector in detail.
Why is SMS the weakest form of MFA?
SMS verification is vulnerable on several fronts. It is not phishing-resistant, since users can be tricked into entering the code on a fake page. It is exposed to SIM swapping, where attackers social-engineer a telecom provider to move the number to their own SIM. And SMS messages can be intercepted through weaknesses in the ageing SS7 telecom protocol.
Does number matching stop push bombing completely?
Number matching defeats automated push bombing because the attacker cannot see the number the user must type. It does not stop adversary-in-the-middle phishing, where a proxy relays the legitimate number to the victim’s fake browser session. For that, only FIDO2 or passkey authentication with cryptographic domain binding provides immunity.
Can an attacker bypass number matching?
Yes, but not through ordinary automated fatigue attacks. They have to switch to an AiTM phishing proxy that passes the number through, or use social engineering such as a vishing call where they impersonate IT support and ask the user to read out the number on their screen to “resolve a system error”.
How do identity providers respond to push bombing?
Major providers introduced number matching as a direct response. Microsoft Authenticator enabled it by default worldwide in May 2023. Many now add context to prompts, such as the geographic location of the login attempt and the name of the application requesting access, to help users spot something suspicious.
Is MFA fatigue only a problem for large enterprises?
No. Mid-market organisations are increasingly targeted. Cybercrime-as-a-service has commoditised the scripts and credential lists needed, so even less skilled attackers can run campaigns at scale. Smaller IT teams also tend to spot abnormal login patterns more slowly and have help desks that are easier to manipulate.
If push bombing is on your radar, the practical next step is to look at how your identity, device, and access layers work together rather than at MFA in isolation. Book a Jimber demo to see how identity-based access, device posture checks, and continuous evaluation contain what one mistaken approval can reach.
