Phishing-resistant MFA is a sign-in method where the credential is cryptographically bound to the real website’s origin, so there is no password or one-time code that a fake page can collect and replay. The two families that CISA names in its fact sheet on the topic are FIDO2/WebAuthn (passkeys and hardware security keys) and PKI-based authentication such as smart cards. SMS codes, email codes, authenticator-app codes and push approvals do not qualify, because in every one of those the user can be talked into handing the secret to the attacker.
What makes MFA phishing-resistant?
An attack is phishing when the user is tricked into giving a credential to the wrong party. A method resists that when the user has nothing they could give away. With WebAuthn (the browser standard behind passkeys and security keys), the browser only lets a page ask for credentials that belong to its own domain (the relying party ID), and it puts the page’s origin into the data the authenticator signs. A look-alike domain therefore cannot ask for your real site’s passkey. Even an adversary-in-the-middle (AiTM) kit that relays the exchange through a reverse proxy produces a signature over the wrong origin, which the real server rejects, and there is no typed code for the proxy to forward.
NIST describes the same property in its 2025 digital identity guidelines (SP 800-63B-4) under the name “phishing resistance”, which it achieves through authenticators that verify the name of the site they are talking to and that do not rely on a secret typed in by hand. CISA’s fact sheet “Implementing Phishing-Resistant MFA” (2022) calls FIDO and PKI-based methods the phishing-resistant options that are widely available today.
Which MFA methods are phishable?
The table below lists what an attacker gets from each common method if they have fooled the user once.
| Method | Phishable | What the attacker gets |
|---|---|---|
| Passkey (device-bound or synced) | No | Nothing reusable; the credential is bound to the real site |
| Hardware security key (FIDO2) | No | Nothing reusable; the credential is bound to the real site |
| Smart card / PKI certificate | No | Nothing reusable; bound through the TLS client certificate |
| Push approval with number matching | Yes | An approval the user gives while on the fake page |
| Plain push approval | Yes | An approval, and the method is also open to MFA fatigue |
| TOTP app code | Yes | A code that works for its whole time window |
| SMS or voice code | Yes | A code, and the number can also be taken over by SIM swapping |
| Email code | Yes | A code that can be relayed in real time |
| Email magic link | Yes, depending on the implementation | A link the user can be tricked into pasting or approving elsewhere; only as strong as the mailbox |
Number matching on push approvals helps against someone approving a prompt they did not start, but it does not help when the user starts the sign-in themselves on a fake page and reads the number out to it. We covered the helpdesk side of that in MFA fatigue and helpdesk vishing, and a recent example that sidesteps the page entirely in device-code phishing with passkey lures.
Synced passkeys versus hardware security keys
At the moment of sign-in, a synced passkey is as phishing-resistant as a hardware key. A passkey that syncs between your devices through a platform account (iCloud Keychain, Google Password Manager, a password manager) is still bound to the origin, so the phishing resistance of the login itself is the same as for a hardware key.
What differs is where the private key lives and how it can be recovered. A device-bound key, such as one on a hardware security key, cannot be copied off the device, which is why NIST’s guidance reserves its highest assurance level for authenticators with non-exportable keys while allowing synced passkeys at the level below it. For a typical SaaS product, a synced passkey is a large improvement over a password plus a code, and hardware keys are worth requiring for administrators and for customers whose own policy asks for device-bound credentials.
The recovery path for a synced passkey is the sync provider’s account, which becomes part of your threat model. Synced passkeys are still a good choice, but you should know what your recovery process does when someone loses all their devices.
Why is adoption still slow?
Passwords are still common at work. In the 2026 Global State of Authentication survey that Yubico and Okta published on 7 October 2026, 43% of security professionals said they still rely on passwords at work, and 52% said they were given a password on their first day. The reasons usually come down to onboarding defaults that start with a password, recovery flows that fall back to email or SMS, and shared or contractor accounts that do not map cleanly onto one person with one device.
Some vendors are changing their defaults. According to Microsoft message center posts summarised by Entra.news, MC1450133 lets users register a passkey as their first MFA method without setting up SMS first, and MC1459133 turns passkeys on by default for B2B guest users. Both are scheduled to start rolling out in late October 2026, although Microsoft’s dates often move, so check the message center for the current state.
Where does the weak spot move once you have passkeys?
An attacker who cannot phish the sign-in goes after the edges around it.
- Enrollment. Whoever can add a new authenticator to an account can add their own, so adding a passkey should require a recent strong sign-in.
- Account recovery and helpdesk resets. If a phone call to support can reset MFA, the helpdesk becomes the easiest way into the account. Require identity verification that does not depend on information an attacker can find.
- Fallback methods. If SMS or email codes remain as an alternative, an attacker simply asks for those. Phishing-resistant MFA only protects the accounts where the weaker methods are turned off.
- Session theft after login. Stolen session cookies skip authentication entirely, so short sessions, sender-constrained tokens such as DPoP, and device checks still matter. See how infostealers and stolen sessions bypass MFA.
How do you roll it out in a SaaS product?
A sequence that keeps support load manageable looks like this.
- Administrators first. Require a passkey or security key for anyone with admin rights in your product and in your own tooling, and remove the weaker fallbacks for them.
- Optional passkeys for everyone. Offer passkey registration after a normal sign-in, and show it where users already manage their security settings.
- Enforcement per organization. Let a customer’s admins require phishing-resistant MFA for their own tenant, since some will be asked by their own auditors to do so.
- Close the fallbacks. Once most active users have a passkey, retire SMS and email codes for the accounts that have one and tighten the recovery flow.
If you are building on Keycloak, the building blocks are already there. Since Keycloak 26.4 passkeys are a supported part of the default login forms, and you turn them on with the Enable Passkeys switch, which in current releases sits under Realm settings, Login tab (in 26.4 to 26.6 it is in the WebAuthn Passwordless Policy). Step-up authentication lets an application ask for a stronger factor only when it needs one. The setup is walked through in our Keycloak passkeys and WebAuthn guide, and the same principle in an Entra context is in moving off SMS MFA to passkeys. Skycloak is identity management as a service built on upstream Keycloak, so the same settings are available on the hosted login, with MFA policy set per application. The feature pages for multi-factor authentication and passwordless sign-in list what is available.
For how a related technique abuses an external MFA provider, see TrustSink and rogue external MFA, and for the older standard behind security keys, FIDO2 for passwordless security.
Frequently asked questions
Is Microsoft Authenticator push phishing-resistant?
No. A push approval, even with number matching, is a response that a person gives, so an attacker who has the user on a fake page can ask for it. Passkeys stored in Microsoft Authenticator are a different thing and do qualify, because they use the WebAuthn domain check.
Are synced passkeys as phishing-resistant as hardware security keys?
Yes, at sign-in, because both are bound to the site’s origin. They differ in where the private key lives and how it is recovered, which the section above covers.
Is TOTP phishing-resistant?
No. A TOTP code is valid for its whole time window and works on any site that asks for it, so a user who types it into a fake page gives the attacker something they can use immediately. TOTP is still much better than no second factor.
Does phishing-resistant MFA stop session hijacking?
No. It protects the sign-in, not the session that follows. A stolen session cookie is accepted without any authentication, so it takes shorter sessions and device checks as well.
Sources
- CISA, “Implementing Phishing-Resistant MFA” fact sheet (2022), https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
- NIST, SP 800-63B-4, “Digital Identity Guidelines: Authentication and Authenticator Management” (2025), https://pages.nist.gov/800-63-4/sp800-63b.html
- W3C, “Web Authentication: An API for accessing Public Key Credentials”, https://www.w3.org/TR/webauthn-3/
- Yubico and Okta, “2026 Global State of Authentication” press release (7 October 2026), https://www.yubico.com/press-releases/high-awareness-low-adoption-new-survey-reveals-nearly-half-of-security-professionals-still-rely-on-passwords/
- Entra.news summaries of Microsoft message center posts MC1459133 and MC1450133 (October 2026), https://daily.entra.news/message-center/MC1459133/ and https://daily.entra.news/message-center/MC1450133/