Passkeys change what a website needs to keep

A password works because a person and a service share knowledge of a secret. A passkey changes that arrangement: authentication uses a pair of cryptographic keys, with the service holding the public key rather than the secret needed to sign in.

The sign-in gesture is not the credential

The familiar part may be a fingerprint, facial recognition or a device PIN. Google’s documentation describes these as ways to use the device’s screen lock during a passkey sign-in. The credential used with the service is the cryptographic key pair, not a new password that happens to be typed by your face.

FIDO distinguishes synced passkeys from device-bound passkeys. The former can be made available through a passkey provider across a user’s devices; the latter remain tied to a particular authenticator. Treating every passkey as a single, immovable object misses that difference.

Why the website’s identity matters

WebAuthn scopes credentials to a relying party and includes the requesting origin in the signed authentication data. The service must verify that origin. This is a central reason passkeys resist the familiar phishing trick of persuading someone to type a reusable password into a lookalike site.

That protection depends on correct implementation. The W3C specification explicitly requires services to reject unexpected origins. A reassuring sign-in button does not, by itself, demonstrate that an application has performed those checks.

What this changes for users

Our reading: the practical question shifts from remembering a secret to understanding which provider or device holds a credential, and how access is recovered. A claim that a service is “passwordless” describes a sign-in method; it does not explain every recovery path or security control around the account.