The thing MFA actually protects
Multi factor authentication verifies identity at the moment of login and issues a session on success.
Almost every technique that defeats it in practice works by not engaging with that moment. The attacker either takes the output rather than attacking the process, or arranges for the legitimate user to authenticate on their behalf, or changes the authenticator rather than defeating it.
This is why arguments about which MFA method is strongest are only partially useful. For one attack, the choice of method is decisive. For most of the others, it makes no difference at all.
The techniques
Adversary in the middle phishing. The attacker operates a proxy between the victim and the genuine service. The victim sees a convincing login page, enters their credentials, completes whatever MFA challenge is presented, and the proxy relays everything in real time to the real service. The session token issued on success is captured. The victim is usually forwarded to the real site afterwards and notices nothing.
This is the one attack where authenticator choice is decisive.
Session token theft by malware. Infostealer malware copies the browser's cookie store from an infected device. No phishing, no interaction, no authentication attempt. The attacker imports a session cookie and resumes a session that was legitimately established by the real user with whatever MFA you deployed.
MFA fatigue, or push bombing. The attacker holds valid credentials and triggers repeated push approvals until the user accepts one, out of confusion or to stop the notifications. Number matching, where the user must type a number displayed on the login screen, addresses this specific attack well.
SIM swapping. Transferring the victim's phone number to an attacker controlled SIM, which delivers SMS codes and recovery messages to the attacker.
OAuth consent phishing. The user is induced to grant a malicious application permission to their account. They authenticate at the genuine origin, with the real authenticator, and then consent. The application holds its own token thereafter, independent of the user's password or MFA.
Device code phishing. The attacker initiates a device authorisation flow and persuades the victim to enter the resulting code at the legitimate sign in page. Again the origin is genuine, so origin binding offers no protection.
Helpdesk and account recovery social engineering. Persuading support staff to reset a credential or enrol a new authenticator. No technical control is engaged. This route has grown notably.
Fallback method exploitation. Steering the victim toward a weaker authentication method that remains enabled on the account.
Which method resists what
This is the part worth being precise about. Derived from what each authenticator does at the protocol level rather than from vendor positioning.
SMS or voice one time codes. Resist nothing on this list except pure credential replay. Relayed trivially by a proxy, interceptable by SIM swap. NIST classifies the public telephone network as a restricted authenticator, specifically citing SIM change and number porting risk.
TOTP authenticator apps. Resist SIM swapping, since there is no phone number involved. Do not resist a proxy, because the code is entered into the attacker's page and relayed within its validity window.
Plain push approval. Resists SIM swapping. Does not resist a proxy. Uniquely vulnerable to push bombing, because approving is a single tap with no context.
Number matched push. Resists SIM swapping and substantially addresses push bombing, since the user must read a number from the screen they are actually looking at. Still does not resist a proxy, which can display the number to the victim.
Device bound FIDO2 security key. Resists proxies, phishing, SIM swapping and push bombing. The credential is bound to the origin it was registered against and the authenticator will not release it to a different one. A lookalike domain receives nothing, regardless of how convincing the page is.
Platform passkey, device bound. Same resistance properties as above.
Syncable passkey. Same resistance to proxies, with a different risk profile: the private key must be exportable in order to sync, which is why NIST states syncable authenticators shall not be used at the highest assurance level. The security of the account becomes partly the security of the sync fabric.
And the row that matters most. Token theft, OAuth consent abuse, device code phishing and helpdesk social engineering are resisted by none of the above. Not by security keys, not by passkeys, not by anything. In each case the attacker either takes the result of a successful authentication or arranges one through a legitimate channel.
Why origin binding works
Worth explaining, because it is the one genuine improvement and the mechanism is elegant.
When a FIDO2 credential is created, it is scoped to the relying party's identifier, meaning the site's domain. When authentication is requested, the browser includes the actual origin of the page in the data that gets signed, and the relying party verifies that the origin matches what it expects.
A proxy on a lookalike domain therefore fails in two independent ways. The authenticator will not produce an assertion for an origin the credential was not registered against, and even if something were produced, the signed origin would not match and the server would reject it.
The user cannot be fooled into overriding this, which is the point. Every other method depends on the user correctly judging that the page is genuine. This one does not ask them.
One honest note on sourcing: the specification does not contain a single sentence declaring that this prevents phishing. The property is emergent from the origin scoping and signing requirements rather than stated as a headline claim.
The limitation nobody markets
Phishing resistant authentication protects the act of authenticating. It does not protect what is issued afterwards.
Once a session exists, it is a token. Malware on the device can copy it. An attacker holding it is not authenticating at all, so the authenticator is not consulted, and the fact that it was a hardware key rather than an SMS code is irrelevant.
This is why session revocation capability and exposure monitoring matter alongside authentication strength, and why the two are not substitutes. We could not find a credible primary measurement of what proportion of MFA bypasses occur this way. Vendor figures circulate without denominators. The mechanism is well documented, the share is not.
The fallback problem
An estate is only as phishing resistant as its weakest enabled method.
Researchers have documented attacks that rewrite the login interface in the victim's browser to hide the passkey option and present a phishable alternative instead. If SMS is still enabled as a backup, an attacker can steer the user to it.
The practical obstacles to removing weaker methods are real. Some SaaS applications do not support modern authentication or federation. MFA enrolment is frequently additive, so users accumulate methods rather than replacing them. Accounts created before a policy change retain old configurations. Service accounts and legacy clients need app passwords, which bypass interactive authentication entirely.
Survey data from April 2026 covering 1,400 enterprises found 68 percent deploying passkeys, only 28 percent fully passwordless, and 57 percent still using a phishable method as their primary authentication. Deployment is not the same as adoption, and adoption is not the same as removal of the alternatives.
The scale of the commodity attack
Adversary in the middle phishing is not an advanced capability. It is a subscription product.
Analysis covering January to April 2025 documented phishing as a service kits sold for roughly 100 to 1,000 dollars a month, with individual kits serving 150 to 250 customers each, approximately 220 to 280 active servers observed, and kit updates shipping weekly.
The operator needs no technical skill. They need a subscription and a list of targets.
What to do, in order
Deploy phishing resistant authentication for administrative accounts first, then broadly. It is the only control that addresses the proxy attack.
Then remove the alternatives. This is the step that gets skipped, and without it the first step is substantially undone.
Restrict OAuth application consent so users cannot grant access to arbitrary applications. This addresses a category that no authenticator touches.
Harden the helpdesk. Documented identity verification for credential and authenticator changes, ideally something stronger than information an attacker could find. This is also a category no authenticator touches.
Build session revocation capability and know where the control lives on each critical system before you need it.
Monitor for exposure, because when a session token is stolen from a device you do not manage, your own telemetry will show you nothing. See stealer log monitoring.
Alert on authentication method changes. A new authenticator being registered is rare, consequential, and far more often attacker behaviour than user behaviour.