MFA Is Not a Finish Line

Turning on multi-factor authentication is the single highest-value security change most businesses ever make. We recommend it constantly. It stops the overwhelming majority of opportunistic attacks, and if you have not enabled it everywhere, stop reading and go do that.

But somewhere along the way, MFA got treated as a finish line. A box ticked, a risk closed, an answer on a questionnaire. It is not. Attackers stopped trying to break MFA years ago. They route around it instead, and they do it often enough that every business relying on it should understand how.

The core problem, in one sentence

MFA protects the moment you log in. It does not protect the session that follows.

Almost every bypass technique in active use today exploits that gap. Once you have authenticated, your browser holds a session token — a small piece of data that says "this person already proved who they are." Steal that token and you do not need the password, the code, or the phone. You are already inside.

How attackers actually get past MFA

Adversary-in-the-middle phishing. This is the big one. The victim clicks a link and lands on a page that looks exactly like their Microsoft or Google login, because it is a live proxy of the real thing. Everything they type is passed straight through to the genuine service. They enter their password. They enter their code. They get logged in for real. Meanwhile the attacker has captured the session token in transit.

This is not exotic. Ready-made toolkits — Evilginx2, EvilProxy, Tycoon 2FA, Mamba and others — are sold as a service to people with no technical skill. Security researchers tracking this class of attack have reported a 146% surge, with tens of thousands of incidents detected daily.

MFA fatigue, or push bombing. The attacker already has the password and simply requests login over and over. The victim's phone buzzes every few minutes, at dinner, at midnight, in a meeting. Eventually someone taps approve to make it stop. This is how attackers got into Uber in 2022, via a contractor who caved after a sustained barrage.

Help desk social engineering. No technology is bypassed at all. The attacker phones IT support, impersonates an employee who has lost their phone, and asks for an MFA reset. This was central to the MGM Resorts breach in 2023. Your MFA is only as strong as the process for resetting it, and that process is usually a person under time pressure trying to be helpful.

Legacy protocols. Older mail protocols such as IMAP, POP3 and SMTP predate modern authentication and will happily accept a username and password on their own. If basic authentication is still enabled anywhere in your tenant, MFA is optional from the attacker's point of view.

SIM swapping. The attacker persuades a mobile carrier to port a phone number to a SIM they control, then receives the SMS codes. This one is specific to text-message MFA, which is exactly why text messages are the weakest factor still in common use.

The accounts that never got MFA. Service accounts, shared mailboxes, admin portals, that one legacy application nobody owns. In the Snowflake-related breaches of 2024, attackers used accounts where MFA was available and simply had not been switched on. Coverage gaps are not sophisticated. They are just common.

What actually resists these attacks

There is a real answer here, and it is more specific than "use MFA."

Phishing-resistant factors. FIDO2 security keys and passkeys are cryptographically bound to the website they were registered with. A proxy on a lookalike domain cannot complete the handshake, no matter how convincing the page looks. This defeats adversary-in-the-middle and real-time code relay outright — not by detection, but by design. It also eliminates push bombing, because there is no push to approve.

If you take one thing from this article: move your highest-risk accounts to passkeys or hardware keys. Executives, finance, IT administrators, anyone who can move money or change permissions.

Kill basic authentication. Disable legacy protocols across your tenant and monitor for attempts to use them. This closes an entire category with a single configuration change.

Harden the reset process. Require out-of-band verification before any MFA reset. Manager approval for sensitive accounts. A callback to a number on file rather than the one the caller is using. Train the help desk that being unhelpful for ninety seconds is an acceptable cost.

Retire SMS where you can. Any authenticator app is better. A hardware key is better still.

Watch the session, not just the login. Because no authentication factor prevents token theft after the fact, detection has to happen downstream. Impossible travel. A session appearing from a new country minutes after a normal login. A mail forwarding rule created at 3am. Shortening token lifetimes and re-authenticating for sensitive actions also narrows the window considerably.

The honest summary

MFA remains one of the best controls available. Nothing above is an argument for turning it off, and a business with MFA everywhere is dramatically safer than one without.

But there is a meaningful difference between having MFA and having MFA that would survive a targeted attempt. The gap usually lives in three places: text-message codes still in use, legacy protocols still enabled, and a help desk that has never been told to say no.

Those are all fixable, and none of them require new spending. If you are not sure which apply to you, that is the kind of thing a Secure Start assessment answers in a week.