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. 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.

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. 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 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. 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 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
- Android guides