Adding a second step to sign-in can improve account protection, but different methods resist different attacks. Passkeys using the appropriate authentication protocol can bind a sign-in to the intended service, while manually entered codes can still be handed to an impostor. This guide explains the distinction and provides a practical setup review for personal accounts. Official guidance was checked on 23 October 2026.
Ask what the method protects
NIST authentication guidance distinguishes phishing resistance from simply requiring another secret. WebAuthn is an example of a protocol that binds authentication to the verifier’s domain. A manually entered one-time code does not provide that same binding. For a user, the practical question is which sign-in method the service supports and how it appears in the trusted application or browser. Do not assume that every screen labelled MFA offers identical protection. Record the method actually enrolled, rather than using two-step verification as a catch-all description.
Compare sign-in methods and recovery dependencies
| Item | Evidence or distinction | Review question |
|---|---|---|
| Password | A reusable secret sent to a verifier | Use a unique value and protect the account storing it |
| Manually entered code | Additional proof that can still be relayed to an impostor | Do not reveal it to unexpected callers or messages |
| Passkey or FIDO credential | Cryptographic authentication tied to the intended service | Check device support and the enrolled credential |
| Recovery method | A separate route when normal sign-in is unavailable | Protect it as carefully as the main account |
The CISA phishing-resistant MFA factsheet is a useful companion to the technical distinction. Stronger sign-in does not eliminate the need to protect a device, review active sessions or maintain a trustworthy recovery route.
Enrol from the account you already trust
Open the service independently through its established application or a known address. Find its security settings and review the available methods. Before removing an existing method, confirm that the new one works and that you understand how to sign in from another device you use. Give enrolled devices or keys recognisable names where the service supports that option. Avoid using a public or borrowed device as the long-term home of a personal credential. If the account belongs to an employer or school, follow the administrator’s enrolment process instead of changing managed settings independently.
Understand synchronised and device-bound credentials
The NIST discussion of syncable authenticators treats synchronisation and account recovery as additional security considerations. Some passkeys can be available through a protected sync service; others remain bound to a device or key. Neither description should be guessed from the word passkey alone. Check the provider’s explanation of where your credential is available and how a lost device is handled. Protect the sync account and review its trusted devices. A convenient recovery path can be valuable, but it is still an access path that deserves deliberate configuration.
Plan a backup that does not share the same single point of failure
Consider what happens if the phone used for sign-in is lost, damaged or unavailable. Where supported, enrol an additional trusted authenticator or retain the service’s recovery material securely. Keep the backup usable without depending entirely on the missing device. Record which accounts have been prepared, but do not put secret codes in a shared inventory. If a family member assists, clarify the difference between helping with setup and retaining permanent access. The aim is reliable access for the account owner without creating an informal collection of credentials held by other people.
Review unexpected prompts without approving them
A sign-in prompt should correspond to an action you initiated. If an unexpected request appears, decline it and inspect the account through a known route. Do not approve a request merely to stop repeated notifications or because someone on a call says it will cancel an attack. Check recent activity and enrolled methods, then follow the provider’s security process if something is unfamiliar. A passkey can reduce one class of phishing risk while other forms of deception remain possible, such as persuading a person to share files or authorise a payment after legitimate sign-in.
Sign-in protection checklist
- Identify the actual authentication method supported by the account.
- Enrol through the trusted application or independently opened website.
- Test the new method before removing an existing access route.
- Protect synchronisation, recovery and additional trusted devices.
- Reject prompts that do not match an action you initiated.
Repeat the review after replacing a phone, changing a recovery address or leaving a shared device behind. Remove credentials that you no longer control through the service’s supported settings. Keep a brief non-secret inventory of what remains, so future maintenance does not depend on remembering which device was enrolled years earlier.
Frequently asked questions
Are all forms of MFA phishing-resistant?
No. A manually entered code can still be relayed to an impostor. The protocol and its binding to the intended service determine the relevant protection.
Does a passkey make recovery unnecessary?
No. Devices can be lost and account access can fail for other reasons. Prepare the service’s supported recovery or backup method in advance.
Does phishing resistance prevent every kind of fraud?
No. It addresses a specific authentication problem. Device compromise, session misuse and deception about actions after sign-in require other safeguards.
Sources and verification
- SP 800-63B-4 authenticator requirements — NIST — 2026-10-23
- Implementing phishing-resistant MFA — CISA — 2026-10-23
- Syncable authenticator considerations — NIST — 2026-10-23