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 against NIST SP 800-63B-4 and CISA guidance, maps the bypass techniques attackers use, and sets out how to move administrators, the workforce and customers to phishing-resistant authentication without locking anyone out. It is written for identity architects, security operations teams and the owners of sign-in journeys.

Key takeaways

Phishing resistance is the property that matters. NIST says authenticators that need manual entry of a code "SHALL NOT be considered phishing-resistant"; FIDO2 passkeys, security keys and smart cards bind the response to the genuine site.
Most bypasses target the process around MFA. Push fatigue, help desk resets, weak enrolment, legacy protocols, exclusions and stolen session tokens all avoid the strong factor rather than break it.
Roll out by risk. CISA suggests starting with IT administrators and the help desk, then remote access, email and the identity provider, then everyone else.
MFA protects the sign-in, not the session. Pair it with bounded session lifetimes, re-authentication for sensitive actions and detection of token replay.
Non-human identities cannot do MFA. Protect service accounts, workloads and AI agents with federated, short-lived and scoped credentials instead of exempting them and moving on.

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. NIST is explicit that a biometric "is not recognized as an authenticator by itself": it must be paired with a physical authenticator, and local biometric checks that unlock a device-held key are preferred over central comparison.

NIST SP 800-63B-4 describes authentication in terms of authenticator assurance levels (AALs):

AAL2: proof of possession and control of two distinct factors, at least one of them replay-resistant. Verifiers "SHALL offer at least one phishing-resistant authentication option at AAL2", and US federal agencies must require phishing-resistant authentication for staff, contractors and partners.
AAL3: a cryptographic authenticator with a non-exportable private key that provides phishing resistance, plus an activation factor or password.
Session limits: at AAL2 NIST says re-authentication should happen at least every 24 hours, with an inactivity timeout of no more than one hour; at AAL3 the overall limit is 12 hours.

NIST recognises two ways to achieve phishing resistance. Channel binding ties the authenticator output to the TLS channel, as client-authenticated TLS does; verifier name binding ties it to the site's domain name, which is how WebAuthn and FIDO2 work. NIST rates channel binding as the stronger of the two, but both meet the requirement.

MFA methods compared

Method	How it works	Phishing resistant?	NIST SP 800-63B-4 position	Main weaknesses
SMS or voice one-time code	Code sent to a phone number	No	Restricted authenticator; extra conditions and a migration plan required	SIM swap, number porting, SS7 interception, real-time relay
Email one-time code or link	Code or link sent to an inbox	No	Not phishing resistant (manual entry)	Depends on the mailbox; relayable
Authenticator app code (TOTP)	Time-based code from a shared secret	No	Usable at AAL2; not phishing resistant	Real-time relay; seed theft from backups
Push notification	Approve or deny in an enrolled app	No	Out-of-band; not phishing resistant	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	Out-of-band; not phishing resistant	Still relayable through a proxy page; blocks blind approvals
Synced passkey	FIDO2 key pair bound to the site, copied between devices by a sync fabric	Yes	Exportable key: usable at AAL2, not AAL3	Security depends on the sync account
Device-bound passkey or security key	FIDO2 key pair held in hardware	Yes	Can meet AAL3 with a non-exportable key	Device loss; needs a recovery plan
Smart card or certificate-based authentication	Private key on a card or TPM, verified by certificate	Yes, when properly configured	Can meet AAL3	Certificate lifecycle overhead; middleware

CISA's fact sheet orders MFA forms from strongest to weakest: phishing-resistant FIDO/WebAuthn and PKI-based MFA first, then app-based codes and push with number matching, then push without number matching, with SMS and voice last: CISA says this form "should only be used as a last resort MFA option". CISA calls FIDO/WebAuthn "the only widely available phishing-resistant authentication". FIDO2 is 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, so a look-alike domain cannot get a valid signature. See the Passwordless and Passkeys Guide and the Hardware Security Keys Guide.

How attackers bypass MFA

Technique	MITRE ATT&CK	What stops it
Push fatigue and bombing	T1621 Multi-Factor Authentication Request Generation	Number matching, prompt limits, phishing-resistant methods
Adversary-in-the-middle phishing proxy	T1557 Adversary-in-the-Middle, T1539 Steal Web Session Cookie	FIDO2 or certificate-based authentication; device-bound sessions
Code interception (SIM swap, SS7, malware)	T1111 Multi-Factor Authentication Interception	Retire SMS for the workforce; risk checks on SIM change
Rogue MFA device enrolment	T1098.005 Device Registration	Strong-factor gate on registration; alerts on new methods
Disabling or modifying MFA after compromise	T1556.006 Modify Authentication Process: Multi-Factor Authentication	Protect MFA policy changes as privileged actions; alert on change

Push fatigue and bombing: CISA describes attackers with a stolen password generating "hundreds of prompts" until the user accepts one. In the Cisco Breach 2022, voice phishing and push fatigue got the attacker onto the VPN, after which it enrolled new MFA devices. In the Uber Breach 2022, repeated prompts wore a contractor down until one was accepted.
Adversary-in-the-middle (AiTM) phishing: a proxy relays the password and code, then keeps the session cookie; MITRE names Evilginx2 and Muraena as open source frameworks for this. In the Twilio Breach 2022, staff received texts linking to fake sign-in pages. See the AiTM Phishing Guide.
SIM swap and SS7: CISA notes attackers convince carriers to move a number to their SIM, or exploit SS7 to receive SMS and voice codes. See the SIM Swap Fraud Guide.
Help desk reset: the attacker impersonates the user and asks for MFA to be reset. In the MGM Resorts Breach 2023, attackers reportedly called the IT help desk posing as an employee. See the Account Recovery and Help Desk Security Guide.
Session token theft: infostealers and appliance flaws take the cookie issued after MFA. CitrixBleed 2023 leaked valid session cookies from memory, and patching did not revoke sessions already stolen. See the Token and Session Security Guide and the Infostealer Threat Guide.
Legacy protocols and exclusions: basic authentication, service accounts and test accounts that skip MFA. The Microsoft Midnight Blizzard Breach 2024 began with a password spray against a legacy test account without MFA.
No MFA at all on one path: in the Change Healthcare Breach 2024, UnitedHealth's CEO told Congress the remote access portal "did not have multifactor authentication". In the Colonial Pipeline Ransomware Attack 2021, an unused VPN account without MFA was the way in. In the Snowflake Breach 2024, Mandiant named missing MFA as one of three gaps behind the campaign.

For a deeper treatment of each bypass, see the MFA Fatigue and Bypass Guide.

Designing an MFA programme

Choose methods by risk

Administrators, privileged users and break-glass operators: hardware security keys, device-bound passkeys or smart cards only. CISA names system administrators and other high-value targets as the first group to move.
Help desk and IT staff: include them in the first phase, as CISA suggests, because they can reset everyone else's factors.
Remote access, email and the identity provider: phishing-resistant methods as the target, number-matched push as an interim minimum. CISA describes number matching as "one of the best interim" mitigations, not an end state.
General workforce: passkeys on managed devices, with a defined fallback for people who cannot use them. The US OMB memorandum M-22-09 requires federal agencies to stop supporting SMS, voice, one-time codes and push for routine self-service staff access.
Customers: offer passkeys, keep SMS only as a fallback with risk checks, and use step-up for sensitive actions. M-22-09 requires agencies to make phishing-resistant MFA an option for public users. 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, APIs and data platforms that authenticate on their own. OWASP warns that a separate login API is a commonly missed path. See the Conditional Access Guide.
Escalate what cannot do MFA: CISA recommends a plan to upgrade or replace systems without MFA support, and escalating the risk of any that remain to senior leadership.
Block legacy authentication that cannot carry MFA.
Protect enrolment: NIST requires that binding a new authenticator needs authentication at the maximum AAL available on the account or the AAL the new authenticator will be used at, whichever is lower. Use a time-limited onboarding credential for first registration, and notify the user out of band whenever a factor changes, as OWASP recommends.
Harden recovery: OWASP notes that account recovery "is just an alternate way to authenticate so it should be no weaker than regular authentication".
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. Microsoft now applies number matching to all Authenticator push notifications.

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 after an incident, and detect the same session used from two places. Platforms are also raising the floor: Microsoft has made MFA mandatory for Azure portal and admin centre sign-ins since October 2024, and from 1 October 2025 began enforcing it for Azure CLI, PowerShell, infrastructure-as-code tools and REST API create, update and delete operations.

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 OWASP Non-Human Identities Top 10 lists insecure authentication (NHI4) and long-lived secrets (NHI7) among the main NHI risks, and human use of NHIs (NHI10) as a way accountability is lost. The answer is not to force MFA onto workloads but to remove the password-like secret:

Use workload identity federation and managed identities instead of static keys. See the NHI Authentication 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.
Check how platform MFA mandates treat automation: plan workload identities for scripts that ran under user accounts before enforcement reaches them.
AI agents acting for users should use delegated, scoped tokens, with human approval for high-impact actions, rather than borrowed user sessions or cookies. A phishing-resistant sign-in by the user does not make an agent holding that user's session safe. See the AI Agent Authorisation Guide.

Signs your MFA is not working

Signal	Likely cause	Response
Clusters of denied pushes followed by an approval	Push bombing	Revoke sessions, reset password, contact the user out of band
New MFA method registered shortly after a password reset or from an unusual location	Enrolment hijack or rogue device	Remove the method, verify the user, review recent activity
Successful sign-ins over protocols or applications that bypass MFA	Legacy authentication or an unprotected path	Block the protocol; bring the app behind the identity provider
The same session token used from different devices or countries	Cookie theft or AiTM	Revoke tokens; investigate the endpoint for infostealers
MFA policy or exclusion changed outside change control	Attacker persistence or drift	Revert and investigate who made the change
Help desk MFA resets rising without more lost devices	Social engineering of the help desk	Tighten caller verification; review recent resets

A growing list of MFA exclusions nobody owns is a signal too, even though no alert will fire for it.

Common failure patterns

MFA counted, not measured: coverage reported as "MFA enabled" with no split by method, so SMS and push are treated the same as passkeys.
One unprotected door: a VPN profile, remote access portal or data platform outside the identity provider, as in Change Healthcare and Colonial Pipeline.
Push without context: plain approve or deny prompts that train users to tap "approve", the pattern in the Uber and Cisco incidents.
Strong sign-in, weak reset: phishing-resistant methods for daily use, but a help desk that resets them after a convincing phone call.
Open enrolment: anyone with a password can register a new device, which turns a stolen password into permanent MFA.
Exclusions that become permanent: migration, location and service account exemptions that are never reviewed.
Sessions that outlive the risk: long-lived cookies and refresh tokens that keep working after a password reset or patch, as CitrixBleed showed.

Framework mapping

This is an indicative NHI Mgmt Group alignment, not an official crosswalk. Control IDs were checked against NIST CSF 2.0, the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls v8.1 control list and a published ISO/IEC 27001:2022 Annex A index; CIS is mapped at control level.

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP NHI Top 10
MFA for privileged and standard accounts	PR.AA-03	IA-2(1), IA-2(2)	8.5 Secure authentication	6	n/a
Phishing-resistant, replay-resistant methods	PR.AA-03	IA-2(8), IA-5(2)	8.5 Secure authentication	6	n/a
Authenticator enrolment, reset and lifecycle	PR.AA-01, PR.AA-02	IA-5	5.17 Authentication information	5, 6	n/a
Session management after MFA	PR.AA-04	AC-12, SC-23	8.5 Secure authentication	6	n/a
Non-human identity authentication	PR.AA-01, PR.AA-03	IA-9, IA-5	5.17 Authentication information	5	NHI4, NHI7, NHI10
Monitoring MFA events and changes	DE.CM-03	AU-6, SI-4	8.15 Logging, 8.16 Monitoring activities	8	n/a
User awareness of push bombing and phishing	PR.AT-01	AT-2(3)	6.3 Information security awareness, education and training	14	n/a

Metrics that show progress

Metric	What it shows	Target direction
Privileged accounts using phishing-resistant methods only	Protection of the highest-value targets	100%
Workforce sign-ins completed with phishing-resistant methods	Progress of the migration	Up
Accounts whose only second factor is SMS or voice	Exposure to SIM swap and SS7	Down, towards zero for the workforce
Sign-in paths and applications without enforced MFA	Unprotected doors	Zero
Active MFA exclusions, and the share with an owner and expiry	Exception hygiene	Fewer; 100% owned
Help desk MFA resets per month, and the share verified by a strong method	Social engineering exposure	Stable count; verification up
Interactive sign-ins by service accounts	Human use of NHIs	Zero

Implementation roadmap

Phase	Focus	Actions
First 30 days	Cover every door	Inventory sign-in paths; enforce MFA on remote access, email and the identity provider; block legacy authentication; turn on number matching and prompt limits; list every exclusion with an owner
Days 31 to 90	Protect the high-value accounts	Issue security keys or device-bound passkeys to administrators, help desk and IT staff; require a strong factor to register new methods; tighten help desk verification for MFA resets
Days 91 to 180	Move the workforce	Roll out passkeys on managed devices; set a date to retire SMS for staff; bound session lifetimes and alert on token replay; replace interactive service account use with workload identities
Ongoing	Sustain and extend	Offer passkeys to customers; review exclusions quarterly; report method mix, not just coverage; test recovery and reset processes against social engineering

For common rollout errors, see the Top 10 MFA Mistakes.

Practitioner checklist

Inventory every sign-in path, including VPNs, APIs, data platforms, legacy protocols and local accounts, and confirm MFA enforcement on each.
Require hardware security keys, device-bound passkeys or smart cards for administrators, help desk and privileged roles.
Turn on number matching and prompt limits for push, and set a date to retire SMS for the workforce.
Require an existing strong factor or a time-limited onboarding credential to register a new MFA method, and notify users of every change.
Verify callers with a strong method before any help desk MFA reset, especially for privileged users.
Block legacy authentication and give every MFA exclusion an owner and an expiry date.
Bound session lifetimes, revoke sessions after incidents and alert on token replay.
Treat changes to MFA policy as privileged actions and alert on them.
Replace static secrets for NHIs with federated, short-lived credentials rather than exempting them from MFA.
Report MFA by method strength, not just coverage.

MFA Guide: Methods, Phishing Resistance and Bypass Techniques