MFA Fatigue: The Risk Behind Push Approvals

Multi-factor authentication (MFA) is one of the most important safeguards for user accounts. With MFA in place, a compromised password alone is no longer enough to gain access to a protected account.

But MFA can still be bypassed. In so-called MFA fatigue attacks, the weak point is not a technical vulnerability, but the user approving a sign-in request.

What is MFA Fatigue?

MITRE ATT&CK tracks this technique as “Multi-Factor Authentication Request Generation” (T1621). Attackers deliberately generate MFA requests for a user account in an attempt to trigger a valid approval. [1]

In a typical scenario, attackers already have valid credentials, obtained through methods such as phishing, infostealer malware, data breaches, or credential stuffing. In certain configurations, MFA requests can also be generated through self-service password reset processes. [1]

In a classic MFA fatigue attack, repeated sign-in attempts are made against the account. Each attempt can trigger another push notification on the user’s smartphone.

When these requests arrive in quick succession, the likelihood of a mistaken approval increases. Eventually, one may be approved – accidentally, out of habit, or simply to make the notifications stop. This technique is therefore also known as “MFA bombing” or “push bombing.” It primarily affects authentication methods that rely on simple Approve/Deny prompts.

Why Simple Push Approvals Are a Problem

A single unexpected MFA request is likely to attract attention. A stream of notifications is a different matter. Users may assume there is a technical issue, mistake the request for a legitimate sign-in, or approve a notification under time pressure without checking what triggered it. That is exactly the kind of mistake the attack is designed to exploit.

MFA fatigue is therefore not just an awareness issue. The design of the authentication method also determines whether a single mistake can directly result in a sign-in being approved.

A Documented Case: Uber 2022

The September 2022 security incident at Uber demonstrated how effective MFA bombing can be.

According to Uber, the attackers first obtained the credentials of an external contractor. They then repeatedly attempted to sign in using that account. The contractor received multiple two-factor authentication requests and eventually approved one of them. [3]

The case illustrates a key characteristic of MFA fatigue: the multi-factor authentication mechanism worked as designed. The attack targeted the approval step.

Phishing-Resistant MFA as the Target State

CISA recommends that organizations move to phishing-resistant authentication methods wherever possible. These include methods based on FIDO and WebAuthn. Where this is not yet feasible, number matching provides a stronger alternative to simple push approvals. [2]

Instead of simply approving a request, users must match a number displayed during sign-in with the authenticator app. This makes the accidental approvals targeted by MFA fatigue attacks much less likely. However, number matching is not the strongest MFA method available.

FIDO/WebAuthn goes a step further. By cryptographically binding authentication to the legitimate service, it also protects against attacks in which users are tricked into authenticating on a fake login page.

Organizations do not need to migrate every account immediately. A risk-based approach makes sense, starting with administrative and other privileged accounts as well as sensitive remote and cloud access.

Conditional Access Adds Another Layer

MFA should not be considered in isolation. Identity platforms can incorporate additional context into access decisions, such as device status, the origin of a sign-in attempt, or detected sign-in risks.

To mitigate MFA request attacks, MITRE recommends measures including Conditional Access policies that can restrict sign-ins from non-compliant devices or from outside defined network locations. The number of MFA requests allowed within a given period can also be limited. [1]

This means an access decision does not depend solely on whether a push request is approved.

MFA Fatigue Can Be Detected

Repeated authentication requests leave traces. MITRE lists indicators including:

• an unusually high number of MFA requests for a single account,
• repeated MFA challenges generated within a short period,
• sign-in attempts from unusual IP addresses or geographic locations,
• MFA requests that do not correspond to a user-initiated session. [1]

Authentication and identity logs should therefore be part of security monitoring. Depending on the platform, these events can be analyzed through a SIEM or native detection and alerting capabilities.

A spike in denied or unanswered MFA requests is more than just an annoyance. It can indicate that an account is under active attack.

Six Questions for Your Admin Check

1. Are simple Approve/Deny push methods still in use?
2. Is number matching enabled?
3. Which accounts require phishing-resistant MFA?
4. Are Conditional Access policies configured appropriately?
5. Are unusual MFA events being monitored?
6. Is there a reporting process for unexpected MFA requests?

Users should only approve MFA requests they initiated themselves. Unexpected requests should be denied and reported to the appropriate IT or security team. Such a report can provide an early warning that an attack is underway.

Not All MFA Is Equal

Multi-factor authentication remains an essential safeguard for digital identities. MFA fatigue is not an argument against MFA – it is a reason to take a closer look at the authentication methods being used.

For IT teams, asking “Is MFA enabled?” is therefore not enough. What matters is how sign-ins are approved, which accounts require stronger protection, and whether suspicious MFA activity can be detected. Number matching, phishing-resistant authentication, Conditional Access, and monitoring address these risks at different points.

Sources: