Passkey UX: how to design sign-in people trust

The best moment to offer a passkey is just after someone has signed in, or as they create an account. They have just proved who they are, and nothing stands between them and what they came to do. Google’s guidance adds three more good moments: in security settings, after account recovery, and when someone confirms who they are before a sensitive change.

Don’t make it a wall. A screen that demands a passkey before someone can reach their basket turns a convenience into an obstacle, and people who don’t understand the request will leave or call support. The FIDO Alliance’s design guidelines, based on usability research, make the same point: people see a passkey as a welcome extra while they are managing their account, and as an interruption in the middle of a task such as shopping.

Give people a real choice. A clear Create a passkey button, a Not now beside it, and the same offer waiting in account settings for later. If they say no, leave it for a while rather than asking at every sign-in.

Here is the same offer made two ways. The first stops people at the door with the names of standards. The second waits until they are in, and says what they will do.

Returning people shouldn’t have to find a separate passkey button. Browsers can show saved passkeys in the same autofill list as saved passwords, right under the email or username field. The person taps the field, picks their account, confirms with their fingerprint, face or screen lock, and they’re in.

This is called conditional mediation, or conditional UI. On the web, you add webauthn to the field’s autocomplete value, after username, and start a passkey request when the page loads. The request waits quietly until the person picks a passkey from the list. Current versions of Chrome, Edge, Safari and Firefox support it, and people without a passkey simply see an ordinary email field.

Keep the rest of the form as it was. Anyone who types their email and presses Continue still gets the usual next step, whether that is a password, a code or a passkey prompt.

Here is a returning Kettlecress customer signing in this way: the email field, the passkey in the autofill list, the device’s own prompt, and their account.

Most people don’t know what FIDO2, WebAuthn, an authenticator or a credential is, and they shouldn’t need to. Describe the action and the benefit in words they already use: “Sign in with your fingerprint, face or screen lock.” Google’s own example copy says much the same, and the phrase covers everyone, including people whose phone has no fingerprint reader and people who prefer a PIN.

Do use the word passkey, though. The big platforms all use it, so people are starting to recognise it, and naming it lets them spot the same thing on the next site. Google recommends including the term without making it the focus. Put it on the button, Create a passkey, and explain it in the sentence beside it.

Answer the worry before it is asked. Some people will assume your site keeps a copy of their fingerprint or a picture of their face. It doesn’t: the check happens on their device, and your service never receives it. One short line saying so does a lot of work.

Creating a passkey happens in a prompt drawn by the device, not by you, and it closes in a second or two. Without a message afterwards, people can’t be sure anything happened. The FIDO Alliance recommends clear words before the device’s prompt and a confirmation after it.

Make the confirmation useful. Say it worked, say how to sign in next time, and say where the passkey was saved, because that decides where it will work. A passkey saved in iCloud Keychain works on the person’s other Apple devices. One saved in Google Password Manager, or in a password manager such as 1Password, works wherever they use that. Your site can tell which provider saved it from a code the passkey carries, called the AAGUID, matched against a list the community maintains.

Passkeys sync within one provider, not across all of them. Someone whose passkey lives on their iPhone may sit down at a Windows laptop at work where it isn’t available. The browser can still help: it offers to use a phone instead, shows a QR code, and the person scans it and confirms on their phone. Bluetooth needs to be on for both devices, because it checks that the phone is nearby.

Once they’re in, offer a passkey for this device too, so next time they don’t need the phone. Google’s passkey deployment checklist recommends exactly this after a sign-in from another device.

Moving between providers is getting easier. The FIDO Alliance’s Credential Exchange standard lets one password manager pass passkeys to another without an unprotected export file. Apple added it in iOS 26 and macOS 26, and Google began rolling it out for Google Password Manager on Android in 2026. Support is still spreading, so don’t build your recovery plans on it.

A passkey should be a faster way in, not the only one. People sign in from a shared family laptop, a library computer, or a new phone that hasn’t finished syncing. If the passkey is the only door, every one of those becomes a support call.

When a passkey sign-in fails, the browser usually doesn’t tell your site why, for privacy. The person may have cancelled, or there may be no passkey for your site on this device. Write one message that works for both: say you couldn’t sign them in with a passkey, suggest it may be on another device, and offer a way in that doesn’t need it, such as a code sent by email.

Don’t remove someone’s password the moment they create a passkey. Let them choose to, later, from account settings, once they are used to signing in without it.

Losing a phone usually doesn’t mean losing a passkey. Most passkeys are synced by the person’s password manager, so when they sign in to the same Apple, Google or password manager account on a new phone, their passkeys come back. A passkey on a hardware security key is different: it lives only on the key, and if the key is lost, so is the passkey.

Your recovery route still matters, because it is the way in for everyone who can’t use their passkey, including anyone trying to break in. Match it to what the account protects. For a grocery account, a code sent to the email address on file is reasonable. For a bank, use the checks you already trust for a forgotten password, and tell the customer by email when a new passkey is added, so they notice if it wasn’t them.

After recovery, offer a new passkey on the device they’re using, and show the passkeys list so they can remove the ones they no longer have. The FIDO Alliance’s guidelines and Google’s guidance both treat the moment after recovery as a good time to offer one.

People need one place to see their passkeys, add another and remove one they no longer trust. The FIDO Alliance suggests putting it in account settings, above passwords, with each passkey listed separately and a way to remove it. If someone has none, the top of that page is a good place to offer one.

Name each passkey after the provider that saved it, such as iCloud Keychain or Google Password Manager, not “Credential 1”. Show when it was created and when it was last used, as Google’s guidance on managing passkeys recommends, so people can spot the one on the phone they sold last year. Let them rename it, too.

Removing a passkey here stops it working on your site, but the copy in the person’s password manager stays until they delete it there. Say so in the confirmation. In browsers that support the WebAuthn Signal API, such as Chrome and Safari, your site can also ask the password manager to hide it.