Passkeys change the sign-in conversation from remembering a reusable secret to proving control of an authenticator. That can make account protection more resistant to phishing, but a passkey deployment still depends on enrollment, device protection, recovery, and the service's implementation. The useful question is not whether the password box disappeared. It is whether the whole account lifecycle became safer and understandable to the person using it.
NIST's July 2025 Authentication and Authenticator Management guidance is a useful reference for that distinction. It separates authentication assurance levels, phishing resistance, and authenticator-management requirements, and includes a normative appendix on syncable authenticators. This article translates the broad ideas into practical account decisions; it is not a compliance assessment for your website or an assertion that every product called a passkey meets every assurance level. NIST SP 800-63B-4
Phishing resistance is about the protocol, not the label
NIST states that passwords are not phishing-resistant. A person can enter a password into a convincing imitation site, and another factor based on a transferable secret can have its own phishing weaknesses. Phishing-resistant authentication uses a protocol designed to resist that kind of credential forwarding rather than relying entirely on the user's ability to recognize a fraudulent page. Authentication guidance
A familiar product label is not enough to understand the boundary. Read the service's description of the authenticator, supported devices, and recovery options. Consider whether the account can still be taken over through a weaker fallback even when its main sign-in method is strong.
This does not mean users should stop checking addresses or ignore suspicious requests. Account security still benefits from careful navigation, current software, and skepticism toward unsolicited approval prompts. A strong authentication protocol helps with a particular class of attack; it is not a universal replacement for judgment.
Syncable and device-bound are different decisions
A syncable authenticator can make access across devices more convenient, but it introduces questions about the account and service that manage synchronization. A device-bound authenticator can create different availability and recovery considerations. Neither choice should be made purely from a slogan that convenience is unsafe or hardware is automatically enough.
NIST's guidance makes an important assurance distinction: AAL3 requires a non-exportable authentication key, and syncable authenticators must not be used at that level because their private keys need to be exportable. That does not make syncable authenticators useless; it explains why requirements depend on the assurance target. Assurance-level distinctions
For a personal account, start with the service's supported methods and your realistic recovery needs. For an organization, have the identity and security owners select a policy appropriate to the account's risk and regulatory context. Do not copy a federal assurance-level requirement into a blog's settings without understanding its scope.
Prepare recovery before removing old access methods
Before changing authentication, confirm that you know how to recover access if a device is lost, damaged, replaced, or unavailable. Read the service's current recovery instructions and identify which options you can actually use. A recovery process dependent on the only lost device can leave a person with a strong sign-in method and no usable account.
If the service offers saved recovery codes, store them through an appropriate secure method and treat them as secrets. NIST describes look-up secrets, including saved recovery codes, and notes that they are not phishing-resistant. A caller asking for a recovery code can therefore create a different risk from a legitimate passkey sign-in. Recovery-code context
Do not send recovery material to a support stranger or paste it into a public chat. Test the documented process only within the account's allowed options, and avoid deliberately locking yourself out to prove that the recovery page exists.
Enroll through the account's real security settings
Navigate directly to the service you intend to protect and use its documented account-security workflow. Confirm which device or authenticator is being enrolled and how the service will identify it later. Avoid enrollment prompts embedded in unsolicited messages or unfamiliar sites.
Give enrolled authenticators meaningful names when the service permits it. A clear record such as a particular personal device or approved hardware key can help you recognize which item to remove after a replacement. A list of indistinguishable entries makes lifecycle management unnecessarily confusing.
If the account belongs to an organization, follow the approved enrollment and ownership policy. Sharing a personal synchronization account or hardware key to make team access convenient can undermine accountability and make offboarding difficult. Use the service's actual team or organizational identity features instead.
Protect the devices that approve sign-in
A passkey does not make device security irrelevant. Keep the operating system and browser maintained, use the device's appropriate lock mechanism, and understand how local approval works. Be cautious about lending an unlocked device that can access important accounts.
Review who controls the synchronization account if your authenticator relies on one. Its recovery and authentication settings can affect your practical security and availability. The exact relationship varies by product, so use the provider's documentation rather than assuming that all passkey ecosystems behave identically.
When disposing of or transferring a device, follow the platform's documented account-removal and data-erasure process. Also review the service's enrolled-authenticator list where appropriate. Physical possession changing hands should not leave old access paths unexplained.
Check the fallback instead of declaring victory
After enrollment, review which alternative sign-in and recovery methods remain available. A password, an email-based recovery route, or another verification channel may still play a role. The account's real security is influenced by those paths, not only by the strongest method shown on its settings page.
Do not remove a fallback blindly if doing so violates policy or leaves you unable to recover. Make a deliberate choice based on the service's supported configuration, account risk, and backup authenticator options. For sensitive work accounts, let the responsible identity team assess the trade-off.
NIST says AAL2 verifiers must offer at least one phishing-resistant authentication option, while its requirements differ at other levels. That is guidance about assessed authentication systems, not proof that every commercial account with an optional passkey has achieved a particular assurance level. AAL2 guidance
Handle lost devices as a lifecycle event
If a device is lost, use the provider's authorized account and device-management tools to review access. Revoke or remove affected authenticators where the service supports it, secure the relevant accounts, and follow the organization's incident process if workplace information is involved.
Avoid assuming that changing an unrelated password automatically removes every enrolled authenticator or session. Verify what the service's specific action does. Keep a record of the changes, and seek legitimate support when recovery is uncertain rather than trusting someone who promises access in exchange for codes or secrets.
Be wary of unexpected account-recovery conversations. A strong normal sign-in method does not make a person asking for recovery material trustworthy. Reach support through the service’s known website or documented channel, confirm which action is being requested, and stop if the request conflicts with the provider’s guidance. Recovery deserves the same deliberate handling as enrollment, especially when someone is applying time pressure.
A better definition of successful adoption
A useful passkey rollout leaves people knowing how to sign in, recognize their enrolled devices, recover safely, and remove access when circumstances change. It also leaves the service or organization with a policy that matches the account's risk instead of relying on a fashionable feature name.
Start with an important account, understand its supported workflow, prepare recovery, and test ordinary sign-in before expanding. Passkeys can strengthen account protection, but the quality of enrollment, fallback, and lifecycle decisions determines how well that protection survives the messy reality of lost devices and changing work.
