 Eiji Kitamura [X](https://twitter.com/agektmr) [GitHub](https://github.com/agektmr) [Mastodon](https://infosec.exchange/@agektmr) [Bluesky](https://bsky.app/profile/agektmr.com)
Published: May 15, 2025
Passkeys are rapidly emerging as a more secure, easier, and faster alternative
to passwords, offering enhanced security and user convenience. To
fully realize the potential of passkeys, careful consideration must be given to
the user experience surrounding their management. This document outlines
guidelines and optional features for designing an intuitive, secure, and robust
passkey management system.
## Manage multiple passkeys
Let users add multiple passkeys and use more than one provider.
But [don't let them add more than one passkey for the same account with the same provider](https://web.dev/articles/webauthn-exclude-credentials).
If a user loses access to one provider, such as when the platform doesn't
support it, or the user loses access to it, they can still sign in with another
passkey from a different provider. This setup lowers the risk of account
lockouts. Make sure your database supports storing multiple passkeys per user.
## Display a list of registered passkeys
Your website or app should display registered passkeys in a list with key
details to help users manage them effectively. This screenshot illustrates how
such a dedicated passkey management page might look. It shows how a user can
create passkeys across multiple platforms, and provides a centralized place to
manage them.
 Example of a passkey management page showing good practices.
Here are some of the common details and features websites and apps can display
about a passkey:
- **Passkey name** : Display the passkey name which was given at the time of registration. Ideally this name matches the passkey provider it was created on [based on the AAGUID](https://web.dev/articles/webauthn-aaguid). If no matching passkey provider is found, naming it after the device information based on the user agent string should be fine.
- **Passkey provider logo**: Display the passkey provider logo. This helps the user identify the passkey they want to manage.
- **Timestamp of when the passkey was created and used the last time**: Recording and displaying the passkey creation timestamp and last usage timestamp can also help the user identify the passkey they want to manage.
- **Non-sync indicator**: Passkeys are synced by default, but the passkey providers sync capability is still evolving. It's a common confusion when a passkey doesn't sync despite the user's expectation. Showing a passkey's incapability of sync can help users clarify this confusion.
- **Delete button** : Allow users to delete the passkey. See [Allow
deleting a passkey](https://web.dev/articles/passkey-management#deleting-a-passkey) for more details.
- **Edit button**: Many users appreciate being able to rename a passkey. For example, when there are multiple passkeys from the same passkey provider but with different provider accounts. Imagine saving multiple passkeys to different Google Accounts. By allowing the user to rename the passkey, they can change it to a name they like.
- **Last sign-in browser, OS or IP address**: Optionally providing details about last sign-in helps the user identify suspicious sign-ins. The browser, OS or the IP address (or location) used to sign-in can be great information.
## Allow deleting a passkey
Allow users to delete a passkey. This helps them tidy up the list, for example,
when a user switches to a new device but the associated passkey is bound to the
older device. It's also helpful when an attacker hijacks a user account and
creates a passkey for future use.
### Signal the updated list of passkeys
Deleting a passkey removes its credential entry and public key from the server
database. This way, the passkey will disappear from the registered passkey list
and it will appear to the user that the passkey is deleted. However, in reality,
it's only removed from the server, and the passkey stored to the passkey
provider still remains, which can cause confusion. The next time the user tries
to sign in, the removed passkey will still appear as a sign in option. But,
authenticating with it will fail, because the matching public key is already
deleted from the server.
To avoid confusion, it's important to keep the passkey on a passkey provider
and the public key on the server consistent. You can achieve this by
[signaling the updated list of passkeys to the passkey provider](https://developer.chrome.com/docs/identity/webauthn-signal-api#signal-a-list-of-saved-credentials).
If the browser and the passkey provider support the Signal API, they can update
the list of passkeys and delete unnecessary passkeys. If they don't support
the API, encourage the user to delete the passkey manually.
### Delete the last passkey
If a user attempts to delete their last remaining passkey for a given account, make sure they
understand that they will have to sign in with another option with more friction
and potentially lesser protection. If this is their only sign-in method for your site, they
won't be able to sign in again. Inform users how they can sign in next time,
such as using a backup method if available or prompting them to register another
passkey before proceeding. It's a good chance to collect feedback why they chose
not to use a passkey.
## Allow creation of new passkeys
While there are opportunities to create passkeys throughout a user's journey
(like right after sign in), it's crucial to have a central hub where users can
always go to create new passkeys, delete passkeys and manage passkeys. A passkey
management screen is the best place for that.
To create a passkey user flow, follow the
[Create a passkey for passwordless logins](https://web.dev/articles/passkey-registration)
Developer's Guide. For advanced security, consider allowing users to create a
passkey on a hardware security token. You can expect users who are willing to
manage passkeys to be more knowledgeable or experienced, so allowing them to
create a passkey on their security key provides improved flexibility.
To allow saving passkeys to a hardware security token, leave
`authenticatorSelection.authenticatorAttachment` unset instead of setting it to
`"platform"` on a passkey creation request. This way, the browser accepts both
platform (device) and roaming authenticators (a security key) without the user
experience being significantly different from only allowing a platform
authenticator. The option to create a passkey on a security key appears as a
secondary option.
## Checklist
- Allow users to manage passkeys in a passkey management page.
- Support registering multiple passkeys.
- Allow users to add new and flexible types of passkeys on the management page.
- Display the passkey name.
- Indicate whether a passkey is syncable or non-syncable.
- Allow users to remove a public key from the server.
- Signal the list of passkeys when an associated public key is removed from the server.
## Other UX guides
- General passkey UX guides
- [Passkeys user journeys](https://developers.google.com/identity/passkeys/ux/user-journeys)
- [Communicating passkeys to users](https://developers.google.com/identity/passkeys/ux/communicating-passkeys)
- [Passkeys user interface design](https://developers.google.com/identity/passkeys/ux/user-interface-design)
- Android guides
- [User authentication with passkeys](https://developer.android.com/design/ui/mobile/guides/patterns/passkeys)