Passkeys and WebAuthn: What Phishing Resistance Really Means
Understand registration, authentication, domain binding, synchronization, recovery, and the threats passkeys do not eliminate.
Reviewed October 10, 2026. Product interfaces vary; this article explains the WebAuthn security model rather than a specific account provider.
A password is a shared secret that a user can type into the correct site or an impostor site. A passkey replaces that reusable secret with a public-key credential. The private key stays with an authenticator; the service stores a public key. During login, the authenticator signs a fresh challenge for the intended relying party.
This architecture can be phishing-resistant because a fake domain does not receive a valid signature for the real domain. It does not mean every account risk disappears. Recovery processes, device security, session cookies, application bugs, and social engineering still matter.
1. Registration creates a key pair
When a user creates a passkey, the site requests a credential through the browser's WebAuthn API. An authenticator—built into a phone or computer, or provided by a hardware security key—creates a key pair. The service receives a credential identifier and public key. The private key is protected by the authenticator and is not sent to the service.
The authenticator may require local user verification such as a device PIN or biometric. The biometric generally unlocks use of the credential on the device; it is not sent to every website as a fingerprint image. Exact hardware and synchronization behavior depends on the authenticator platform.
2. Authentication signs a fresh challenge
At sign-in, the service generates a challenge that should be unpredictable and used once. The browser and authenticator assemble data that includes the relying-party context. After user presence or verification, the authenticator signs the challenge with the credential's private key. The service verifies the signature with its stored public key.
Because the private key is not revealed and the response changes with the challenge, a database holding public keys does not contain password-equivalent secrets. A captured response should not be reusable for a later fresh challenge.
| Property | Password | WebAuthn passkey |
|---|---|---|
| Secret stored by service | Password verifier or hash | Public key and credential metadata |
| User enters a reusable secret | Yes | No |
| Bound to site identity | User must judge the page | Protocol checks relying-party context |
| Replay of captured response | Possible in weak flows | Fresh challenge is designed to prevent it |
3. Domain binding provides the phishing-resistant step
Suppose an attacker copies a bank's visual design onto a look-alike domain. A victim can accidentally type a password there, and an attacker can relay a one-time code in real time. With WebAuthn, the browser supplies the relying-party identity, and the authenticator scopes credentials accordingly. The impostor origin cannot simply ask for a signature valid for the bank's relying party.
NIST SP 800-63B-4 requires phishing-resistant options at Authentication Assurance Level 2 and phishing-resistant authentication with a non-exportable key at AAL3. “Passkey” is a user-facing term that covers different authenticator arrangements, so assurance depends on implementation, key protection, and policy—not the label alone.
4. Synced and device-bound credentials trade properties
A device-bound credential remains on a particular authenticator, such as a hardware security key. This can provide strong control over where the key exists, but users need backup authenticators and a recovery plan. A synced passkey can be made available across devices through a platform account, improving usability and reducing lockout risk.
Synchronization moves part of the trust boundary to the provider that protects and synchronizes the credential material. NIST's guidance treats syncable authenticators explicitly and places requirements on their use. Organizations should match the choice to threat model, account value, device management, and recovery needs.
5. Recovery can become the weakest path
A service that allows passkey users to recover an account with a weak email link or easily reset password may reintroduce a phishable route. Recovery must handle lost devices without letting an attacker bypass the stronger primary authenticator.
Useful controls include multiple enrolled authenticators, carefully protected recovery codes, reauthentication for adding a new credential, notifications about changes, delay or review for high-risk recovery, and support procedures that do not rely on easily researched personal facts.
6. Sessions still need protection
After authentication, many web applications issue a session cookie. That cookie can act as a bearer secret: whoever possesses it may be treated as the logged-in user until it expires or is revoked. Passkeys prevent a major class of credential phishing, but they do not automatically prevent malware, cross-site scripting, stolen session tokens, or a compromised endpoint.
Applications still need secure cookie settings, short or risk-appropriate session lifetimes, reauthentication for sensitive actions, cross-site request protections, monitoring, and a reliable way to terminate sessions after suspected compromise.
7. Implementation details can defeat a sound protocol
Servers must validate the expected challenge, origin, relying-party identifier, signature, and credential state. Challenges need adequate randomness and single-use handling. Credential registration should be protected against an attacker who already controls a session. Developers should use well-maintained libraries and test negative cases, rather than implementing the cryptography from scratch.
The display name and account-discovery flow also affect privacy. A resident credential can support username-less sign-in, but services should avoid revealing whether an account exists to unauthenticated attackers.
8. A practical migration path
Offer passkeys alongside an existing method, explain where the credential is stored, and encourage users to register more than one recovery-capable authenticator. Inventory every fallback path. For administrators, separate workforce requirements from consumer usability and document which authenticator types meet the required assurance.
Track adoption, successful login rates, recovery rates, and suspected account takeovers. Do not measure success only by the number of created passkeys. A secure method that users cannot recover responsibly may lead support staff to create a weaker bypass.
Passkeys change the login ceremony in an important way: the user no longer transports a reusable website secret. Their strongest benefit comes from origin-bound public-key proof. Their safe deployment still depends on the surrounding account lifecycle—from enrollment to sessions, recovery, and revocation.