What a Passkey Replaces

Stage: sign-in without a password or a code. In control: your device.

1. The password leaves, the address stays

A passkey replaces the password. It does not replace the address. Services that adopt passkeys keep asking for an address, and the address moves from the front door to the back one, which changes what it has to be capable of.

This gets stated backwards constantly, usually by people summarising a vendor announcement. Passwordless is read as identifier-free, and it is not. The account still needs something to be called, something to send a receipt to, and something to fall back on when the key is unavailable.

The practical result for anyone weighing up which address to hand over is that the choice matters more on a passkey service, not less.

2. The device keeps one half and shows a proof

The mechanism fits in a paragraph. When you create a passkey, your device generates a pair of related keys. One stays on the device and never leaves it. The other goes to the service, which stores it in place of a password hash.

Signing in is a challenge. The service sends a random value, the device signs it with the half it kept after confirming you are present through a fingerprint, a face, or a device PIN, and the service verifies the signature against the half it holds.

Two consequences fall out of that. There is no shared secret at the service to steal, so a breach yields public keys that are useless on their own. And the key is bound to the site it was created for, so a convincing copy of the login page cannot get a signature out of your device, because the device checks the origin rather than trusting your eyes.

3. Two kinds of passkey behave differently on a bad day

Synced passkeys live in an ecosystem keychain and appear on every device signed into that ecosystem. Device-bound passkeys, including those on hardware security keys, exist in one place only.

The difference is invisible until something goes wrong. Drop a phone with synced keys in a lake and the replacement has your passkeys back after signing into the same ecosystem account. Drop a phone holding device-bound keys and those keys are at the bottom of the lake.

The trade is the one you would expect: synced keys are recoverable and inherit the security of the ecosystem account they sync through, while device-bound keys depend on nothing external and are gone when the device is. Knowing which kind you have decides whether recovery is a five minute inconvenience or a genuine problem.

4. The address does the introductions and the rescue

With passwords gone, the address takes on two narrower jobs and keeps them permanently.

It identifies you before the key is presented, because many sign-in flows still start by asking who you claim to be so the service knows which stored key to challenge. That job is cosmetic and could be replaced by account selection on the device.

The second job is not cosmetic. When there is no usable key on the device in front of you, the address is the route back in: a message goes to it, you prove you can read it, and the service lets you register a new key. Every passkey deployment has a path like this, because a system where a lost device meant a lost account permanently would be unusable.

That means the address on a passkey account is not a formality. It is the credential of last resort, and it is holding more weight than it did when there was also a password.

5. A temporary address fails here in a specific and delayed way

The mismatch is precise: on a passkey service, sign-in keeps working long after the mailbox has gone, and recovery does not.

Register with a disposable address, create a passkey, and everything is fine for months. The key on your device signs you in without touching the mailbox at all, so nothing reminds you that the mailbox expired weeks ago. The address here is deleted after twenty four hours of no use for a guest inbox, or seven days from your last sign-in on a free account, and neither of those windows was ever meant to cover the life of a real account.

Then the device changes. New phone, wiped laptop, keychain that did not carry over. The service offers to send you a recovery message, and it goes to an address that has ceased to exist, or that now belongs to a stranger. Everything about the account is intact except the ability to reach it.

Passwords were more forgiving of this, in the sense that a remembered password kept working forever. A key that vanished with the hardware leaves you with nothing but the address, which is exactly the piece that was chosen to be disposable.

6. What it looks like on screen right now

Passkeys turn up on the large platforms, in password managers, on some banks and shopping sites, and increasingly as an option rather than a replacement.

The pattern is recognisable. You sign in with your existing method, and afterwards the service offers to set up faster sign-in, or asks whether to remember this device. Accept and your device asks for a fingerprint, a face scan, or the PIN you unlock it with. Next time, entering the address is followed by that same prompt instead of a password box.

The signal to notice is what the service offers as the alternative when the prompt fails. If the only fallback is a message to your address, then your address is the account, and the choice of address is a long-term decision rather than a form field.

7. The rest of the pipeline continues exactly as before

A passkey changes how you prove who you are and changes nothing about what the address is doing everywhere else.

The service still stores it, still uses it to write to you, still copies it into whatever internal systems it uses to manage customers, and still treats it as the identifier that ties your records together. Any commercial use it made of the address before passkeys, it makes after.

For that reason a passkey is not a privacy measure. It is an authentication measure, and it is a good one. The question of who ends up holding your address is answered somewhere else entirely, which is worth remembering when a service presents passkeys as though they solved it.

The handover

Control at this stage sits with your device, and the address quietly becomes the thing that outranks it in an emergency. That the account is anchored to an attribute rather than to an identity is the same trap seen from the schema side in the address as a user id. If you would rather hand the sign-in job to a company you already have an account with, that trade is priced in signing in with an account you have, and the intermediate arrangement where the mailbox itself is the credential is when the address becomes the password. Where a service decides the address is not enough proof of a person, it usually asks for something harder to generate, and that field is examined in when the form wants a phone number. For an account with nothing to recover, an address made here is still the right answer.