Multi-factor authentication was supposed to solve the credential theft problem. It has — partially. MFA significantly raises the cost of unauthorized access for attackers relying on stolen or purchased credentials. But attackers have adapted, and one adaptation in particular is causing breaches at organizations that believed MFA made them safe: push notification fatigue.
The organizations affected by MFA fatigue attacks weren't running weak security. In most cases, they had MFA deployed across the environment. The MFA just wasn't configured to resist this specific attack pattern.
What Is MFA Fatigue?
MFA fatigue — also called MFA bombing or push spam — works as follows:
An attacker obtains valid credentials through phishing, a credential dump, or access purchased on criminal marketplaces. Those credentials are correct — the password is right. The only barrier to access is the MFA approval step. So the attacker initiates a login attempt, triggering an MFA push notification to the legitimate user's device. Then they do it again. And again. Sometimes dozens of times over a short period — including at night, while the target is asleep.
Eventually, a user approves a request — to make the notifications stop, because they assume it's a system glitch, or simply while half-awake at 2am. That approval grants the attacker full, authenticated access to the account.
MFA fatigue exploits a human weakness, not a technical one. The attacker doesn't need to break the MFA system — they need the legitimate user to approve a request out of frustration or confusion. It works because standard push notifications don't tell the user who is initiating the login or from where.
Real-World MFA Fatigue Incidents
Two high-profile 2022 breaches illustrate that MFA fatigue is not a theoretical attack:
The Uber breach (September 2022) involved an attacker using MFA fatigue to gain initial access after credential compromise. The attacker repeatedly sent push notifications until the target approved — then used that authenticated access to move laterally through Uber's internal systems.
The Cisco breach (May 2022) followed a similar pattern. An attacker with compromised credentials used MFA push fatigue combined with voice phishing to obtain an MFA approval. Both organizations had MFA deployed. In both cases, the attack didn't break MFA — it persuaded a legitimate user to approve an attacker's session.
Microsoft's Response: Number Matching in Authenticator
Microsoft Authenticator now supports — and for most tenants, requires — number matching as the default MFA behavior. The mechanism is straightforward: instead of a simple "Approve / Deny" push notification, the login screen displays a randomly generated two-digit number. The user must input that number in the Authenticator app to approve the request.
An attacker sending fatigue requests cannot know the number displayed on the victim's login screen. They can send as many push notifications as they want — without the correct number, none of them can be approved. This single control defeats the MFA fatigue attack pattern entirely.
DOYB strongly recommends verifying that number matching is enabled for all Microsoft 365 environments. In tenants where it's not yet the default, it can be enforced through authentication policy configuration.
Additional Controls That Reduce MFA Fatigue Risk
Number matching addresses the push notification attack pattern specifically. A complete MFA hardening posture includes:
- Number matching in Microsoft Authenticator — eliminates the core push fatigue attack vector
- FIDO2 / passkeys — the strongest available authentication method; phishing-resistant and immune to push fatigue attacks entirely
- Biometric authentication where device and application support it
- Conditional access policies that limit login attempts, flag unusual behavior, and block access from unexpected locations or devices
- Geographic and network-based access restrictions — legitimate logins from unexpected countries or anonymous IP ranges should require additional verification or be blocked outright
- Security awareness training that specifically covers MFA push requests — users should understand that they should only approve notifications they initiated, and that IT will never ask them to approve an unexpected push
What to Review in Your Environment
When assessing MFA posture, the questions that matter are:
- Which MFA method is deployed — simple push notification, TOTP (time-based one-time password), number matching, or FIDO2?
- Is number matching enabled and enforced in Microsoft Authenticator? (Check authentication policy in Entra ID — this is not always enabled by default on older tenants.)
- What conditional access policies are in place, and do they cover sign-in risk signals?
- Does security awareness training specifically address MFA push fatigue — not just phishing generally?
- How are MFA bypass requests handled? (Help desk social engineering is a common secondary attack vector.)
An Ascend Cyber assessment evaluates your MFA configuration against current attack patterns — including whether your authentication controls would survive a credential compromise scenario where an attacker has valid credentials and is attempting to abuse the MFA process.