- TOTP and number-matching push can improve security without being phishing resistant.
- FIDO2/WebAuthn protects against false sign-in sites, but enrollment and recovery still need controls.
- Choose factors for each access path and test what happens when the primary factor is lost.
"MFA enabled" does not tell you whether an attacker can relay a code through a fake login page or persuade support to replace the factor. Choose authentication methods by the attacks they resist and the recovery process your team can maintain.
NIST SP 800-63B-4 treats phishing resistance as a technical property, not a sliding marketing score. Manually entered OTP codes and ordinary push approvals do not provide it. FIDO2/WebAuthn authenticators bind the authentication to the legitimate relying party.
Compare methods without mixing properties
| Method | Phishing resistant? | Deployment consideration |
|---|---|---|
| SMS or voice code | No | Carrier and number recovery add dependencies; codes can be relayed |
| Email code or link | Generally no | Mailbox compromise and session security affect the whole flow; do not assume an independent second factor |
| TOTP authenticator app | No | Removes carrier dependency, but a user can still enter the code into a phishing site |
| Ordinary push approval | No | Unexpected prompts and approval fatigue need controls |
| Number-matching push | No | Reduces blind approvals; it does not provide WebAuthn's origin binding |
| Hardware OTP token | No | Useful when phones are unsuitable, but generated codes remain relayable |
| Properly configured PIV or certificate authentication | Can be | Protocol and verifier binding matter; certificate lifecycle adds work |
| FIDO2 security key or WebAuthn passkey | Yes | Enrollment, device or key loss, and recovery still need a managed process |
An authenticator app may support several methods. Evaluate the configured method rather than assigning a security property to the app's brand. Likewise, a hardware key operating in OTP mode does not provide the same protection as its FIDO2 mode.
Prioritize sensitive access paths
Start with administrators, help-desk staff, finance, and other roles that can change access or authorize consequential actions. Identify every application those users reach and whether it can enforce the required method. Protecting the identity provider does not automatically close a legacy local-login path.
Where phishing-resistant options are not yet supported, use the strongest practical interim method, reduce privileges, monitor exceptions, and set a migration owner. An interim control should have a stated limitation rather than being described as equivalent protection.
For general workforce rollout, test the actual device mix, accessibility needs, remote onboarding, and shared-workstation workflows. A factor employees cannot reliably use will create pressure for weaker recovery exceptions.
Decide between synced and device-bound credentials
Passkeys can be synced or tied to a particular device or security key. That choice affects recovery, portability, and administrative control. Check which credential types your identity platform accepts and whether policy distinguishes them.
For sensitive roles, evaluate control of the device or key, user verification, approved enrollment, and backup factors. For synced credentials, include the security and recovery of the sync account. Do not assume all passkey deployments satisfy every assurance requirement merely because the sign-in is phishing resistant.
Keep an inventory of issued physical keys where relevant. Provide a protected backup method and a replacement procedure that does not depend on an unverified phone call.
Test recovery before calling the rollout complete
Use a test account to exercise a lost phone or key. Check how support verifies identity, what authority approves replacement, whether existing sessions or factors need revocation, and which notifications are sent. Include an after-hours case.
Review enrollment and recovery logs alongside sign-ins. Successful phishing-resistant authentication cannot prevent misuse of an already stolen session in every circumstance, nor can it correct excessive application permissions. Keep session controls and least privilege in the wider design.
Record coverage by application path, factor type, and unresolved exception. That gives leadership a clearer migration picture than a single percentage of employees who have registered any MFA method.
Turn this identity guidance into a review of MFA strength, privileged access, lifecycle controls, and audit visibility.