Sign-in prompts increasingly ask for a fingerprint or a face scan instead of a typed password. The change is not cosmetic: the secret being checked is a different kind of thing, held in a different place.
Passwords fail because they are shared secrets
A password is a string the user knows and the service also stores in some form. Both sides must hold something derived from it for verification to work.
That creates two exposures. A breach at the service can leak the stored values, and a convincing fake login page can capture the string directly from the user.
Reuse across sites multiplies both problems, because one exposed credential becomes a key tried automatically against many other accounts.
A passkey is a key pair, not a string
When a passkey is created, the device generates two mathematically linked keys. The private key stays on the device and the public key is sent to the service.
At sign-in the service sends a challenge, the device signs it with the private key, and the service verifies the signature using the public key it stored.
The private key is never transmitted, so there is nothing at the service worth stealing and nothing for the user to accidentally disclose.
The browser checks who is asking
A passkey is bound to the domain it was created for, and the operating system or browser enforces that binding before offering to use it.
A lookalike site at a different address simply will not be matched, so the passkey is not offered at all rather than being offered and misused.
This is the structural defense against phishing. It does not depend on the user noticing a misspelled address in a location bar.
Biometrics authorize the key locally
A fingerprint or face scan authorizes the device to use the private key. The biometric data itself is checked on the device and is not sent anywhere.
A device passcode serves the same function, which is why passkeys still work on hardware without a biometric sensor.
The convenience and the security come from different parts of the design, and conflating them is a common source of confusion.
Recovery is now the hard problem
If a key lives only on one device, losing that device loses the account, so most implementations sync passkeys through an encrypted account on a platform or password manager.
That syncing reintroduces a dependency: access to the accounts holding the keys becomes the account that matters most.
Services therefore still maintain recovery paths, and those paths remain the weakest link in an otherwise stronger arrangement.