Help users manage passkeys effectively

These passkey management guidelines help you accomplish an intuitive, secure, and robust experience for your users.

W

web.devweb.dev

·

Designing a usable passkey management experience

Passkeys are becoming a mainstream authentication method, but their success depends on more than just the registration flow. Users need a clear, centralized way to manage the passkeys they've created. A well-designed management experience helps users keep track of credentials, clean up stale entries, and understand what they're signing in with.

Support multiple passkeys per account

Allow users to register multiple passkeys for the same account, ideally across different providers. If a user loses access to one provider—because the platform no longer supports it or the account was compromised—they can still authenticate using a passkey from another provider. This reduces the risk of account lockout.

However, avoid letting users create more than one passkey for the same account using the same provider. Your backend should be able to store multiple public keys per user account and treat each passkey as an independent credential.

Build a dedicated passkey list page

Expose a management page that lists every registered passkey along with identifying details. This gives users a single place to review, rename, and remove credentials. Useful fields to display include:

Passkey name: Show the name assigned during registration. Ideally, derive it from the provider using the AAGUID; if no provider match is found, fall back to the device name from the user agent string.
Provider logo: A recognizable logo helps users quickly distinguish credentials across providers.
Creation and last-used timestamps: These help users identify which passkey corresponds to which device or sign-in.
Sync indicator: Passkeys are synced by default, but provider support is still evolving. If a passkey isn't syncable, make that explicit—users often assume their passkeys travel across devices and are confused when they don't.
Last sign-in context: Optionally show the browser, OS, or IP address used at the last sign-in. This can help users spot suspicious activity.
Rename option: Users may register passkeys from the same provider using different provider accounts (for instance, multiple Google profiles). Allow renaming so they can label passkeys in a way that makes sense to them.

Let users delete passkeys

Deletion is essential for two scenarios: when a user upgrades devices and wants to remove a passkey bound to an old one, and when an attacker has hijacked an account and registered a passkey for future access.

Deleting a passkey removes its public key from your server, so it disappears from your list. But the private key stored with the passkey provider still exists. On the next sign-in attempt, that passkey will still be offered as an option—and authentication will fail because the server-side public key is gone. That's a confusing experience.

To avoid this mismatch, call the Signal API to notify the passkey provider when you delete a credential. If the browser and provider support it, the provider can remove its copy of the passkey too. If the API isn't available, suggest the user delete the passkey manually from the provider's settings.

Handle deletion of the last passkey

Removing the last remaining passkey for an account has real consequences the user may not have considered. If they have no other sign-in method for your site, they could be locked out permanently. Before completing the deletion, explain what they're losing and what sign-in options remain—such as a backup method or the ability to register a new passkey right away. This is also a natural moment to collect feedback about why they chose not to use passkeys.

Offer passkey creation on the management page

Users should have a clear entry point for creating new passkeys even after their initial setup. While there may be prompts elsewhere in the journey, a management page should always offer the option to add a credential. For security-minded users, also support registering passkeys on hardware security tokens. To allow both platform authenticators and security keys, leave authenticatorSelection.authenticatorAttachment unset rather than locking it to "platform". The security key option appears as a secondary choice without disrupting the default flow.