Passwordless vs Phishing-Resistant MFA: Which Methods Really Stop Phishing

"Passwordless" describes what the user no longer types; "phishing-resistant" describes what an attacker can no longer relay, and many passwordless methods give you the first without the second. A magic link, an SMS code used as the only login step, or an approve-on-your-phone prompt all remove the password, yet each still hands a usable secret or approval to whoever builds a convincing fake sign-in page. Programmes that report "we went passwordless" can therefore leave adversary-in-the-middle phishing fully open. This guide is for identity architects, IAM engineers and security leads writing authentication policy. It sorts common passwordless methods by whether they meet the NIST definition of phishing resistance, explains why, and shows how to express the difference in access policy, exceptions and recovery. For the programme view of phishing-resistant MFA, see the Phishing-Resistant MFA Guide; for how passkeys work, the Passwordless and Passkeys Guide. Platforms are listed alphabetically.

Key takeaways

• The two labels answer different questions. Passwordless is about the user experience and removing a shared secret; phishing resistance is a protocol property defined in NIST SP 800-63B-4 section 3.2.5.
• Manual entry and approval are the dividing line. NIST states that authenticators involving manual entry of an output are not phishing-resistant; out-of-band and OTP methods are named. Magic links, SMS or email codes, and push approvals all fall on the wrong side.
• Only two mechanisms qualify. Verifier name binding (WebAuthn and FIDO2, including passkeys) and channel binding (client-authenticated TLS, as used by PIV and CAC). Everything else is, at best, phishing-reduced.
• Policy must name the property, not the label. Identity providers ship separate policy objects for "passwordless" and "phishing-resistant"; choosing the wrong one silently allows phishable methods.
• Recovery decides the real assurance. A phishing-resistant sign-in backed by an SMS or email recovery path is only as strong as that path.

Short answer

Every phishing-resistant authenticator in common use is also passwordless capable, but not every passwordless method is phishing-resistant. If your goal is to stop credential phishing and real-time relay, set policy to require phishing-resistant methods (FIDO2 security keys, passkeys, device-bound platform authenticators, smart cards or certificate-based authentication). Treat other passwordless methods, such as magic links, one-time codes and push sign-in, as convenience or interim options with a documented risk, never as the target state for workforce or privileged access.

Definitions that matter

Phishing resistance (NIST SP 800-63B-4, section 3.2.5): the ability of the authentication protocol to prevent the disclosure of authentication secrets to an impostor verifier without relying on the vigilance of the claimant. It requires single-factor or multi-factor cryptographic authentication and is achieved by one of two mechanisms:

• Verifier name binding: the output is cryptographically bound to the verifier's authenticated identifier, for web sign-in the DNS hostname or a parent domain at least one level below the public suffix. WebAuthn, used by FIDO2 authenticators, is NIST's example. A look-alike domain receives nothing it can use at the real site.
• Channel binding: an identifier of the authenticated protected channel is irreversibly bound to the authenticator output, for example by signing both with the claimant's private key. Client-authenticated TLS is the example, and NIST notes that PIV and CAC cards provide phishing resistance this way. NIST considers channel binding the more secure of the two because it is not vulnerable to misissued or misappropriated verifier certificates.

Passwordless: not a NIST term of art. In product and policy language it means sign-in without a memorised secret, using a possession factor, often unlocked locally with a biometric or PIN. It says nothing about whether the possession factor's output can be relayed.

NIST is explicit about the methods that fail: passwords, look-up secrets, out-of-band authentication and OTP authentication are each stated to be not phishing-resistant, and section 3.2.5 says authenticators involving the manual entry of an output shall not be considered phishing-resistant because manual entry does not bind the output to the session.

Passwordless methods sorted by phishing resistance

CISA's fact sheet "Implementing Phishing-Resistant MFA" reaches the same split: it calls FIDO/WebAuthn the only widely available phishing-resistant authentication and PKI-based MFA a less widely available form, while app-based OTP, push with or without number matching, and SMS or voice are all susceptible to phishing, with SMS and voice to be used only as a last resort.

Option in depth: passwordless that is not phishing-resistant

Threat model it fits: mass credential stuffing and password reuse. Removing the password removes the reusable secret, so breach corpora and spraying lose value. It does not address targeted phishing, adversary-in-the-middle kits or social engineering of the approval step.

Architecture in words: the service sends a secret or prompt over a second channel (email, SMS, push), and the user proves control of that channel by clicking, typing or approving. The service has no cryptographic proof of which site the user was looking at when they did so.

Failure modes:

• Relay: an adversary-in-the-middle page forwards the code or triggers the push in real time, then keeps the resulting session cookie. See the AiTM Phishing Guide.
• Approval fatigue and pretexting: repeated prompts until one is accepted. In the Uber Breach 2022 a contractor's password, believed bought after malware on a personal device, was followed by repeated approval prompts until the contractor accepted one. See the MFA Fatigue and Bypass Guide.
• Channel takeover: SIM swap or mailbox compromise gives the attacker the second channel itself, which makes the method single-factor in practice.
• Link scanners and forwarding: email security tools that prefetch links can consume or expose magic links, and users forward them. See the Magic Links and Email OTP Security Guide.

Controls that make it acceptable as an interim: number matching and location context on push; rate limits and short validity on codes and links; same-browser binding for magic links where the design allows; and session monitoring for replay. These lower risk but do not change the classification.

Option in depth: phishing-resistant authentication

Threat model it fits: credential phishing, real-time relay and prompt bombing. The authenticator will not produce a usable response for the wrong origin or channel, so the user's vigilance is no longer the control.

Architecture in words: the authenticator holds a private key; the relying party sends a challenge; the browser or TLS stack supplies the origin or channel identifier; the authenticator signs both after a local user gesture. A phishing proxy cannot obtain a signature valid for the real site.

Failure modes:

• Weak alternatives left on: policy accepts both FIDO2 and push, so the phishing kit simply requests push. This is the most common gap.
• Session theft after sign-in: phishing resistance protects the authentication ceremony, not the cookie it produces. Infostealers and token replay bypass it. See the Session Hijacking and Cookie Theft Guide.
• Phishable bootstrap and recovery: a first credential registered after a password and SMS check, or a help desk reset by phone, gives the attacker a phishing-resistant credential of their own.
• Side doors: legacy protocols and the device authorisation grant are not covered by WebAuthn origin binding. See the Device Code Phishing Guide.

Controls that make it work: require the phishing-resistant property in access policy; register first credentials through a verified process; make recovery at least as strong as sign-in; block legacy and device code flows where not needed; shorten and bind sessions.

What the mandates require

• OMB M-22-09 (26 January 2022): for US federal agency staff, contractors and partners, phishing-resistant MFA is required; for public users it must be an option. It names PIV, including derived PIV, and FIDO2 and WebAuthn authenticators, and requires agencies to discontinue support for methods that fail to resist phishing, such as SMS or voice, one-time codes and push notifications, for routine self-service access. See the OMB M-22-09 Federal Zero Trust Strategy Guide.
• NIST SP 800-63B-4: at AAL2, verifiers shall offer at least one phishing-resistant option, and federal agencies must require phishing-resistant authentication for staff, contractors and partners; at AAL3 a phishing-resistant authenticator is required and syncable authenticators shall not be used. Authentication intent should be shown at AAL2 and shall be shown at AAL3. See the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.
• Restricted authenticators: section 3.2.9 treats the public telephone network for out-of-band authentication as restricted: a provider using it must offer an unrestricted alternative, give subscribers notice of the risks and keep a migration plan.

Note what the mandates do not say: none treat "passwordless" as meeting the requirement. A passwordless push or magic-link deployment does not satisfy M-22-09 for workforce access.

Expressing the difference in identity provider policy

The trap is in the policy objects. Several identity providers ship a passwordless setting and a phishing-resistant setting side by side, and the names are easy to confuse. Platforms are listed alphabetically, each with the customer-side setting that enforces the property.

• Google Workspace: 2-Step Verification enforcement under Security, Authentication, 2-step verification offers the method options "Any", "Any except verification codes via text, phone call" and "Only security key". Google's documentation states that "Only security key" accepts both security keys and passkeys. Set it per organisational unit, starting with administrators. See the Google Workspace Security Guide.
• Microsoft Entra ID: Conditional Access authentication strengths include built-in "MFA strength", "Passwordless MFA strength" and "Phishing-resistant MFA strength". Microsoft's table shows Microsoft Authenticator phone sign-in in Passwordless MFA strength but not in Phishing-resistant MFA strength, which contains FIDO2 security keys, Windows Hello for Business or platform credential, and certificate-based authentication (multifactor). Require the phishing-resistant strength for the target population. See the Entra ID Security Guide.
• Okta: Okta's documentation names Passkey (FIDO2 WebAuthn) and Okta FastPass as phishing-resistant authenticators and describes app sign-in policies that require a phishing-resistant possession factor. Okta documents restrictions to plan for, such as some embedded WebView apps and a Safari SSO extension requirement on macOS. See the Okta Security Hardening Guide.

Whatever the platform, write the policy in terms of the property: "access to [resource] requires a phishing-resistant authenticator", then map that sentence to the platform's setting. The Authentication and MFA Policy Template gives wording.

Worked scenario: a passwordless programme that is not yet phishing-resistant

A 3,000-person company announces it is passwordless: staff sign in with push-based phone sign-in, contractors with email magic links, and the help desk resets lost phones by sending an SMS code. A red team runs an adversary-in-the-middle exercise.

The company was passwordless before and after. Only after the changes was it phishing-resistant, and the measure that proved it was the access policy, not enrolment numbers.

Rollout and recovery path

1. Inventory methods in use: export sign-in logs by authentication method for 30 days and classify each method against the table above.
2. Create the policy in report-only or audit mode: require the phishing-resistant property for administrators and help desk staff first, and review the sign-ins that would fail.
3. Register through a verified process: issue the first phishing-resistant credential after strong identity verification, not after an SMS code. The Help Desk Identity Verification Policy Template covers checks.
4. Enforce in rings: administrators, then high-risk roles, then all staff on managed devices, then contractors and BYOD.
5. Remove phishable alternatives: once a ring is enforced, disable push, OTP and SMS for that ring rather than leaving them as fallbacks.
6. Make recovery match: require a second phishing-resistant credential, or verified in-person or supervised video recovery, with a temporary credential that only allows registering a new authenticator. See Passkey account recovery.
7. Rollback: keep a dated, approved exception group for users blocked by hardware or app limits, recorded in the MFA Exception Register Template, and review it monthly.

Decision guidance

Small organisations can usually reach phishing-resistant sign-in for administrators in a week with two security keys each, and for staff through passkeys on existing devices. Large organisations are slowed by legacy applications, shared workstations and recovery; plan for an exception population and measure it down.

Detection and measurement

• Phishing-resistant enforcement coverage: percentage of users, and of privileged users, whose access policy requires the phishing-resistant property (not merely registered).
• Phishable sign-in share: percentage of successful sign-ins in 30 days that used a method from the "No" rows of the table.
• Exception count and age: users in the exception group and the median days they have been there.
• Recovery strength: percentage of recoveries completed through a phishing-resistant or verified in-person path.
• Method downgrade attempts: sign-ins that tried a phishable method for an enforced user, a useful phishing indicator in itself.

Common failure patterns

• Choosing the passwordless policy object: the "passwordless" strength or setting is enforced instead of the phishing-resistant one, so phone sign-in or push still passes.
• Reporting enrolment as coverage: dashboards count users with a passkey registered while policy still accepts every method.
• Phishable fallback: "Use another method" offers SMS or push to an enforced user, and the phishing kit picks it.
• Email as the recovery root: passkeys for sign-in, magic link for recovery, making the mailbox the real authenticator.
• Help desk resets by phone: a pretext call replaces the user's authenticator, as covered in the Vishing and Help Desk Social Engineering Awareness Guide.
• Ignoring sessions: treating phishing-resistant sign-in as the end of the problem while long-lived sessions remain stealable.

Framework mapping

Practitioner checklist

• Classify every sign-in method in use as phishing-resistant or not, using the NIST section 3.2.5 test.
• Rename internal targets from "passwordless" to "phishing-resistant" wherever the aim is to stop phishing.
• Enforce the phishing-resistant policy object, not the passwordless one, starting with administrators and help desk staff.
• Remove push, OTP, SMS and magic-link fallbacks for each enforced ring.
• Issue first credentials only after verified identity checks, and make recovery at least as strong as sign-in.
• Keep a dated exception register and review it monthly.
• Block legacy authentication and unneeded device code flows.
• Measure enforcement coverage and phishable sign-in share, not enrolment.

Standards and references

• NIST: SP 800-63B-4, Authentication and Authenticator Management
• OMB: M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
• CISA: Implementing Phishing-Resistant MFA fact sheet
• Google Workspace: Deploy 2-Step Verification
• Microsoft Learn: Conditional Access authentication strengths
• Okta: Phishing-resistant authentication
• MITRE ATT&CK: Adversary-in-the-Middle (T1557)

Related NHI Mgmt Group resources: Phishing-Resistant MFA Guide, Passwordless and Passkeys Guide, Phishing-Resistant MFA vs Push and SMS MFA, Passwordless MFA vs OTP-Based MFA, Smart Card and PIV/CAC Authentication Guide.