TL;DR
  • MFA fatigue (also called push-bombing) is an attack that bypasses MFA by flooding a target with authentication push notifications until they approve one out of confusion or annoyance. It is low-cost, highly effective, and does not require any malware.
  • Uber and Cisco were both breached via MFA fatigue in 2022. Dozens of professional services firms — including law offices and financial advisers — have been compromised via the same vector without public disclosure.
  • Standard push-notification MFA is vulnerable. Number matching, FIDO2/passkeys, and conditional access policies eliminate the attack surface.
  • The upgrade path does not require replacing your entire identity stack. Most Microsoft 365 and Google Workspace tenants can enable phishing-resistant MFA with configuration changes that take less than a day.

Your firm has multi-factor authentication. Every staff member uses it. You feel confident that even if an attacker obtains a password — through phishing, a data breach at another service, or credential stuffing — they cannot access your systems without also controlling the employee’s phone. This confidence is reasonable, well-founded in the history of MFA effectiveness, and currently being systematically undermined by an attack technique that most small and mid-size firms have not heard of.

MFA fatigue, also called push-bombing or MFA bombing, does not try to defeat your MFA system. It uses your MFA system against you. The attack is simple in concept: the attacker has already obtained a valid username and password (usually through phishing or purchasing credentials from a breach database). They use those credentials to initiate repeated login attempts — sometimes dozens, sometimes hundreds — each of which triggers a push notification to the target’s phone asking them to approve the sign-in. The attacker waits. Eventually, the target approves one — because they think it is a system glitch, because they are busy and tapping approve by reflex, or because after the 30th notification at 11pm they just want their phone to stop buzzing.

This is not a theoretical attack. It is the documented technique behind some of the most high-profile corporate breaches of recent years, and it is actively used against professional services firms because those firms typically have strong perimeter defences but have not updated their MFA posture beyond basic push notifications.

How MFA fatigue actually works: the attack flow

MFA fatigue attack — step by step
1

Credential acquisition

The attacker obtains a valid username and password. Common sources: credential stuffing using email/password pairs from unrelated data breaches (many people reuse passwords), spear-phishing targeting the specific employee, or purchasing credentials from dark web markets. This step often happens weeks before the MFA fatigue attempt and may not trigger any security alert.

2

Push notification flood

With valid credentials in hand, the attacker initiates repeated login attempts to Microsoft 365, Google Workspace, or another SSO-protected system. Each attempt triggers a push notification to the target’s MFA app. The attacker typically sends notifications in bursts — sometimes continuously for hours, sometimes at specific times (early morning, late evening) when the target is less alert.

3

Social engineering amplification (optional)

More sophisticated attackers combine push-bombing with a phone call or WhatsApp message impersonating IT support: “Hi, this is IT. We’re running a system update and need you to approve the authentication request on your phone.” This dramatically increases approval rates and is the technique used in the Uber attack. The social engineering does not require sophisticated impersonation — people expect IT to call about authentication issues.

4

Approval and full account access

The target approves one notification. The attacker gains complete access to the account — email, documents, contacts, connected applications — with the same permissions as the legitimate user. Because the authentication was technically completed correctly (valid password plus MFA approval), many security information and event management systems do not flag the login as anomalous.

5

Persistence and lateral movement

With account access established, the attacker typically moves quickly to establish persistence — adding a second MFA device, creating OAuth tokens, or establishing forwarding rules — before the target notices anything unusual. In professional services breaches, this phase often includes harvesting client contacts, reading recent correspondence to understand ongoing matters, and identifying high-value data to exfiltrate.

Real incidents: Uber, Cisco, and the firms you didn’t hear about

Incident — September 2022

Uber Technologies

An 18-year-old attacker purchased Uber contractor credentials from a dark web market, then conducted an MFA fatigue attack combined with a WhatsApp social engineering call impersonating Uber IT. The contractor approved the MFA request. The attacker gained access to Uber’s internal network, Slack workspace, and multiple internal tools. The attacker then found credentials for Uber’s privileged access management system stored in a PowerShell script on a network share. The breach affected internal systems, customer data, and Uber’s HackerOne vulnerability disclosure programme. Reported remediation and incident response costs exceeded $23 million.

Incident — August 2022

Cisco Systems

Attackers associated with the YANLUOWANG ransomware group obtained an employee’s Google account credentials through a personal device compromise. The Google account contained saved passwords for corporate systems. The attackers then conducted a sustained MFA push notification campaign against the employee. The employee approved an authentication request after becoming confused by the volume of notifications. The attackers gained VPN access and moved laterally through Cisco’s network before being detected. Cisco disclosed that no customer data, sensitive employee data, or intellectual property was exfiltrated in the breach — but the breach demonstrated the technique’s effectiveness even against a security-mature organisation with significant security tooling.

The Uber and Cisco incidents are notable because they were disclosed. The far larger category of MFA fatigue breaches involves organisations that either did not detect the intrusion, detected it after significant data loss, or detected and remediated it without public disclosure. Professional services firms — law firms, accountancies, financial advisers — are disproportionately represented in the undisclosed category, because they face strong reputational incentives not to publicise security incidents and because their breach notification obligations, while real, can sometimes be managed without public disclosure if client personal data was not confirmed exfiltrated.

CISA (the US Cybersecurity and Infrastructure Security Agency) and the UK’s NCSC have both published advisories specifically addressing MFA fatigue as a threat vector. CISA’s 2023 advisory on “Implementing Phishing-Resistant MFA” explicitly names push-notification MFA as inadequate for high-value targets and recommends migration to FIDO2-based authentication as the baseline. The advisory is not targeted at government agencies — it applies to any organisation with sensitive data, including small professional services firms.

Why basic push MFA is not enough — and what actually is

The fundamental vulnerability of push-notification MFA is that it asks a binary question — “did you just try to log in?” — without providing the context needed to answer it correctly. When an attacker initiates a login, they trigger a notification that looks identical to one triggered by the legitimate user. The target sees “Approve sign-in?” and a button. Nothing in the standard push flow tells them where the login is coming from, what device initiated it, or what IP address is on the other end of the request.

Four controls materially reduce or eliminate MFA fatigue risk. They are listed in order of effectiveness and implementation complexity:

CONTROL 1

Number matching (immediate, high impact)

Number matching requires the user to enter a number displayed on the login screen into their MFA app before approving. The attacker, who is on a different device, does not see the number the user sees — so they cannot tell the user what to enter. An unsolicited push notification that asks the user to “enter the number shown on the screen” is immediately recognisable as illegitimate when the user is not at a login screen. Microsoft Authenticator and Google Prompt both support number matching. In Microsoft 365, it can be enabled for all users via a single policy change in Entra ID (formerly Azure AD). This is the highest-leverage, lowest-effort change available to most firms.

CONTROL 2

Phishing-resistant MFA: FIDO2 and passkeys (gold standard)

FIDO2-based authentication — hardware security keys like YubiKey, or device passkeys using biometric authentication — is the only form of MFA that is genuinely phishing-resistant. Unlike push notifications or TOTP codes, FIDO2 credentials are cryptographically bound to the specific website they were registered for. A FIDO2 credential for your Microsoft 365 tenant cannot be used to authenticate to any other site, which means phishing pages cannot steal them. And because FIDO2 requires physical possession and biometric or PIN confirmation on a registered device, it cannot be remotely approved by a confused employee. CISA and the NCSC both recommend FIDO2 as the target authentication posture for high-value accounts.

CONTROL 3

Conditional access and impossible travel detection

Conditional access policies add context to authentication decisions. Rather than simply asking “did the user provide valid credentials and MFA?”, conditional access asks “is this login from a device we recognise, in a location consistent with previous access, at a time consistent with this user’s patterns, using a compliant managed device?” Microsoft Entra ID and Google Workspace both support conditional access policies that can block or step up authentication for logins from unexpected locations, unmanaged devices, or anonymising proxies. Impossible travel detection — flagging a login from Singapore two hours after a login from London as requiring additional verification — catches a significant fraction of account takeover attempts before MFA fatigue has a chance to occur.

CONTROL 4

MFA push notification limits and anomaly alerting

Configure your identity platform to limit the number of MFA push notifications that can be sent per user per hour. Microsoft Entra ID allows you to configure notification throttling — after a certain number of declined or ignored requests, further attempts are blocked and an alert is sent to the security team. This does not prevent MFA fatigue but it limits the attack window and ensures that sustained push-bombing generates an alert rather than continuing silently. Even a small professional services firm should have alerts configured for unusual MFA activity — multiple declined pushes from a single account within a short window is a reliable signal of an ongoing attack.

How to upgrade MFA without disrupting your team

The concern most firm managers express when told they need to upgrade their MFA posture is that change will disrupt staff productivity. This concern is legitimate but frequently overstated. The upgrades described above — particularly number matching and conditional access — add seconds to the login process, not minutes. The disruption of a credential compromise and the subsequent incident response, by contrast, typically removes the affected employee from productive work for days and occupies senior partners and legal counsel for weeks.

The practical upgrade path for most small professional services firms using Microsoft 365 or Google Workspace looks like this:

MFA upgrade implementation checklist
  • Week 1: Enable number matching in Microsoft Authenticator or Google Prompt for all users. This is a policy setting in Entra ID / Google Admin Console. No user-side action required beyond updating their authenticator app. Deploy the policy in report-only mode for 48 hours to verify no production impact before enforcing.
  • Week 1–2: Enable conditional access policies blocking login from anonymising proxies and VPNs not on your firm’s approved list. Require compliant or managed devices for access to email and document stores. Monitor for false positives in report-only mode before enforcing.
  • Week 2: Configure MFA push notification throttling. Set an alert for more than 5 declined or ignored MFA requests from a single account within 30 minutes. Route the alert to a monitored mailbox or your security contact.
  • Week 3: Enable impossible travel detection. Review the default risk thresholds — most are sensibly calibrated but may need adjustment if staff routinely work from multiple countries.
  • Week 4: Pilot FIDO2 passkeys with a small group of willing staff — ideally senior partners with high-value data access. Windows Hello, Apple Face ID, and Android biometrics all support passkey authentication for Microsoft 365 and Google Workspace natively. The passkey experience is faster than push MFA once staff are familiar with it.
  • Week 6–8: Expand FIDO2 passkeys to all staff on managed devices. For staff using personal or unmanaged devices, enforce number matching as the minimum standard.
  • Ongoing: Run a quarterly authentication audit: review conditional access policy logs, check for accounts still using legacy authentication methods (SMS OTP, voice call MFA), and verify that no accounts are excluded from MFA requirements via legacy exclusion policies.

The timeline is conservative. Most Microsoft 365 tenants can enable number matching and basic conditional access in a single afternoon. The phased approach exists to catch unexpected issues — a legacy application that breaks with conditional access enforced, a staff member whose MFA app is not updated — before they become production incidents.

The legacy authentication blind spot: Many Microsoft 365 tenants have a small number of accounts or applications still using basic authentication or legacy protocols (IMAP, POP, SMTP AUTH) that do not support MFA. These accounts are completely invisible to your MFA controls — an attacker with the password has immediate access, no MFA required. Check your Entra ID sign-in logs for legacy authentication events. Block legacy authentication protocols in your Exchange Online policy unless you have a specific verified business requirement. Microsoft has been deprecating legacy auth since 2021 but legacy exclusions can persist for years in tenants that have not specifically addressed them.

The broader lesson: MFA is necessary but not sufficient

The emergence of MFA fatigue as a widespread attack technique illustrates a consistent pattern in enterprise security: defensive controls that were genuinely effective eventually become well-understood by attackers, who develop techniques specifically tailored to exploit their weaknesses. Password-only authentication was defeated by phishing. Standard MFA is being defeated by push-bombing and adversary-in-the-middle proxies. Phishing-resistant FIDO2 authentication represents the current best practice — but it too will eventually be challenged by new attack techniques.

This is not an argument for security nihilism — it is an argument for maintaining a current security posture rather than a circa-2018 security posture. The firms most exposed to MFA fatigue are not those with no MFA. They are those with MFA that was implemented several years ago and has not been reviewed since. “We have MFA” was a complete and correct security statement in 2019. In 2026, the correct statement is “we have phishing-resistant MFA with conditional access, and we reviewed it in the past six months.”

For professional services firms, the stakes of authentication failures are particularly high. A compromised email account at an accounting practice does not just expose the account holder’s inbox — it potentially exposes every client matter the account holder has corresponded about, every document they have access to, every system their credentials are stored in, and every client relationship the firm has invested years in building. The 72-hour GDPR breach notification clock is indifferent to how you were compromised. It starts the same way whether you were hit by zero-day malware or a sleepy employee who approved one too many push notifications at midnight.

Staff awareness training for MFA fatigue: Technical controls are more reliable than user behaviour, but user education is a useful complementary layer. Train staff on three things: (1) an unsolicited MFA push notification that appears when you are not logging in means your credentials are compromised — do not approve it and report it immediately; (2) IT will never call you and ask you to approve an MFA request; (3) if you receive multiple MFA requests in quick succession, assume an attack is underway and call your IT contact using a pre-established number (not one provided by the person calling you). These three points, delivered in a 20-minute briefing, measurably reduce MFA fatigue approval rates.

Authentication built for regulated teams

HubSecure enforces phishing-resistant MFA, conditional access, and impossible travel detection as standard features — not optional add-ons. Every session is verified. Every login event is audited. When your authentication posture matters as much as your compliance posture, they need to be designed together.

Reserve your founding seat