WebAuthn And Passkeys
WebAuthn is a W3C standard that defines how a website and a device perform a cryptographic login using public-key credentials. Passkeys are a user-friendly way to store and use those credentials across devices, usually through the browser or an operating system password manager. In practice, a passkey login starts with a challenge from the website, then your device signs that challenge with a private key stored in secure hardware or a protected software store.
For a concrete example, imagine signing into an account on a laptop. The site sends a WebAuthn “registration” or “authentication” request, your browser talks to a platform authenticator (like a phone or built-in secure element), and the authenticator returns a signature plus metadata. The server verifies the signature using the public key it stored during registration. If you later sign in on a phone, the same public key can be used again, as long as the passkey is available on that device.
One small detail that often confuses people: WebAuthn is the protocol, while passkeys are the user-facing credential management and sync experience. The protocol messages are defined by WebAuthn, and the “sync” part depends on platform services and browser implementations, which can differ by vendor and OS version (I noticed this while testing Chrome 126 on macOS 14, where prompts and fallback behavior varied by site).
Common Misunderstandings
People often treat passkeys as “passwords that look different,” but the security model is different. A password is a shared secret that the server can verify by comparing hashes; a WebAuthn credential uses a public key stored on the server and a private key kept on the authenticator. That means the server never receives the private key, and the login response is a signature over a server-provided challenge.
Another misunderstanding is assuming WebAuthn works the same everywhere. WebAuthn depends on a “relying party” (the website), a “client” (the browser), and an “authenticator” (a device component that can sign). If a browser lacks support for the required WebAuthn features, or if the authenticator is missing, the flow can fall back to other methods. Those fallbacks vary by site policy and browser settings, and some sites disable fallback after enabling passkeys.
Credential storage and sync also create dependencies. Passkeys usually rely on platform account services to sync credentials between devices, and those services can require the same OS account or cloud sign-in. If you change phones, switch browsers, or disable sync, you might still have the passkey on one device but not another. That gap is where most “it stopped working” support tickets come from, not from cryptography failing.
Finally, people sometimes miss that WebAuthn is tied to origin and relying-party identifiers. A credential created for one domain is not meant to authenticate to a different domain, even if the UI looks similar. This origin binding is a core protection against phishing sites that try to reuse credentials.
How To Use Passkeys Safely
Register With Multiple Devices
When you enable passkeys for an account, add more than one authenticator. A practical approach is to register on your primary phone and your main computer, then add a second device if the account supports it. Many services let you manage multiple passkeys per account; if you only register one device, losing access to that device can force a recovery path that may take days.
Look for settings that show “passkeys” or “security keys” and confirm how many credentials are listed. If the site offers a “backup” option, use it. I’ve seen accounts where the UI says “passkey added” but only one device is actually registered, because the browser prompt was dismissed early.
Understand Recovery Options
Before you rely on passkeys, review the account’s recovery methods. WebAuthn does not replace account recovery; it changes the login step. Common recovery options include backup codes, email-based verification, phone numbers, or identity checks. If your account uses only passkeys and removes other factors, recovery can become slower and more restrictive.
Use a simple test: sign out, then try logging in from a different device you trust. If you cannot complete the login without the original device, you do not yet have a resilient setup. Some services also support “security key” registration (a hardware authenticator), which can be a better fallback than relying on a single phone.
Check Browser And OS Support
WebAuthn support depends on browser versions and platform authenticator capabilities. If you see repeated prompts that end in errors, confirm that your browser supports WebAuthn in the mode the site requires. For example, some sites require resident credentials or specific attestation behaviors, and older browsers may not meet those requirements.
As a practical step, update your browser and OS, then retry registration. On Windows, authenticator behavior can differ between built-in platform authenticators and external security keys. On macOS, the Secure Enclave and keychain integration can change how prompts appear, and the exact wording can differ by browser release (I saw this in Firefox 129 where the prompt text differed from Chromium-based browsers).
Watch For Phishing UI
Passkeys reduce credential theft, but phishing still exists. A phishing site can still trick you into approving a signature prompt if it can get you to interact with the prompt on a compromised device. The origin binding helps, but users can still be socially engineered into approving the wrong request.
Verify the domain shown in the prompt and compare it to the site you intended to visit. If the prompt appears on a domain you did not expect, cancel it. This is one place where “it asked me to approve” is not enough evidence; the domain and account name matter.
Educational Case Examples
Case: Phone Upgrade With Sync
Alex enabled passkeys on a phone and a laptop. After upgrading the phone, Alex kept the same OS account and re-enabled password manager sync. The laptop passkey continued to work, and the new phone passkey appeared after a short sync delay. Alex then tested sign-in on a third device and confirmed the passkey was present before deleting the old phone.
The lesson is not that passkeys “magically transfer,” but that sync depends on platform services and account continuity. If Alex had switched OS accounts or disabled sync, the new phone might not have received the passkey, even though the laptop still worked.
Case: Recovery After Lost Device
Sam registered a passkey only on one phone. The phone was lost, and the account recovery relied on email verification plus a time delay. Sam recovered the account after completing the email steps, then re-registered passkeys on a new phone and a laptop. The login experience returned to normal after the new credentials were created.
This scenario highlights a realistic limitation: passkeys remove password entry, but they do not remove the need for a recovery path when you lose the authenticator that holds the private key.
Passkeys Vs Other Logins
| Method | What the server verifies | Main failure mode | User actions to manage risk |
|---|---|---|---|
| Passwords | A hash of a shared secret | Reuse, phishing, credential stuffing | Use a password manager, unique passwords, and 2FA |
| Passkeys (WebAuthn) | A signature over a server challenge using a public key | Loss of the device/authenticator without recovery options | Register multiple devices and review recovery before switching |
| SMS codes | A one-time code sent to a phone number | SIM swap, interception, delayed delivery | Prefer authenticator apps or passkeys when available |
| Security keys | A signature using a hardware-held private key | Physical loss without backups | Keep a spare key and store it separately |
Common Mistakes
One frequent mistake is enabling passkeys and then removing all other login methods without checking recovery. If the only authenticator is on a lost phone, the account becomes dependent on email or identity checks that can take time and may require documents.
Another mistake is assuming that “passkey works on my phone” means it works on every browser. Some sites require specific WebAuthn behaviors, and some browsers treat cross-device credential discovery differently. If you travel or use shared computers, test sign-in on the devices you actually use.
People also approve prompts too quickly during phishing attempts. Passkeys change the credential type, but they do not remove the need to verify the domain and account name shown in the prompt. A prompt that appears on the wrong domain is a reason to cancel, not a reason to proceed.
Finally, users sometimes confuse WebAuthn with “attestation” and assume it affects privacy in the same way everywhere. Attestation handling varies by site configuration and authenticator behavior, and the exact privacy impact depends on what the server requests and stores. If a site offers attestation options, read the description carefully; if it does not, you can only infer behavior from what the site reports in its documentation.
FAQ
Is WebAuthn the same as passkeys?
WebAuthn is the protocol standard for public-key authentication. Passkeys are a credential management and sync experience that typically uses WebAuthn credentials under the hood.
Do passkeys work without internet?
Passkey authentication requires the website’s challenge and server verification, so the login flow needs network access. Some device-side steps can happen offline, but the full sign-in requires the server.
What happens if I lose my phone?
If you registered passkeys on multiple devices or have backup options, you can sign in elsewhere and re-register. If you registered only on the lost device and recovery is limited, you must use the account’s recovery process.
Can a passkey be used on a different website?
Passkeys are bound to the relying party’s origin and identifier, so a credential created for one domain is not meant to authenticate to another domain.
Why do some sites still ask for passwords?
Some sites keep passwords for recovery, for users who cannot use passkeys, or because passkeys are not enabled for that account yet. The site’s authentication policy determines which methods are offered.
Author's Insight
WebAuthn’s core value is that it replaces shared-secret verification with public-key signature verification tied to a specific origin. Passkeys build on that by making credential creation, storage, and cross-device availability easier through platform services. The practical risks are not “cryptography failing,” but loss of the authenticator, misconfigured recovery, and user approval of prompts from unexpected domains. If you treat passkeys as a login factor that still needs a recovery plan, the setup process becomes much less fragile.
Key Takeaways
- WebAuthn is the authentication protocol; passkeys are the credential experience that usually uses WebAuthn.
- Passkey logins rely on a server challenge and a signature verified with a stored public key.
- Register passkeys on more than one device and review recovery methods before removing other login options.
- Verify the domain shown in the prompt during sign-in attempts, since phishing still targets user approval.
