Can phishing bypass MFA?

The short answer

Multi-factor authentication remains one of the highest-value controls you can deploy. It ends credential stuffing, it ends password reuse as an attack path, and it forces an attacker to work in real time rather than at leisure with a leaked database. None of that is in question.

What is in question is the belief that enabling MFA closes phishing. It does not. The distinction that matters is between a factor that produces a shared secret - something the user reads and retypes, or a button they press - and a factor that produces a signature bound to a specific web origin. The first kind can be relayed. The second cannot.

The four routes attackers use

Four techniques account for nearly all real-world MFA defeat. They differ in effort and in what they leave behind, but all four end with the attacker holding valid access.

• Real-time relay. The phishing page is a reverse proxy that forwards every field to the genuine service and steals the session cookie once login succeeds. This is adversary-in-the-middle phishing, and it is now the default technique rather than an advanced one.
• Prompt fatigue. The attacker already has the password and simply requests authentication repeatedly until the victim approves a prompt to stop the noise, often helped along by a fake helpdesk call. This is MFA fatigue.
• SMS interception. A SIM swap moves the victim's number to an attacker-controlled device, after which every text-message code arrives on the wrong phone. This route needs no interaction from the victim at all.
• Token theft from the endpoint. Malware on a compromised device copies session cookies and refresh tokens straight out of the browser profile, skipping authentication entirely because the authentication already happened.

Notice that only the first two involve the victim doing anything wrong, and in both cases what they did looked entirely reasonable at the time. Training helps at the margins here, but any plan that rests on users never making a mistake under time pressure is a plan that will eventually fail.

What actually holds

Passkeys and FIDO2 security keys resist every phishing route above. When you register one, the authenticator ties the credential to the site's origin. Presented with a login challenge from a lookalike domain, it will not produce a valid signature - not because it detects fraud, but because the domain does not match and there is nothing valid to produce. There is also no code displayed anywhere, so there is nothing for a caller to talk the user into reading out.

Be precise about the claim, though. Phishing-resistant does not mean unbreakable. It means the phishing page cannot make the browser sign for a domain it is not on. Malware already running on the device, a weak account-recovery flow, or a helpdesk that will enrol a new authenticator for anyone who calls all remain open, and attackers move to exactly those routes once the credential itself stops giving. Recovery and enrolment are where phishing-resistant deployments usually fail in practice.

• Pair phishing-resistant credentials with conditional access on device compliance, so a stolen token replayed from an unmanaged machine fails anyway.
• Shorten session lifetimes and enable continuous access evaluation, so revocation takes effect promptly rather than whenever the token happens to expire.
• Harden the recovery path. An account that can be reset by a phone call to the service desk is protected by that phone call, not by its authenticator.
• Remove SMS as a fallback once stronger methods are enrolled, because an attacker will always choose the weakest method you still accept.

What to do now

A practical order of work for an administrator who has MFA switched on and wants to know where the real gaps are.

1. Inventory which methods are actually registered across your users, rather than which ones your policy permits. The two are rarely the same.
2. Turn on number matching wherever push notifications are still in use. It is a single setting and it closes the prompt-fatigue route.
3. Roll out passkeys or security keys to administrators and finance staff first - the accounts where a single compromise turns into money leaving the company.
4. Set a date to stop accepting SMS as a second factor, and treat it as a real deadline rather than an aspiration.
5. Add detection for a burst of denied MFA challenges on one account, which is the one signal that fires before a compromise rather than after it.
6. Test the recovery and enrolment path yourself. Call your own service desk and see how much it takes to get a new authenticator registered.

Someone who has already approved a prompt or entered a code on a suspicious page should follow the steps in I clicked a phishing link immediately, and the surrounding control set is covered in phishing tests for employees.