Uber's 2022 Incident: Lessons About MFA Fatigue

Uber's September 2022 security update said an attacker likely obtained a contractor's password after malware infected the contractor's personal device. Repeated two-factor prompts initially blocked access, but one was eventually approved.

The event became a clear example of MFA fatigue: a control can be worn down when prompts lack context and users are asked to make repeated security decisions under pressure.

One approved prompt opened a wider identity path

After the initial account access, the attacker reached additional employee accounts and internal tools. Uber responded by locking accounts, rotating keys, disabling tools, protecting source code, and requiring reauthentication.

The initial access combined endpoint exposure, a contractor identity, stolen credentials, push-based MFA, and internal permissions. Fixing only one element would leave the wider attack path available.

Make authentication harder to trick

Prefer phishing-resistant methods for privileged and high-risk access. Number matching and clear geographic or application context can reduce accidental approval, but users also need an immediate way to report unexpected prompts.

Treat repeated denials as a possible attack, not harmless user error. Investigate the device and account, revoke sessions, reset credentials, review MFA methods, and scope access to internal tools and secrets.

Extend identity controls to contractors and personal-device risk.
Alert on repeated push denials and unusual enrollment.
Reduce standing internal privilege.
Include tokens, keys, and sessions in containment.

Put the lesson into practice

Identify accounts still using simple push approval.
Move high-risk users to phishing-resistant MFA.
Alert on MFA fatigue patterns.
Give users a one-step reporting route.
Exercise contractor account compromise and secret rotation.

Related Outfaze guidance

Authoritative sources

Uber security update on the September 2022 incident