MFA Is Not the Finish Line
In September 2022, Uber got breached. The attacker used a stolen contractor password and then, when MFA push notifications started arriving on the contractor's phone, sent them repeatedly for over an hour. The contractor, presumably exhausted by the relentless notification flood, eventually approved one. The attacker was in.
The technique is called MFA fatigue. It is not sophisticated. It requires no technical skill beyond persistence and a basic understanding of human psychology, specifically that people will eventually tap "Approve" just to make something stop. Uber had MFA deployed across their environment. It did not stop the breach.
MFA is one of the most effective security controls available. It is also not a finish line. It is the beginning of a longer conversation.
What MFA Actually Stops
Let's be fair to MFA first. Credential stuffing attacks, where attackers take username and password combinations from old breaches and try them everywhere, are almost entirely neutralized by MFA. Password spray attacks, where one common password gets tried against thousands of accounts, same thing. If your threat model is "someone buys a credential dump and tries to log into our environment," MFA is an excellent answer.
That threat model covers a lot of attacks. MFA adoption genuinely reduces breach risk. The evidence on this is strong and consistent. This is not a post arguing against MFA.
This is a post about what happens when organizations check the MFA box and stop thinking.
What MFA Does Not Stop
Push notification fatigue is the obvious one after Uber. But the more technically interesting bypass is adversary-in-the-middle phishing. Tools like Evilginx and similar frameworks set up proxy sites that sit between the user and the real service. The user thinks they're logging into the real site. They enter their credentials and approve their MFA prompt. The proxy captures the resulting session token in real time. The attacker now has an authenticated session with no need for the credentials or the MFA code.
The user did everything right. They entered their real password. They approved a legitimate MFA prompt. They were phished anyway, because MFA-based authentication can be relayed in the same moment it happens.
This is not hypothetical. These kits are commercially available. They are used in real attacks against real organizations. The specific defense against them is phishing-resistant MFA, which is a different category entirely.
Phishing-Resistant MFA Is a Different Thing
FIDO2 hardware keys and passkeys are fundamentally different from push-based or TOTP-based MFA. They are cryptographically bound to the legitimate domain. A proxy attack cannot relay them because the key's response is specific to the origin it registered with. You cannot man-in-the-middle a hardware key the same way you can relay a push notification.
Most organizations are running push-based MFA because it is easy to deploy and users tolerate it. That is a reasonable place to start. It is not where you want to stay if your risk profile involves targeted attacks rather than opportunistic credential stuffing.
The migration path from push MFA to FIDO2 is real work. Hardware keys cost money and require distribution. Passkeys require platform support and change management. The operational lift is meaningful, which is why it doesn't happen automatically after the initial MFA rollout.
The Controls That Make MFA More Effective
While you're working toward phishing-resistant MFA, conditional access policies do a lot of heavy lifting. Limit MFA approvals by device compliance, location, and time of day. Flag push notifications from unexpected locations before they reach the user. Implement number matching on push prompts, which requires the user to enter a code displayed on the login screen into the push notification, making approval a conscious act rather than a reflexive tap.
Set a maximum number of push attempts before an account gets locked or flagged. The Uber attacker sent pushes for over an hour. That should not be possible without a security alert firing somewhere.
Session management matters too. Short session lifetimes limit the damage from a stolen token. Continuous access evaluation, where session validity is re-checked against current conditions rather than trusted indefinitely from login, is becoming table stakes for higher-risk environments.
MFA is not the finish line. It is a gate that raises the cost of a certain class of attacks, while leaving other doors open that require different controls. Deploy it because it works. Then keep building.