Moving to passkeys? Keep a recovery plan for the accounts that still use passwords

Passkeys can replace passwords on accounts that support them. If any of your accounts still require passwords, keep a way to generate and store unique credentials for those accounts. Before changing sign-in methods, record how you would recover access if your usual device were unavailable.

NIST's current Digital Identity Guidelines describe properly configured syncable authenticators as phishing resistant because their key use is constrained to the website or relying party for which the credential was created. Each authentication also includes a fresh random challenge to resist replay. NIST separately recommends password managers for accounts that still require passwords and says the manager itself should support multifactor authentication.

Treat sign-in and recovery as one system

A smooth sign-in is not enough. Ask what happens after a lost phone, broken laptop, forgotten vault password or departure of a team member. A passkey may be synced through a platform account, stored on one device or held on a hardware security key. Those are different recovery paths.

For every important account, record:

• the sign-in methods currently enabled;
• where each passkey is stored or synced;
• whether a second enrolled device or hardware key exists;
• the recovery contact and verified recovery method;
• where one-time recovery codes are stored;
• who can remove an old device or former team member.

Do not put the only recovery code inside the vault it is meant to recover.

A practical migration order

Start with the account that controls other accounts: your primary email, platform account and password manager. Confirm their recovery details, add a second factor or second passkey where supported, and sign in from a second device before changing lower-impact accounts.

Then migrate a small batch:

1. Create the passkey from a device you control.
2. Note the provider or device that stores it.
3. Sign out and test a normal sign-in.
4. Test the documented recovery path without completing a destructive reset.
5. Check the service's current instructions for removing a password fallback. Do not assume creating a passkey removed it, and do not disable your only working recovery route.
6. Remove stale devices only after the replacement method works.

The goal is not the largest passkey count. It is fewer reusable secrets without creating a single unrecoverable dependency.

Choosing a password manager during the transition

Use a manager that works on every platform you actually use, supports strong protection for the vault account, provides a clear export path, and explains how recovery works. Team use needs role removal, shared-item ownership and an offboarding method. Consumer use needs a recovery design another trusted person could follow if that is part of your plan.

Do not rank managers from feature lists alone. A useful evaluation would test import, autofill, passkey creation, export, a lost-device scenario and account recovery on named versions. This article performs none of those tests.

What passkeys improve, and what they do not

Passkeys reduce exposure to fake login pages that try to capture a reusable password. They do not make the device, platform account or recovery process invulnerable. Someone who gains control of an unlocked device or the account that syncs credentials may still create serious problems. Device locks, updates, account alerts and recovery hygiene remain part of the system.

Passwords also remain. For those accounts, use unique generated credentials rather than memorized variations. NIST's consumer guidance recommends a password manager and says that a password created manually should be at least 15 characters.

The one-page plan

Finish with three columns: passkey ready, password plus MFA, and blocked or unknown. Put every critical account in one column. Add the recovery method and last test date. Inquory proposes a quarterly review, and another whenever a phone, laptop, staff role or platform account changes; this interval is a practical suggestion, not a NIST requirement.

Keep this inventory private. It should contain locations and verification dates, not passwords, recovery codes, private keys or copies of authentication messages.

A fictional dependency check

Suppose Jules uses a platform account to sync passkeys, and that account sends recovery messages to Jules's main email. The email account also relies on the same platform for its only working passkey. This fictional example identifies a dependency to investigate; it does not establish how either unnamed service handles recovery.

Jules reads both providers' current recovery instructions and checks whether a supported second authenticator or recovery route remains usable without the usual device. Until that is confirmed, the inventory stays blocked or unknown. No account reset, credential sharing or deletion is needed merely to document the gap.

Editorial method and limitations

Inquory reviewed NIST documentation. No password manager, authenticator, passkey provider or recovery flow was tested. This is general security organization guidance, not a guarantee against account loss or compromise. Vendor-specific claims require current documentation and named-version testing.

Sources and disclosure

• NIST SP 800-63B-4 Appendix B: Syncable Authenticators
• NIST consumer password guidance

AI assisted research, drafting and the conceptual illustration. See our AI-use disclosure, editorial policy and corrections process.