Passkeys: passwordless sign-in, in brief

A passkey is a sign-in key that lives on the user's phone or laptop and is unlocked with a fingerprint, face scan or screen lock PIN. The user never types a password, and the website never stores a password that could be stolen. Since October 2023, Google has offered passkeys by default for personal accounts, so many of your users already have at least one, even if they don't know what it's called.

What a passkey actually is

Passkeys are built on the FIDO standards and use public key cryptography. When an account is created, the device generates a key pair:

• the private key stays on the device (or in the password manager that syncs it, encrypted);
• the public key goes to the app's server.

At sign-in, the server sends a challenge, the device signs it with the private key once the user confirms with a fingerprint or PIN, and the server checks the signature against the public key. Google's documentation puts it simply: the site stores only the public key. If the database is breached, the attacker gets nothing they can use to break into accounts.

Why phishing matters here

A password works anywhere you type it, including on a fake page that looks exactly like yours. A passkey doesn't: it's tied to the website or app it was created for. Google's documentation notes that passkeys work only on the websites and apps where they were registered. On a lookalike domain, the phone simply doesn't offer the key.

For a service app, that means fewer hijacked accounts and fewer messages along the lines of "I can't get in, someone changed my password."

Where it already works

• Apple: passkeys sync through iCloud Keychain across Apple devices, end-to-end encrypted. Apple says "even Apple can't read them," and an iPhone can be used to sign in on non-Apple devices too.
• Google: on October 10, 2023, passkeys became the default option for personal Google Accounts. Passwords are still available, but users are prompted to create a passkey.
• The standard is shared. The FIDO Alliance describes passkeys as either synced across a person's devices or bound to a single device or a physical security key.

In short, an ordinary user with a recent phone already has everything they need. The missing piece, most of the time, is on the app side.

What it means for your app

If your app has user accounts, passkeys can be added without rebuilding everything. A few decisions to make:

1. Don't drop passwords overnight. The web.dev sign-in guide is clear that, for now, sites need to support both password users and passkey users.
2. Use autofill. On the web there's an option called "conditional UI": the username field gets autocomplete="username webauthn", and the passkey shows up in the browser's autofill suggestions next to saved passwords. Nobody has to learn a new button.
3. Offer a passkey after a successful sign-in, not on the first screen. Someone who just got in with a password is the most likely to say yes to "next time, use your fingerprint."
4. Plan for account recovery. What does someone do if they lose their phone and the passkey wasn't synced? Without a backup route (a verified email, another device), you've just swapped "I forgot my password" for "I lost my phone."
5. Allow several passkeys per account: one on the phone, one on the work laptop.

When it's worth doing now

It's especially worth it if:

• your app holds sensitive data or handles payments;
• users sign in often and complain about forgotten passwords;
• most of your users are on phones, where typing a long password is most annoying.

For an internal app with ten employees signing in with a company account, the priorities may be different. For a new public app, it makes sense to design it with passkeys from the start, even if it keeps passwords at launch.

If you're planning an app and want sign-in done properly, see what we do at App Dev. On sign-up screens in general: The sign-up screen: where most users drop off.