MFA Fatigue Bypassed Uber, MGM, and Cisco. Number Matching Stops It in One Config Change.

Three of the most expensive identity breaches of the last few years (Uber 2022, MGM 2023, Cisco 2022) had the same root cause: MFA fatigue. The attacker had a valid password (from a credential dump or social engineering); they triggered MFA push notifications repeatedly until the user, exhausted, tapped "Approve." The attacker walked in.

The defense, called number matching, is one IdP config change. Most major IdPs have supported it since 2022; Microsoft made it default-on in 2023. And yet a remarkable number of organizations still have not enabled it. Their MFA "works" in the sense that it requires a second factor; it does not work against an attacker who knows the most common 2026 attack pattern.

This post is the attack mechanics, the defense mechanics, and why number matching is the highest-leverage 30-second config change in identity security.

The attack#

The setup:

Attacker has the user's password (from a credential dump, phishing, or
helpdesk social engineering). They cannot log in alone because MFA is
required.

Attacker logs in repeatedly. Each login attempt triggers an MFA push
notification on the user's phone:
  "Approve sign-in to Okta?"
  [Approve] [Deny]

User receives notification 1 at 2:14 AM. Confused; deny.
User receives notification 2 at 2:14 AM. Annoyed; deny.
User receives notification 3 at 2:14 AM. ...
...
User receives notification 47 at 2:30 AM. Tired, half asleep, taps
Approve to make it stop.

Attacker is in.

Three properties make this attack effective:

1. Push notifications are designed to be tapped quickly. Modern phones train users to swipe-approve notifications without reading. The UX is a cost.

2. Push notifications have no context. "Approve sign-in?" with a yes/no is the entire information. The user does not see the source IP, the location, the device, or the time of the original login attempt.

3. Attackers can spam infinitely. No rate limit (or very generous one) on triggering MFA. The attacker can send 100 push notifications in a minute.

The Uber 2022 breach: attacker had purchased an employee's stolen credential on the dark web. Spammed MFA push notifications. Eventually contacted the employee on WhatsApp pretending to be IT support; convinced them to approve. Got in. Exfiltrated source code, internal Slack, and other internal systems.

Same pattern repeated at Cisco (May 2022), Microsoft (March 2022), MGM (September 2023), and many others. The pattern is so common it has its own name: "MFA bombing" or "push bombing."

The defense: number matching#

Number matching changes the push notification UX. Instead of a binary approve/deny, the notification shows a number, and the user must enter that number on the requesting device (laptop or browser).

Login attempt at the laptop:
  Browser shows: "Enter this number on your phone: 47"

Push notification on phone:
  "Approve sign-in to Okta?
   Type the number you see on the requesting device:"
  [_____ ]
  [Cancel]

User must:
  1. See the laptop's screen (because that is where the number is shown).
  2. Be willing to enter the matching number on the phone.

Attacker in their basement does not have access to the user's laptop screen.
The attacker started the login; the laptop showing the number is the
attacker's. The user's phone shows a prompt asking for a number; the user
has no way to know the number.

User cannot enter a meaningful number. The login fails.

The defense works because:

1. The number is shown only on the device that started the login. Attacker started the login on their device; the number appears on their device, not the user's.

2. The user has to enter, not approve. Mindless approval is impossible; entering 0000 or random numbers fails.

3. The user is forced to engage cognitively. "Why am I being asked to enter a number when I am not logging into anything?" is the question that breaks the attack.

This is not a perfect defense. A user who is also currently logging in legitimately and gets prompted at the right time might still mistake the attacker's prompt for their own. But it raises the attack cost dramatically and defeats the basic spam pattern.

How to enable it#

Per IdP, the rough path to enabling number matching:

Okta:

Admin Console -> Security -> Authenticators -> Okta Verify -> Edit
  -> "User interaction" -> change from "Push notification" to 
  "Number challenge" or "Verified push"
  -> Save

Then update the authentication policies to require this stronger
factor for sensitive apps.

Microsoft Entra ID (formerly Azure AD): number matching is on by default since February 2023. If you have an older tenant that opted out, re-enable.

Admin Center -> Security -> Authentication methods -> Microsoft
Authenticator -> Configure -> Number matching: Enable

Duo:

Admin Panel -> Authentication Methods -> Duo Mobile Push
  -> Verified Push: Enable

Google Workspace:

Google Prompt with number matching has been default since 2023.
If you are on legacy "Yes/No" prompts, migrate to "Tap a number" prompts.

For all of them, the rollout is:

1. Enable in audit/observe mode.
2. Watch for compatibility issues (some old client versions do not support number matching).
3. Switch to enforced mode.

Ten minutes of admin work; massive security improvement.

Why companies still have not enabled it#

Three reasons MFA fatigue defenses are not deployed:

1. The default-off legacy. Number matching arrived as an opt-in feature in 2022. Tenants created before then have to opt in. Many never have. Microsoft's default-on flip in 2023 covered Entra ID; Okta tenants still have to flip it manually.

2. Operational friction concerns. "Will users complain about a more complex MFA prompt?" Yes, briefly. They will get used to it within a week. The complaints are real but small; the security improvement is large.

3. The "we have MFA" checkbox. Compliance frameworks check for "MFA enabled," not "MFA that survives the most common 2026 attack." A team that has MFA-but-not-number-matching passes audit but fails the actual threat model.

The detection layer (in case the attack happens anyway)#

Number matching defeats most MFA fatigue attacks. The remaining ones (where the user does enter the right number, possibly under social engineering pressure) need detection.

Signals to monitor:

1. High volume of MFA challenges for one account in short time.
   Threshold: 10+ MFA challenges in 5 minutes.
   Action: alert security; lock the account temporarily.

2. MFA approved from new geo / impossible travel.
   Threshold: approval from a country the user has never authenticated from,
   or from a location that would require faster-than-airplane travel from
   their last known location.
   Action: page security on-call; force re-auth.

3. MFA approved very quickly after challenge.
   Threshold: approval within 1 second of challenge (mindless tap).
   Action: log; if combined with other risk signals, challenge.

4. Account recovery activity preceding MFA approval.
   Pattern: helpdesk-driven MFA reset, then login from new device.
   Action: page security; verify with the user out of band.

Each is a query on the IdP audit log. Most modern IdPs (Okta ThreatInsight, Auth0 Anomaly Detection, Entra ID Risk Detection) implement variations natively; you turn them on.

What about FIDO2 / hardware keys?#

FIDO2 (hardware keys, passkeys) is phishing-resistant by design and immune to MFA fatigue (no push to fatigue). For sensitive accounts (admins, executives, anyone with broad access), FIDO2 is the right answer.

But:

• Rolling out hardware keys to 5,000 employees is a logistics campaign (months).
• Some users will resist (perception of friction).
• Some apps do not yet support WebAuthn well.

Practical layered approach:

• Today: enable number matching for everyone. Free; immediate; defeats the basic attack.
• This year: roll out FIDO2 to admins, engineering, anyone with broad access. Expensive but manageable scope.
• Next year: extend FIDO2 to remaining roles based on risk.

Number matching is the floor; FIDO2 is the ceiling. Most organizations need both, deployed in that order.

Real incident: Uber 2022 reconstructed#

The Uber breach is well-documented because the attacker boasted about it publicly. The full chain:

1. Initial access: attacker bought a stolen credential for an Uber contractor on the dark web. The contractor used an Uber-managed device.

2. MFA bombing: attacker used the password to log in repeatedly to Uber's VPN. Each attempt triggered an MFA push to the contractor's phone. The contractor denied initially.

3. Social engineering: attacker contacted the contractor on WhatsApp pretending to be Uber IT. Said "we are working on a problem; please approve the next push so we can verify."

4. Approval: the contractor approved. Attacker had VPN access.

5. Lateral movement: from inside the network, attacker found a PowerShell script with a hardcoded admin credential for Privileged Access Management (PAM). Used it to gain admin to many systems (Slack, AWS, GCP, Google Workspace, internal tools).

6. Exfiltration: attacker dumped source code, posted screenshots in Slack, accessed financial info.

The defenses that would have stopped this:

• Number matching: defeats step 2 directly. Contractor cannot approve a number they do not see.
• FIDO2 instead of push MFA: defeats step 2 by design. No push to fatigue.
• No hardcoded credentials: would have prevented the privilege escalation in step 5.
• PAM with stronger MFA on admin paths: would have stopped the PowerShell credential from working.

Of these, number matching is the cheapest. Uber had push MFA; if it had been number-matching push, the attack stops at step 2.

Common mistakes around MFA in 2026#

• Default Okta Verify push (no number matching). Defeated by MFA fatigue. Switch to Verified Push.
• SMS as the primary MFA factor. Defeated by SIM swap. Phase out; TOTP minimum.
• MFA reset over phone without strong verification. Helpdesk social engineering. Require callback to the user's recorded number, or in-person.
• MFA only at IdP, not on sensitive apps. Step-up MFA missing. Sensitive operations (admin grant, deletion) need fresh MFA.
• No anomaly detection on MFA. Brute MFA bombing not flagged. Enable IdP anomaly features.
• Too many MFA notifications during normal work. Users are conditioned to tap-approve. Tune the prompt frequency.
• No FIDO2 for admins. Stronger factor available, not used. Issue hardware keys to admins minimum.
• MFA bypass for "trusted devices" without expiry. Attacker compromises the device; MFA is never required again.
• Number matching enabled but only for some apps. Inconsistent; users get confused. Enable globally.
• No audit on MFA factor changes. Attacker adds a new factor to a compromised account; nobody knows. Alert on factor enrollment.

Quick reference: MFA fatigue defense checklist#

Today (immediate, free):
  [ ] Enable number matching at the IdP for push factor
  [ ] Disable SMS factor (or restrict to recovery only)
  [ ] Enable IdP anomaly detection (Okta ThreatInsight, etc.)
  [ ] Page security on > 10 MFA challenges per account per 5 min

This quarter:
  [ ] Issue FIDO2 keys to all admins; enforce in policy
  [ ] Step-up MFA for destructive admin operations
  [ ] Helpdesk policy: no MFA reset over phone without callback

This year:
  [ ] FIDO2 rollout to engineering, then broader workforce
  [ ] Tabletop exercise: MFA fatigue + helpdesk social engineering
  [ ] Audit all MFA factors for compliance with the new policy

The mental model#

Push MFA as deployed in 2018-2022 was a real improvement over SMS. It worked because attackers had not yet adapted. By 2022, the attackers had adapted (MFA fatigue), and basic push became the new weak link. Number matching is the small change that adapts the defense.

The pattern repeats: every defense becomes the new attack target. SMS gave way to TOTP; TOTP gave way to push (faster, more user-friendly); push gave way to FIDO2 (phishing-resistant). Each step is a response to attacks the previous step did not anticipate.

In 2026, the right MFA strategy is layered: TOTP minimum for everyone, push-with-number-matching for those who want the convenience, FIDO2 mandatory for admins. The 30-second config change to enable number matching closes a class of attack that has cost real companies real money. There is no excuse to leave it off.

---

MFA, identity attacks, and the broader zero-trust posture are covered in the Identity and Trust for DevOps Engineers course. The Kubernetes-side equivalent (RBAC + MFA-required IdP federation + audit on auth events) is part of the Kubernetes Security course.