Passkeys Explained: How They Work, Login and Recovery

A passkey lets you sign in with a cryptographic credential instead of sending a password to a website. The site holds a public key. Your authenticator controls the matching private key and uses it to approve a fresh sign-in challenge.

You normally see a fingerprint, face, PIN or security-key prompt. Underneath it are two operations: registering a credential and using it to authenticate. This guide combines the practical overview with the login flow, including what is signed, what the server checks and what happens if you lose a device.

What a passkey is

The FIDO Alliance describes passkeys as FIDO credentials that can be synced across devices or bound to an individual authenticator. A passkey is not necessarily stored only in hardware, and it is not simply a password hidden behind biometrics.

Three roles participate:

• Relying party: the website or service accepting the credential.
• Client: the browser or operating system coordinating the request.
• Authenticator: the component managing the credential, such as a security key, platform provider or password manager.

The site does not receive your fingerprint or face scan. User verification happens through the authenticator and its platform. The site receives a cryptographic result with information about the ceremony.

A synced passkey may be encrypted and replicated through its provider. A device-bound passkey stays with its authenticator. Both can support phishing-resistant sign-in, but their backup and recovery paths differ.

Registration: how a website gets your public key

WebAuthn calls credential creation a registration ceremony. In the W3C specification, the browser operation is called navigator.credentials.create().

1. The site issues a fresh challenge. It associates that challenge with your pending registration.
2. The site supplies credential options. These include its relying-party identifier, a user identifier, acceptable algorithms and authentication requirements.
3. The client checks the request’s scope. It validates that the requesting origin is permitted to use that relying-party identifier.
4. The authenticator obtains the required consent and verification. A simple touch can establish presence; a PIN or biometric can establish user verification.
5. A credential is created for the relying party. The private key is controlled by the authenticator or credential provider; the public key and credential identifier are returned.
6. The site validates the result and saves the public credential. It checks the challenge, origin and required registration data before linking the credential to your account.

The website’s credential record contains a public key rather than a reusable password secret. That reduces one consequence of a stolen credential table, although the account and other site data still need protection.

Login: how passkeys work step by step

Authentication uses navigator.credentials.get(). The user-facing action may simply be choosing an account and approving the device prompt.

1. The site generates a new challenge. It must relate to the current authentication request.
2. The client locates an eligible credential. The site can supply acceptable credential IDs; discoverable credentials can also allow account selection without typing a username first.
3. The client checks the relying-party scope. A page cannot freely request credentials for an unrelated service.
4. The authenticator performs the requested interaction. The verification requirement depends on the site’s policy and the authenticator’s capabilities.
5. The authenticator signs an assertion. The result binds the authentication data to the client data for this request.
6. The site verifies before granting access. It checks the stored public key, challenge, origin, relying-party identifier and required flags.

Signing and checking are separate responsibilities. A valid signature alone is not enough if the server accepts an unexpected challenge or ignores the requesting origin. The protection depends on the complete, correctly implemented ceremony.

What actually gets signed?

A WebAuthn authentication assertion signs authenticator data followed by a hash of the client data. This is the mechanism-level detail behind the shorthand phrase “signing a challenge.”

Client data includes the ceremony type, challenge and origin. The type distinguishes credential creation from authentication. The challenge ties the response to the request. The origin identifies the context in which the browser performed it.

Authenticator data includes a hash of the relying-party identifier, flags and a signature counter. Together, these structures let the service check where the assertion belongs and what authentication occurred.

The private key is not sent to the website as part of this exchange. For synced passkeys, that does not mean the key can never leave a single physical device: encrypted synchronization is a separate provider operation.

The signature counter also needs careful interpretation. Some authenticators report zero, and synced credentials do not necessarily provide a simple ever-increasing counter across devices. A counter is not an infallible detector of a copied credential.

User presence, user verification and backup flags

The login-flow detail matters because a touch is not the same as authenticating a particular user.

A service can use these signals when applying its authentication policy. BE and BS describe the credential’s backup properties; they do not reveal a complete inventory of the user’s devices.

When a site offers the option, registering another credential can reduce dependence on one authenticator. Whether that is necessary for a particular account also depends on the provider’s recovery route and the site’s fallback methods.

Why passkeys resist phishing

Passkeys are scoped to a relying party, and the authentication includes origin information checked by the client and server. This makes the ordinary trick of asking a user to type a reusable secret into a lookalike page ineffective against a correctly implemented passkey ceremony.

Avoid the shortcut that a passkey is bound to one exact hostname forever. The relying-party identifier and the full browser origin are related but distinct concepts; valid use can include allowed subdomains and explicitly supported related-origin arrangements.

NIST’s authentication guidance distinguishes phishing-resistant cryptographic methods from manually entered one-time codes. It also makes authenticator assurance depend on the authentication system, not on a product simply calling its feature a passkey.

That leaves other risks. Account recovery, authorized sessions and compromised devices still matter. Phishing resistance is a property of the sign-in method, not a promise that every way into an account has the same strength.

Which threats do passkeys actually stop?

Passkeys stop credential phishing and the reuse of passwords leaked in another site’s breach, because there is no secret to type and nothing reusable on the server. They help only partly against someone close to you who knows your phone passcode, and little against malware already running on your unlocked computer.

1. A fake login page. A text about a held parcel links to a perfect copy of your bank’s sign-in. A password, and even a six-digit code from SMS or an authenticator app, can be typed into the copy and relayed to the real bank. NIST SP 800-63B-4 says authenticators that rely on manual entry shall not be considered phishing resistant, because the typed value isn’t bound to the session. A passkey won’t appear on the lookalike domain at all. Winner: any passkey, synced or hardware.
2. A breached shop. A store you last used years ago leaks its customer database. A reused password gets tried everywhere. A passkey left only a public key unique to that account, which unlocks nothing. Your address and order history still leak; passkeys protect the login, not the data a company keeps. Winner: passkey.
3. An ex who knows your passwords. Your Apple Account password alone won’t pull your iCloud Keychain onto their device, because recovery also wants an SMS code and a device passcode. Google likewise wants your Password Manager PIN or Android screen lock. Someone who has watched you type your phone passcode and can pick up the phone, though, can use every passkey on it. Change the passcode, review signed-in devices on your Apple or Google account, and put a hardware-key passkey on your primary email. Winner: a hardware key for email; synced passkeys elsewhere, after a passcode change.

What passkeys don’t fix

A passkey is only as strong as the weakest other way into the account. If the site still offers a reset by email link or SMS code, an attacker can skip the passkey and use the reset. And malware on your unlocked computer can ask your passkey provider to sign in for it, no fake page required.

That second risk is documented. On August 3, 2026, Palo Alto Networks’ Unit 42 described three attacks on Google Password Manager passkeys in Chrome on Windows. Each starts with malware running as an ordinary user, and none breaks the cryptography. In one, the attacker got a sign-in with the “user verified” flag unset, which eBay accepted until it fixed its checks and GitHub rejected. Unit 42 also reported that the master key protecting synced passkeys remained readable in Chrome’s memory, with no way to rotate it, even after Google stripped it from Chrome’s logs. Passkeys are no substitute for OS updates or for care over what you install.

NIST draws a related line: syncable authenticators “SHALL NOT” be used at AAL3, its top assurance level, which demands keys that can’t be exported. Synced passkeys are permitted at AAL2 and below. That is the argument for a hardware key on your most valuable account.

Synced passkeys, password managers and hardware keys

Supported clients and platforms vary. A manager installed on a device does not automatically guarantee that every app or browser can use every stored credential.

Where each provider keeps the key, and how you get it back

• Apple. Apple’s passkey security page says iCloud Keychain is end-to-end encrypted with keys Apple doesn’t know, and it requires two-factor authentication on your Apple Account. If you lose every device, recovery runs through keychain escrow, which needs your Apple Account credentials, an SMS code and a device passcode, with 10 attempts before the escrow record is destroyed.
• Google. Since September 2024, Google Password Manager has saved passkeys on Windows, macOS, Linux and Android and synced them end-to-end encrypted. A new device needs your Google Password Manager PIN (six digits by default, or a longer alphanumeric one) or your Android screen lock.
• Password managers. Vaults such as Bitwarden and 1Password hold passkeys next to passwords and sync across Apple, Android and Windows. The vault’s own login then protects everything; how a password manager works explains that encryption.
• Hardware keys. A YubiKey on firmware 5.7.4 or later holds up to 100 passkeys. Nothing syncs, so enroll a spare.

If you are choosing a vault for stored passkeys, the Bitwarden vs 1Password comparison covers the account and export choices. For a separate second factor protecting the vault itself, use the YubiKey enrollment guide.

Keep those two jobs distinct. Bitwarden’s passkey documentation separates saving website passkeys, logging in with a passkey and using one for two-step login. A passkey for a website inside the vault does not automatically protect the vault’s own account.

Signing in from a device that has no passkey

Cross-device authentication lets a nearby phone supply a credential when the computer does not hold one. The computer may display a QR code that you scan before approving the sign-in on the phone.

The FIDO hybrid flow uses Bluetooth for a proximity check. Bluetooth availability is therefore part of the expected workflow, not merely a preference for how the screen looks. Compatibility also depends on the browser, operating system and credential provider.

Apple’s passkey security page describes using a nearby device for supported sign-ins. This is one reason ecosystem boundaries do not mean a passkey can never be used from another platform.

Distinguish using a phone to approve one login from transferring the credential into the computer’s vault. A successful cross-device sign-in does not itself prove that you now have a second stored copy or a new recovery route.

Passkeys versus TOTP authentication codes

A device may perform its local cryptographic operation without fetching a secret from the website. The website still needs to validate the sign-in. Neither method makes an online account available without its service.

Use the stronger supported method you can recover reliably. For accounts without passkey support, the password security fundamentals guide remains relevant.

Moving passkeys and backing up credentials

Do not assume a password CSV export contains passkeys. Bitwarden’s export guide distinguishes JSON-supported data from the more limited CSV fields. 1Password’s export guide describes supported mobile passkey transfer paths separately from desktop file export.

On iOS, iPadOS, macOS and visionOS 26, Apple lets you transfer passkeys directly between participating credential managers using a data format built with the FIDO Alliance. Per Apple’s WWDC25 session, the transfer is user-initiated, secured by Face ID or similar, and leaves no unencrypted export file on disk.

Before changing providers, identify which credentials must move and confirm that the destination supports the transfer. Where transfer is unavailable, a website may let you register a new passkey while you still have access. Keep the working credential until the replacement is verified.

For file-based backups or migration, protect the exported material according to its actual encryption state. Calling a file a backup does not make it encrypted.

How to start without losing account access

1. Pick an account that supports passkeys and review its recovery settings.
2. Choose where to store the credential before accepting the prompt.
3. Register it, then confirm sign-in from the devices you intend to use.
4. Prepare another credential or the provider’s supported recovery method.
5. Retain the existing password until you understand the site’s fallback behavior.

Removing a saved password entry from your manager does not disable password login at the website. Change account settings only after you have verified the intended access and recovery routes.

Worked example: a passkey for your Google Account

Start with the account that controls your email, since its reset links unlock everything else. Google’s help page lists Android 9 or iOS 16 on phones, and Windows 10, macOS Ventura or ChromeOS 109 on computers, as minimums. Budget ten minutes, including the checks.

1. Use a device you own. Google advises creating passkeys only on devices you personally own and use.
2. Pick the storage first. On an iPhone or Mac, turn on iCloud Keychain, as Google’s page instructs. To use a password manager instead, enable it as your passkey provider in the phone’s settings first.
3. Create it. Go to myaccount.google.com/signinoptions/passkeys, choose Create a passkey, and unlock your device when prompted.
4. Keep your fallback. Leave your password and 2-Step Verification in place for now.

Check it worked:

• Sign out and back in. You should see a passkey prompt and a fingerprint, face or PIN request instead of a password field.
• In your Google Account, open Security & sign-in, then Passkeys and security keys, and confirm the new entry is listed. That is also where you remove a lost device’s passkey.
• Open your provider (Apple Passwords, Google Password Manager or your vault) and confirm it now shows a passkey for Google.
• On a computer without the passkey, choose to sign in with a phone, turn on Bluetooth, and scan the QR code.

For a dry run first, webauthn.io, a Duo Labs demo, lets you register and sign in with a throwaway username. passkeys.directory, a community index provided by 1Password, shows which of your other accounts support passkeys.

The browser-password comparison helps with provider choice. For device and account risks specifically, read whether browser password managers are safe.

FAQ

How do passkeys work without sending a password?

The website sends a challenge, your authenticator signs authentication data for that request, and the site verifies the result with a stored public key. Your private key is not sent to the website.

Are passkeys the same as fingerprint login?

No. A fingerprint can authorize use of a passkey locally, but the website receives a cryptographic authentication result rather than the fingerprint. Other verification methods, such as a PIN, can also authorize the credential.

What happens if I lose my phone?

Synced passkeys survive a lost phone, because encrypted copies live with your provider and on your other devices: sign in to your Apple, Google or password manager account on a replacement to restore them. A passkey on a lost hardware key is gone, so remove it from the account and sign in with your spare. Either way, recovery depends on what the account supports, so prepare the route before losing your main device.

Can a passkey be stored on a YubiKey?

Yes, a compatible security key can hold device-bound passkeys. They do not automatically sync to a spare key, so register another credential separately if you need a backup.

Are passkeys safer than 2FA codes?

Yes, against phishing they are clearly safer. An SMS or authenticator-app code is typed by hand, so a fake page can capture and relay it, and NIST doesn’t count manually entered codes as phishing resistant. A passkey is bound to the real site’s domain, so a lookalike page has nothing to collect.

Can I have more than one passkey for the same account?

Usually, yes. Google and many other services let you register several, for example one in iCloud Keychain, one in a password manager and one on a hardware key. Each is a separate key pair, so removing a lost device’s passkey leaves the others working. Check the account’s passkey list to see what’s registered.

Do I still need a password manager if I use passkeys?

Yes, for now. Plenty of sites still accept only passwords, and many that offer passkeys keep a password as a fallback, so you need strong, unique passwords stored somewhere safe. A dedicated manager can also hold your passkeys and sync them across Apple, Android and Windows devices instead of one company’s ecosystem.