MFA Guide: Methods, Phishing Resistance and Bypass

Multi-factor authentication stops most password-based attacks, but not all MFA is equal and attackers now routinely get past the weaker kinds. An SMS code, an app push and a passkey all count as "MFA" on a compliance checklist, yet they fail in very different ways. SMS can be intercepted through SIM swap, push approvals can be spammed until a tired user accepts one, and one-time codes can be relayed in real time by a phishing proxy that also steals the session. This guide compares MFA methods, explains how MFA is bypassed, and sets out how to move people, privileged users and customers to phishing-resistant authentication without locking anyone out.

Key takeaways

Phishing resistance is the property that matters. Methods that bind authentication to the genuine site, such as FIDO2 passkeys, security keys and smart cards, defeat real-time phishing. Codes and pushes do not.
Most MFA bypasses target the process around MFA: fatigue, help desk resets, weak enrolment, legacy protocols and stolen session tokens after sign-in.
Roll out phishing-resistant MFA by risk: administrators and privileged users first, then remote access, then everyone.
MFA protects the sign-in, not the session. Pair it with short, bound sessions and detection of token replay.
Non-human identities cannot use MFA. Protect them with workload identity, short-lived credentials and scoping instead.

What counts as a factor

MFA combines evidence from at least two categories: something you know (a password or PIN), something you have (a phone, security key or smart card) and something you are (a biometric). Two passwords are not MFA, and a biometric that only unlocks a device key is used to activate the "something you have" factor rather than being sent to the server. NIST SP 800-63B-4 describes authentication in terms of authenticator assurance levels (AALs): AAL2 requires two factors, and AAL3 requires a hardware-backed, phishing-resistant authenticator with a non-exportable key.

MFA methods compared

Method	How it works	Phishing resistant?	Main weaknesses
SMS or voice one-time code	Code sent to a phone number	No	SIM swap, number porting, SS7 interception, real-time relay, social engineering of the code
Email one-time code or link	Code or link sent to an inbox	No	Depends on the security of the mailbox; relayable
Authenticator app code (TOTP)	Time-based code generated from a shared secret	No	Real-time relay by phishing proxies; seed theft from backups
Push notification	Approve or deny on an enrolled app	No	Push fatigue and bombing; approval without context
Push with number matching	User types a number shown on the sign-in page into the app	No, but stronger	Still relayable if the user is on a proxy page; blocks blind approvals
Passkey (synced)	FIDO2 key pair bound to the site, synced by a platform provider	Yes	Security depends on the sync account; not permitted at AAL3
Passkey (device-bound) or security key	FIDO2 key pair held in hardware, never leaves the device	Yes	Loss of the device; needs a recovery plan
Smart card or certificate-based authentication	Private key on a card or TPM, verified by certificate	Yes, when properly configured	Certificate lifecycle overhead; middleware complexity

FIDO2 authenticators are phishing resistant because the browser tells the authenticator which site is asking, and the key pair only works for the site it was registered with. A look-alike domain simply cannot get a valid signature. See the Passwordless and Passkeys Guide for rollout detail.

How attackers bypass MFA

Push fatigue and bombing: repeated push prompts until the user approves one, often combined with a phone call pretending to be IT. This featured in the Cisco 2022 breach.
Adversary-in-the-middle (AiTM) phishing: a proxy sits between the user and the real site, relays the password and one-time code, and captures the session cookie that results. The Twilio and 0ktapus campaign used fake sign-in pages to relay codes at scale.
SIM swap: the attacker persuades a mobile carrier to move the victim's number, then receives SMS codes and recovery messages.
Help desk reset: the attacker calls the help desk, impersonates the user and asks for MFA to be reset or a new device enrolled. See the Account Recovery and Help Desk Security Guide.
Enrolment hijack: an attacker with a stolen password registers their own MFA device before the real user does, or adds a second device after compromise.
Session token theft: infostealers and exploits take the session cookie issued after MFA, so the attacker never has to authenticate. CitrixBleed leaked valid sessions directly from appliances. See the Token and Session Security Guide.
Legacy protocols and exclusions: basic authentication, older mail protocols, service accounts and "trusted" locations that skip MFA entirely. The Midnight Blizzard breach began with a password spray against a legacy test account without MFA.
No MFA at all on one path: a single remote access portal or data platform without enforced MFA undoes the rest. The Change Healthcare, Colonial Pipeline and Snowflake incidents all involved accounts without MFA.

Designing an MFA programme

Choose methods by risk

Administrators, privileged users and break-glass operators: hardware security keys or device-bound passkeys only. See the Privileged Access Management Guide.
Remote access, email and the identity provider: phishing-resistant methods as the target, number-matched push as an interim minimum.
General workforce: passkeys on managed devices, with a defined fallback for people who cannot use them.
Customers: offer passkeys, keep SMS only as a fallback, and use risk-based step-up for sensitive actions. See the Customer IAM (CIAM) Guide.

Close the gaps around MFA

Enforce everywhere: apply MFA through the identity provider with conditional access, and find applications, VPNs and data platforms that authenticate on their own.
Block legacy authentication that cannot carry MFA.
Protect enrolment: require an existing strong factor or identity verification to add a new MFA method, and alert on new registrations.
Harden recovery: MFA is only as strong as the process for replacing a lost factor.
Remove blanket exclusions for locations, groups and "temporary" exceptions, and review the ones that remain.
Rate-limit prompts: cap push requests, use number matching and show sign-in context (application, location) in the prompt.

Protect what MFA produces

A successful MFA sign-in issues tokens and cookies. Keep session lifetimes proportionate to risk, bind sessions to devices where supported, revoke sessions when risk changes, and detect the same session used from two places. The Identity Provider and SSO Security Guide covers IdP-side controls.

MFA and non-human identities

Service accounts, API keys and workloads cannot respond to a push or tap a security key, which is why they are often excluded from MFA policies and then targeted. The answer is not to force MFA onto them, but to remove the password-like secret:

Use workload identity federation and managed identities instead of static keys. See the NHI Authentication Guide and the Cloud Workload Identity Guide.
Where a secret is unavoidable, restrict where it can be used from, keep it short-lived and store it in a vault.
Stop people signing in interactively as service accounts, and monitor for it. See the Service Account Security Guide.
AI agents acting for users should use delegated, scoped tokens, with human approval for high-impact actions rather than borrowed user sessions. See the AI Agent Authorisation Guide.

Signs your MFA is not working

Clusters of denied pushes followed by an approval.
New MFA methods registered shortly after a password reset or from an unusual location.
Successful sign-ins over protocols or applications that bypass MFA.
The same session token used from different devices or countries.
A growing list of MFA exclusions nobody owns.
Help desk MFA resets rising without a matching rise in lost devices.

Practitioner checklist

Inventory every sign-in path, including VPNs, data platforms, legacy protocols and local accounts, and confirm MFA enforcement on each.
Require hardware security keys or device-bound passkeys for administrators and privileged roles.
Turn on number matching and prompt limits for push, and set a date to retire SMS for the workforce.
Protect MFA enrolment and re-registration with an existing strong factor or identity verification.
Verify callers properly before any help desk MFA reset, especially for privileged users.
Block legacy authentication and review every MFA exclusion.
Shorten and bind sessions, and alert on token replay.
Replace static secrets for NHIs with federated, short-lived credentials rather than trying to apply MFA to them.

MFA Guide: Methods, Phishing Resistance and Bypass Techniques