Skip to content
atlas

Passkey

Also known as: FIDO credential, discoverable credential

A login without a password, where your device proves who you are with a secret key that never leaves it.

Draft - this entry has not been reviewed yet.

Formal

A credential built on public-key cryptography under the FIDO standards, where the device keeps a private key for each site and signs a fresh challenge with it after the user unlocks with a fingerprint, face or PIN; the site stores only the public key.

In plain English

Like a key that never leaves your key ring and turns only in your own front door - there is no code to say out loud, so a fake door gets nothing from you.

In practice

A case officer at a Danish region opens the staff portal on her work laptop and touches the fingerprint reader when asked to use her passkey; she is in with nothing typed and nothing a fake site could capture.

Why it matters

Passwords get guessed, used again and typed into fake pages; a passkey works only on the real site, and the server holds no shared secret worth stealing.

How to put it into practice

The usual steps, in order. Adapt them to your organisation.

  1. Decide where passkeys come first, for example staff sign-in through the identity provider, administrators and the organisation's own customer-facing login, and name an owner for the rollout.
  2. Decide which passkey types each group may use - synced passkeys in a password manager for most users, device-bound passkeys on security keys or in an authenticator app with attestation for administrators.
  3. For your own applications, use a maintained WebAuthn server library, set the RP ID to your registrable domain, and verify challenge, origin and signature on every sign-in instead of writing the checks yourself.
  4. Let users register a passkey only after a strong sign-in, allow several passkeys per account so a lost device is not a lock-out, and show each passkey with a name and last-used date.
  5. Offer passkeys in the normal sign-in flow through autofill and in account settings, run a pilot group first, and measure how many users sign in with a passkey.
  6. Secure account recovery as carefully as sign-in, with identity checks in person or through MitID, because an attacker will go for the weakest fallback.
  7. Once most users have a passkey, require phishing-resistant sign-in for sensitive systems through conditional access, and phase out SMS codes and passwords as fallbacks.
  8. Review every quarter which accounts still lack a passkey, which weak methods are still enabled and how recovery requests are handled.

Common pitfalls

  • Adding passkeys while leaving password and SMS sign-in enabled forever, so attackers simply phish the old method instead.
  • Allowing only one passkey per account, so a lost or replaced phone sends every user to the service desk.
  • Giving administrators synced passkeys without checking whether policy requires device-bound keys for high-assurance access.

Good guides

Technical deep dive

A passkey is a FIDO2 credential, meaning W3C Web Authentication (WebAuthn) between the relying party and the browser plus the FIDO Alliance's Client to Authenticator Protocol (CTAP 2) between the browser and an external authenticator. Technically it is a discoverable credential, formerly called a resident key: the authenticator stores the private key together with the RP ID and a user handle, so sign-in can begin without a user name, typically through autofill-style conditional mediation. WebAuthn Level 2 became a W3C Recommendation in April 2021, and Level 3 followed on 25 August 2026.

At registration the site calls navigator.credentials.create() with a random challenge, its RP ID (a registrable domain such as example.dk), a user ID and acceptable algorithms as COSE identifiers, usually -7 (ES256) and -257 (RS256), and requests residentKey "required" plus a user-verification preference. The authenticator generates a fresh key pair scoped to that RP ID and returns authenticator data containing the SHA-256 hash of the RP ID, a flags byte, a signature counter, the credential ID and the public key, optionally with an attestation statement. At sign-in, navigator.credentials.get() asks the authenticator to sign the authenticator data concatenated with the hash of clientDataJSON, which the browser fills with the type, the challenge and the actual origin. The server verifies the signature with the stored public key and checks challenge, origin, RP ID hash and the UP (user present) and UV (user verified) flags.

Phishing resistance comes from that binding: the browser, not the user, asserts the origin, and the authenticator will not even offer a credential whose RP ID does not match the site, so a look-alike domain gets nothing to relay. This is verifier-name binding in the sense of NIST SP 800-63B-4 §3.2.5. Server-side, only public keys are stored, so a database breach yields nothing usable for login.

Passkeys are either synced or device-bound. After the joint commitment by Apple, Google and Microsoft in May 2022, platforms began syncing passkeys through iCloud Keychain, Google Password Manager and third-party password managers; the BE (backup eligible) and BS (backup state) flags reveal this, and synced authenticators often report a signature counter of zero, which makes counter-based clone detection meaningless. SP 800-63B-4 accepts syncable authenticators up to AAL2 but not at AAL3, which requires a non-exportable key, so administrator and high-assurance use calls for device-bound passkeys on security keys or platform TPMs, often with attestation to verify the model. Cross-device sign-in uses the hybrid transport, a QR code plus a Bluetooth proximity check, so a phone can authenticate a laptop. The residual risks are the weakest remaining recovery or fallback method (SMS or password left enabled), compromise of the sync account, and theft of the session cookie issued after a perfectly phishing-resistant login.

What to learn first

Everything this builds on, foundations first.

  1. Cryptographic key
  2. →Digital identity
  3. →Credential
  4. →Public-key cryptography
  5. →Authentication
  6. →Passkey

Relationships

A kind of
Credential
Don't confuse with
One-time password (OTP)
Alternative to
Password

Sources & further reading

Standards & official texts

Official documentation

Where this data comes from

This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.

See the review queueSuggest a correction on GitHubThis term as JSON

Check yourself

Loading…

Atlas is in beta.