Passkeys vs Passwords: What Actually Changes When You Switch

Passwords have survived decades of predictions of their demise, largely because every proposed replacement traded one problem for a worse one. Passkeys are the first alternative with broad platform support and a genuinely different security model, and they are now available across the major operating systems and browsers.

What is wrong with passwords

The fundamental problem is that a password is a shared secret. You know it and the service knows something derived from it, which means there is something on the server worth stealing. Even correctly hashed, a stolen database enables offline attack against weak entries.

Worse, because the secret is transmitted at login, it can be intercepted or, far more commonly, phished. A convincing replica of a login page collects a working credential, and no amount of password complexity helps. Traditional two-factor authentication by code reduces but does not eliminate this, because codes can be relayed in real time by an attacker sitting between the user and the real service.

How passkeys differ

A passkey is a public and private key pair. When you register, your device generates the pair, sends the public key to the service, and keeps the private key. The private key never leaves your device and is never transmitted anywhere.

At login, the service sends a random challenge. Your device signs it with the private key — after verifying you locally through a fingerprint, face scan or device PIN — and returns the signature. The service verifies it against the stored public key.

Related: what an IPO actually involves

Two properties follow. A breach of the service yields only public keys, which are useless to an attacker. And there is no secret for the user to reveal, so there is nothing for a phishing page to collect.

The origin binding that stops phishing

The most important protection is one users never see. Each passkey is cryptographically bound to the exact domain it was created for. The browser enforces this: presented with a lookalike domain, the device will not offer the passkey at all, because the origin does not match.

This is a categorical improvement rather than an incremental one. It does not rely on the user noticing a suspicious address, which is precisely where human defences fail most reliably.

The local verification step

The biometric or PIN check happens entirely on the device and unlocks the private key locally. Your fingerprint is not sent to the service and is not stored by it. Services receive only a signature, and cannot distinguish which local method authorised it.

This distinction matters for anyone concerned about biometric data. Using a passkey does not give the service your biometrics; it gives them a signature that your device produced after satisfying itself you were present.

Synchronisation, and the real trade-off

Passkeys as commonly deployed sync through a platform account or password manager, encrypted end to end. This solves the practical problem that a device-bound key becomes useless when the device is lost.

It also relocates the security question. The passkeys are now only as protected as the account that syncs them, which makes securing that account — with a strong unique credential and its own second factor — the single most important step. Some sensitive deployments use device-bound passkeys or hardware security keys precisely to avoid this, at the cost of requiring backup devices.

Where it gets awkward

Cross-ecosystem use is the main friction. Signing in on a device belonging to a different platform ecosystem generally requires a QR code flow, in which the site displays a code, you scan it with the phone holding the passkey, and a proximity check over Bluetooth confirms the devices are physically near each other. This works reliably but is more steps than typing a password.

Account recovery is the second unresolved area. If you lose access to every device and to the syncing account, recovery falls back to whatever the service offers — commonly email, which is frequently protected by a password, which reintroduces the weakness the passkey was meant to remove. This is an implementation problem rather than a protocol problem, but it is a real one today.

The practical approach

Adding a passkey generally does not remove the existing password unless you explicitly delete it, so the realistic path is incremental: enable passkeys where offered, starting with the accounts that gate everything else — your email and your platform account. Secure the syncing account thoroughly. Keep a recovery method that does not depend on a single device.

The gain is not that passkeys are harder to break than a strong password. It is that the most common way accounts are actually compromised — someone typing a credential into a convincing fake — stops being possible at all.