Passwords are portable by design. A person can type the same secret into a legitimate service, a lookalike page, or an unrelated application. That flexibility is convenient, but it also gives phishing pages a chance to collect credentials that can later be replayed against the real service.
Passkeys change the shape of sign-in. Instead of sending a reusable secret to a server, a device proves possession of a private key. The matching public key is stored by the service, while the private key remains under control of the user’s authenticator or credential provider.
A major security property comes from where that credential is valid. A passkey is associated with a relying party identifier, normally derived from the service’s web domain. A page on an unrelated domain cannot simply ask the authenticator to use that credential as if it belonged there.
Registration creates a key pair for one relying party
When a service registers a passkey, it asks the browser or platform to create a WebAuthn credential. The request includes information about the relying party, the user account, cryptographic options, and a fresh challenge supplied by the server.
The authenticator creates a public-private key pair. The service receives the public key and credential metadata needed for later verification. It does not receive the private key.
The server then associates the public key with the account. On a later sign-in, it can verify a cryptographic signature produced by the corresponding private key.
This arrangement differs from a password database. A password verifier ultimately has to decide whether a submitted secret matches the account’s expected secret. With a passkey, the server checks a signature against a public key. The private signing material does not need to cross the network during authentication.
Domain binding blocks simple credential replay
WebAuthn uses the concept of a relying party identifier, often called an RP ID. For a web service, this is tied to the site’s domain scope and is checked by the browser as part of the credential operation.
Consider an account whose passkey belongs to example.com. A deceptive page hosted at example-login.net cannot request that credential under its own origin and then receive a reusable secret to forward to example.com. The browser and authenticator enforce the relying-party relationship before a matching credential can be used.
The authentication response also carries data bound to the web context and server challenge. The legitimate server verifies these values along with the signature. Capturing one completed response does not provide a static password that can be replayed later, because a fresh challenge is expected for each authentication ceremony.
This is the core phishing-resistant property associated with passkeys and WebAuthn. The user is not responsible for visually comparing a domain and deciding whether it is safe to reveal a shared secret. Credential selection is constrained by protocol rules enforced by software.
User verification protects local use of the credential
A passkey can be protected by user verification on the device. Depending on the platform, that can involve a fingerprint, face recognition, device PIN, or another local verification method.
The biometric sample itself is not sent to the website as the account credential. The local system uses its configured verification mechanism to authorize access to the private key, then the authenticator signs the requested data.
This distinction matters when a service says that a passkey uses a fingerprint or face. The website normally receives evidence from the WebAuthn ceremony, not a copy of the biometric template used by the device.
Local verification also separates possession from account authentication at the server. The device controls use of the private key, while the service validates the resulting signature with the registered public key.
Synced passkeys change availability, not the basic proof
Some passkeys are synchronized across a user’s devices through a credential provider. Others remain bound to one hardware authenticator or one device. Both models can participate in the same public-key authentication pattern.
Synchronization changes how the private credential material becomes available across trusted devices. It does not turn the passkey into a password that the website receives. The service still stores a public key and verifies signatures during sign-in.
This creates a practical difference in recovery. A device-bound credential may require another registered authenticator or account-recovery path if the device is lost. A synchronized credential can become available on another device after the user regains access to the relevant credential provider.
The security of a synchronized passkey therefore also depends on protections around that provider account, device enrollment, recovery controls, and local device access. Passkeys reduce one important class of credential theft, but they do not remove every account-security dependency.
Cross-device sign-in does not require copying a password
A passkey can also support sign-in on a device that does not already hold the credential. One common flow displays a QR code so a nearby phone can participate in the authentication process.
The phone confirms the request, performs local user verification when required, and uses the relevant credential without exposing a reusable password to the computer. Protocol mechanisms establish that the devices are participating in the intended nearby flow rather than treating the QR code itself as the account secret.
This can be useful on a shared or temporary computer because the passkey does not have to be permanently copied onto that machine. The exact interface varies among browsers, operating systems, and credential providers.
Passkeys do not remove server-side security work
A service still has to implement registration and authentication correctly. Challenges need suitable randomness and single-use handling. Origins and relying-party settings need correct validation. Account recovery needs controls strong enough that an attacker cannot bypass passkey protection through a weaker fallback route.
Session security also remains important after authentication. If malware or another attack steals an active authenticated session, the fact that the account originally signed in with a passkey does not automatically invalidate the stolen session token.
The same applies to social engineering outside the credential ceremony. An attacker may try to persuade a user or support agent to change account details, approve recovery, or disclose other sensitive information. Passkeys specifically strengthen the authentication credential and its use; they are not a complete defense against every route into an account.
Public-key credentials change the phishing equation
The practical shift is larger than replacing one login field with another. Password authentication asks a person to provide a reusable secret to a site. Passkey authentication asks an authenticator to prove possession of a private key for the expected relying party and current challenge.
That protocol boundary removes the ordinary act of typing the account secret into a web page. It also prevents an unrelated domain from using a credential registered for the legitimate service under its own identity.
Passkeys still depend on sound account recovery, secure devices, careful server implementation, and protected sessions. Their strongest contribution is more specific: the credential is cryptographic, scoped to the service, and not handed to a page as a reusable secret.