Passkeys explained: safer sign-in with WebAuthn
Understand how passkeys replace passwords, how synced and device-bound credentials differ, and how to adopt them without losing account access.
How a passkey signs you in
A passkey is a cryptographic credential created for one account on one website or app. Your device keeps a private key, while the service stores the matching public key. During sign-in, the service sends a fresh challenge and your device signs it after you unlock the credential. The private key does not need to be typed, copied or sent to the service.
The browser and operating system use the Web Authentication API, usually called WebAuthn, to connect the website with an authenticator. That authenticator may be built into a phone or laptop, held in a password manager, or stored on a hardware security key. A fingerprint, face scan, device PIN or security-key touch confirms that the person present is allowed to use it. Biometric data stays with the device or authenticator; the website receives the signed response rather than a copy of your fingerprint or face.
A passkey is bound to the legitimate website identity. A convincing phishing page on another domain cannot ask the authenticator to produce a valid response for the real domain. Each account also gets a distinct key pair, so a database leak at one service does not reveal a reusable secret that works elsewhere. These properties remove the common habits of reusing passwords and entering them into lookalike pages.
Choose between synced and device-bound passkeys
A synced passkey can be made available on other devices through an account-based credential provider. This is convenient when a person owns several phones or computers and wants recovery to follow the security controls of that provider account. The exact availability depends on the operating systems, browsers and password manager in use, so test the combinations that matter before removing an older sign-in method.
A device-bound passkey remains on the authenticator where it was created. Hardware security keys are a common example. They suit administrators, regulated environments and other cases where portability must be tightly controlled. They also require a deliberate backup plan: losing the only security key must not permanently lock out the legitimate owner. Registering two keys and storing the spare securely is a practical pattern.
Passkeys can also support cross-device sign-in. A computer may display a QR code that a nearby phone scans, allowing the phone to approve the sign-in without copying the passkey to the computer. Start this flow only from the site you intended to visit, read the phone prompt and reject an unexpected request. A QR flow proves proximity and possession; it does not make an untrusted computer safe for sensitive work after sign-in.
Adopt passkeys without creating a recovery problem
Begin with important accounts that clearly support passkeys in their security settings. Confirm the domain, create the passkey on a device you control and give it a recognizable label if the service offers one. Sign out and test a fresh sign-in before changing anything else. On a shared device, read whether the credential will be saved to the device, an operating-system account or a password manager shared by several profiles.
Review every recovery route at the same time. Remove obsolete phone numbers and email addresses, protect the recovery mailbox, save recovery codes offline and register a second authenticator where the account supports it. A strong passkey can still be undermined by an easily hijacked fallback process. For business accounts, document who can recover an employee or administrator account and how identity is checked.
Do not immediately delete a working password or sign out every trusted session. First confirm that the passkey works on the browsers and devices you actually use, and that recovery works if the primary device is unavailable. Some services use a passkey as one option while keeping a password; others allow passwordless operation. The account's security page should be the authority for which methods remain active.
Plan a passkey rollout for a website or team
A service adding passkeys should keep registration and sign-in language simple. Tell users where the passkey will be stored, let them name credentials, show the date and approximate device for each one, and provide a way to revoke a lost authenticator. Offer passkey creation after a trusted sign-in and require a recent verification before changing recovery details. Avoid presenting a passkey as a generic code that users should share.
Test user-verification requirements, discoverable credentials, duplicate registration, cancelled prompts, lost devices and cross-device sign-in. Check accessibility with keyboard and screen-reader flows. Teams should also decide whether managed employees may sync work passkeys into personal accounts, whether hardware keys are required for privileged roles, and how offboarding revokes credentials and active sessions.
WebAuthn Level 3 is a W3C Recommendation, but support for individual capabilities can still vary by platform version and authenticator. Use feature detection and current browser documentation rather than assuming every device behaves alike. Keep a monitored recovery path during migration, measure successful sign-ins and recovery requests, and reduce older authentication methods only after real users can complete the new flow reliably.
Quick checklist
- Create passkeys only from the account's real domain and security settings.
- Test a fresh sign-in before removing an existing method.
- Protect the provider account that synchronizes passkeys.
- Register a spare authenticator for important or administrative accounts.
- Review recovery email, phone, codes and support procedures.
- Revoke credentials for devices that are lost, sold or no longer managed.
Primary references
Standards and platform support change. Use these authoritative sources to check the current specification and migration guidance.