Passkey basics
What is a passkey? How it works and how it differs from a password
7 min read
Key points
- A passkey is the user-facing name for a FIDO2 / WebAuthn discoverable credential, used with the same gesture that unlocks the device.
- Each passkey is bound to the site's domain (the RP ID), so it cannot be used on a look-alike site, and the server keeps only a public key.
- The hard parts of adopting passkeys are not the cryptography but enrollment, recovery, and how long passwords stay around.
A passkey is a way to sign in based on FIDO2 / WebAuthn, the standards from the FIDO Alliance and the W3C, that replaces the password with a public-key pair. The private key stays with the user (on a device, in a password manager, or on a security key) and the server stores only the public key. Because the key is bound to the site's domain, it cannot be used on a phishing site, and a leaked server database does not let anyone sign in. For the user, signing in feels like unlocking their phone or laptop: a fingerprint, a face scan, or a PIN.
What "passkey" refers to
The FIDO Alliance describes a passkey as an authentication credential based on FIDO standards that can be stored on a phone or computer, or on a hardware security key, and that lets users sign in with the same process they use to unlock their device.
In technical terms, "passkey" is the user-facing name for a discoverable credential in the W3C Web Authentication (WebAuthn) specification, which was previously called a resident key. The passkeys.dev glossary defines a passkey as "the high level, end-user centric term for a FIDO2/WebAuthn Discoverable Credential." Because the credential is discoverable, the device can find "the key for this site" and offer it without the user typing a username.
WebAuthn Level 3 became a W3C Recommendation on August 25, 2026. In the browser, the API surface is navigator.credentials.create() and navigator.credentials.get().
The three parties
WebAuthn involves three roles:
| Role | Name in the spec | What it does |
|---|---|---|
| Your service (your server) | Relying Party (RP) | Issues a challenge (random value) and verifies the returned signature with the public key |
| Browser | Client | Exposes the API, checks the origin against the RP ID, and talks to the authenticator |
| Device, password manager, or security key | Authenticator | Creates the key pair, keeps the private key, verifies the user, and signs |
The RP ID is the domain the passkey is bound to. It is usually the domain of your login page or a parent domain (for example example.com for login.example.com). By design, a passkey can only be used within the scope of its RP ID.
What happens during registration and sign-in
Registration
- Your server builds options containing a challenge, the RP ID, the user's ID, and requirements such as
residentKeyanduserVerification. - The browser passes them to the authenticator through
navigator.credentials.create(). - The authenticator verifies the user (fingerprint, face, PIN) and creates a key pair just for this site.
- The public key and signed data that includes the challenge go back to your server.
- Your server checks the challenge, the origin, the RP ID hash and other fields, then stores the public key against the user.
Sign-in
- Your server issues a fresh challenge.
- The browser passes it to the authenticator through
navigator.credentials.get(). - The authenticator verifies the user and signs data that includes the challenge with the private key.
- Your server verifies the signature with the stored public key and, if it checks out, creates a session.
The private key never leaves the authenticator. Biometric matching also happens on the device; the server only receives a flag saying the user was verified.
How it differs from a password
| Password | Passkey | |
|---|---|---|
| What the server stores | A password hash (a shared secret) | A public key (useless for signing if leaked) |
| Per-site uniqueness | Users can reuse the same one everywhere | A new key pair is created for each site (RP ID) |
| Look-alike sites | Typing it in hands it over | The browser checks the domain, so no signature is produced for the fake domain |
| Strength | Up to the user | Always generated, never guessable |
| Input | Type a string | The device-unlock gesture |
Two differences matter most:
- There is no shared secret. The server keeps only a public key, so a database leak cannot be replayed against other services. Password reuse attacks (credential stuffing) simply do not apply.
- The credential is bound to the domain. The signed data includes the origin the browser verified, and the authenticator picks the key by RP ID. NIST SP 800-63B-4 calls this "verifier name binding," names WebAuthn as an example, and treats it as phishing-resistant. Unlike SMS or app one-time codes, there is nothing for the user to copy into a fake site.
Synced and device-bound passkeys
Passkeys come in two kinds, depending on where they live:
- Synced passkeys are synchronized across a user's devices by the OS or a password manager. Apple says passkeys sync through iCloud Keychain with end-to-end encryption. Google says Google Password Manager syncs passkeys between a user's Android devices and Chrome.
- Device-bound passkeys never leave a single authenticator. Passkeys on a hardware security key are the typical example.
The WebAuthn authenticator data carries BE (Backup Eligibility) and BS (Backup State) flags, so your server can tell whether a passkey is the syncable kind and whether it is currently backed up. Synced passkeys survive a phone upgrade; device-bound passkeys suit cases where the key must stay in one place. Which one fits depends on the use case, and we cover the trade-offs in a separate post.
Signing in on another device (hybrid)
When a user wants to sign in on a computer that has no passkey, the browser can show a QR code that the user scans with their phone, then sign with the phone's passkey. WebAuthn defines this path as the hybrid transport. According to Google's developer documentation, the two devices confirm they are near each other over Bluetooth and the user approves on the phone. No special server-side work is needed.
What you need to decide as a developer
Browsers, authenticators, and a verification library (or an external API) handle the cryptography. Teams tend to get stuck elsewhere:
- How you protect enrollment. A passkey is strong once registered, but confirming who is registering is your job. If you accept new passkeys from sessions that only proved a password, an attacker who stole that password can add their own passkey.
- How recovery works. Decide up front how users who lost their device, or who do not use sync, prove who they are and register again.
- How long passwords stay. Not everyone moves at once. Decide on a cut-off and whether users who have a passkey still see a password field.
The technology choice (build it yourself, use a library, use an external API) can come after these three decisions.
Implementing with SealGate
SealGate is an API and browser SDK for adding passkeys to an existing login. Your login page and user data stay with you; SealGate stores the user ID you pass (external_id), a display name, public keys, and authentication records. Registration and sign-in both take two steps ("get options → run the authenticator in the browser → send the result to verify"), and the SDK's sg.register() and sg.login() handle the browser side. See the docs for details, and adding passkeys to an existing login for the overall flow.
FAQ
Does a passkey send biometric data to the server?
No. Fingerprint or face matching happens on the device. The server receives only a signature and a flag saying whether the user was verified.
Is a passkey the same as a security key?
A security key is one kind of authenticator, and one place a passkey can live. The FIDO Alliance notes that passkeys can be stored on phones and computers as well as on hardware security keys.
What if the public keys on my server leak?
A private key cannot be derived from a public key, so a leaked public key cannot be used to sign in. The data still links users to credentials, so treat it like any other personal data.
Sources
- Web Authentication: An API for accessing Public Key Credentials Level 3 (W3C Recommendation, 2026-08-25)
- FIDO Passkeys: Passwordless Authentication (FIDO Alliance)
- Terms (passkeys.dev)
- NIST SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management (NIST, August 2025)
- About the security of passkeys (Apple)
- Passkeys (Google for Developers)
- Passkeys use cases (Google for Developers)
