📅 Published 1 May 2026

Passkeys have crossed the adoption threshold in 2026. Apple, Google, and Microsoft have integrated passkey support into their operating systems and browsers. Major services — Google, Apple, Microsoft, Amazon, GitHub, PayPal — support passkey authentication. The FIDO Alliance's specifications are stable. The developer tooling has matured from "technically possible" to "practically reasonable." And the security benefits are unambiguous: passkeys are phishing-resistant by design, cannot be reused across services, and eliminate the credential stuffing attacks that plague password-based authentication.

This page covers the practical implementation of WebAuthn and passkeys for web applications in 2026: the registration and authentication flows, the platform differences that affect user experience, the server-side verification requirements, and the migration strategy for existing password-based systems. The page is part of the security section and connects to the privacy and security topic hub.

How passkeys work​

A passkey is a FIDO2 credential — a public-private key pair where the private key is stored on the user's device and the public key is registered with the service. Authentication uses a cryptographic challenge-response: the server sends a random challenge, the authenticator signs it with the private key, and the server verifies the signature with the stored public key. The private key never leaves the device.

The key property that makes passkeys phishing-resistant: the credential is bound to the origin (domain) where it was registered. A phishing site at faceb00k.com cannot request a credential registered at facebook.com — the authenticator refuses because the origin does not match. This is enforced by the authenticator hardware/software, not by user judgement.

Platform authenticators vs. roaming authenticators​

Platform authenticators are built into the device: Touch ID, Face ID, Windows Hello, Android biometrics. The passkey is stored on the device and synchronized via the platform's cloud keychain (iCloud Keychain for Apple, Google Password Manager for Android/Chrome, Microsoft account for Windows).

Roaming authenticators are external hardware keys (YubiKey, Titan Security Key). The passkey is stored on the physical key and is not synchronized. Hardware keys provide the strongest security guarantee (no cloud sync means no cloud-based compromise vector) but reduce convenience (lose the key, lose access).

Registration flow​

The WebAuthn registration (credential creation) flow:

// Server generates options
const options = {
  challenge: new Uint8Array(32), // Random challenge from server
  rp: {
    name: 'Your Service',
    id: 'example.com',        // Relying party ID (domain)
  },
  user: {
    id: userIdBuffer,          // Opaque user ID (not email)
    name: 'user@example.com',
    displayName: 'User Name',
  },
  pubKeyCredParams: [
    { alg: -7, type: 'public-key' },   // ES256
    { alg: -257, type: 'public-key' }, // RS256
  ],
  authenticatorSelection: {
    residentKey: 'required',           // Passkey (discoverable credential)
    userVerification: 'preferred',     // Biometric/PIN if available
  },
  timeout: 60000,
};

// Browser prompts user to create passkey
const credential = await navigator.credentials.create({
  publicKey: options,
});

// Send credential.response to server for verification and storage

The server must verify:

1. The clientDataJSON contains the correct challenge and origin
2. The attestationObject contains a valid public key
3. The credential ID is unique (not already registered)
4. The rpIdHash matches the expected relying party ID

Authentication flow​

// Server generates authentication options
const options = {
  challenge: new Uint8Array(32), // Fresh random challenge
  rpId: 'example.com',
  allowCredentials: [],          // Empty for discoverable credentials
  userVerification: 'preferred',
  timeout: 60000,
};

// Browser prompts user to select and authenticate with a passkey
const assertion = await navigator.credentials.get({
  publicKey: options,
});

// Send assertion.response to server for verification

With discoverable credentials (passkeys), the allowCredentials array is empty — the authenticator presents all credentials stored for this origin and the user selects one. This enables username-less authentication: the user clicks "Sign in with passkey," authenticates biometrically, and is signed in without typing anything.

Cross-device authentication​

The most complex user flow: a user has a passkey on their phone and wants to sign in on a laptop that does not have the passkey. WebAuthn supports this via the "hybrid" transport:

1. The laptop displays a QR code
2. The user scans it with their phone
3. The phone authenticates the user via biometrics
4. The phone sends the signed assertion to the laptop via Bluetooth Low Energy (BLE)
5. The laptop completes authentication

This flow works across platforms (Android phone to Windows laptop, iPhone to Chromebook) because it uses the FIDO2 CTAP 2.2 hybrid transport protocol. In practice, the UX is acceptable but not seamless — the QR scan and Bluetooth pairing add friction compared to native platform authenticator use.

Server-side implementation​

Use a maintained library rather than implementing WebAuthn verification from scratch. The cryptographic verification is straightforward but the attestation parsing and edge cases are numerous.

Node.js: SimpleWebAuthn (@simplewebauthn/server) is the most mature option. It handles registration and authentication verification, including attestation format parsing.

Python: py_webauthn provides equivalent functionality.

Go: go-webauthn/webauthn is the standard library.

Store the following per credential in your database:

• Credential ID (unique identifier)
• Public key (in COSE format)
• Sign count (for detecting cloned authenticators)
• User ID association
• Transport hints (for allowCredentials optimisation)
• Creation timestamp

Migration from password-based authentication​

The practical migration path for existing services:

1. Add passkey as an additional authentication method. Do not remove passwords immediately. Let users register passkeys alongside their existing credentials.

2. Prompt passkey registration after password login. After a successful password login, prompt the user to create a passkey for faster future authentication. Make it easy to dismiss — forced registration creates friction.

3. Prefer passkeys for returning users. If a user has a registered passkey, present passkey authentication first with a "Use password instead" fallback.

4. Track passkey adoption metrics. Monitor the percentage of users with registered passkeys, passkey authentication success rates, and fallback-to-password rates.

5. Consider password removal for high-adoption segments. When passkey coverage is high enough (and recovery flows are robust), offer users the option to remove their password entirely.

The TLS adoption patterns documented in the TLS ratings analysis on this site illustrate how authentication technology transitions play out in practice — gradually, with long tail compatibility requirements.

What passkeys do not solve​

Passkeys eliminate password-related attacks (phishing, credential stuffing, brute force) but do not address all authentication risks:

• Account recovery remains the weakest link. If an attacker can reset authentication via email or SMS, passkeys do not help. Recovery flows must be designed with the same security rigour as primary authentication.
• Session management is unchanged. After passkey authentication, the session token is still vulnerable to XSS, session fixation, and other web application vulnerabilities.
• Cloud sync introduces new trust dependencies. Passkeys synced via iCloud Keychain or Google Password Manager are as secure as those cloud accounts. An attacker who compromises an Apple or Google account gains access to all synced passkeys.

Passkeys are a significant security improvement over passwords. They are not a complete authentication solution — they are the strongest available first factor, and should be combined with robust session management and thoughtful recovery flows.