Technology · Security & sovereignty
Passkeys: The Slow, Secure End of the Password
Passkeys are safer and more convenient than any password – yet hardly anyone uses them consistently. How the technology works and how to make the switch.
By Boaz Lichtenstein

The password is a design flaw we’ve been living with for decades: people choose weak ones, reuse the good ones, and hand both over to phishing sites. Passkeys solve all three problems at once – and yet the switch keeps stalling. Time to make the topic practical.
Key takeaways
- A passkey is a cryptographic key pair – there’s no longer a secret you could type, guess, or enter on a fake site.
- A passkey only works on the genuine domain: phishing, the single most common attack vector, structurally hits a dead end.
- Losing a device loses you nothing – passkeys sync in encrypted form via your account or password manager, recoverable on any new device.
- The switch stalls on fragmentation between ecosystems, and on the fact that many services still keep the password open as a fallback.
- The pragmatic path: start with your most important accounts, test recovery beforehand, pick up the rest opportunistically.
How passkeys work
A passkey is a cryptographic key pair: the private key stays on your device (or encrypted within your provider’s sync), the public key sits with the service. At login, your device proves via a signature that it holds the private key – authorised by fingerprint, face, or device PIN. There’s no secret you could type, guess, or enter on a fake site: a passkey only works on the genuine domain. Phishing, the single biggest attack vector there is, hits a dead end, because the cryptographic signature is bound to the exact web address – a perfectly cloned phishing site on a different domain simply can’t request the login.
The login process itself runs through a few steps, invisible to you:
- The service sends a request to your device, tied to its exact domain.
- Your device checks whether it holds a matching passkey for that exact domain – for any other domain, the check fails.
- You authorise it, via fingerprint, face recognition or device PIN – never by typing a secret.
- Your device signs the request with the private key, which never leaves it.
- The service checks the signature against the public key it holds, and lets you in.
This chain explains why even a perfectly copied appearance of a phishing site stays useless: step 2 fails automatically, because the domain doesn’t match – regardless of how convincing the site looks visually.
Passkeys versus passwords, compared
| Criterion | Password | Passkey |
|---|---|---|
| Phishing-prone | Yes, often gets typed in | No, bound to the genuine domain |
| Needs to be remembered | Yes, or a manager is needed | No, released biometrically |
| Reusable across services | Yes (risk!) | No, unique per service |
| Exposed in a data breach | Yes, can be leaked | No, no secret transfers |
| Usable across devices | Yes, typeable anywhere | Yes, via sync or QR code |
Why it still stalls
Three honest reasons: fragmentation – Apple, Google and Microsoft each sync passkeys within their own ecosystems; anyone mixing platforms needs a cross-platform password manager as passkey storage (see our password manager basics). Inconsistent implementation – some services use passkeys as a full login, others only as a second factor, and others still bury the option in submenus, so users simply never find it. The fallback problem – as long as a password exists in parallel, its attack surface remains; real security only emerges once services consistently offer passwordless mode and deactivate the old password.
Passkeys or a physical security key?
Besides passkeys on your smartphone or in a password manager, there’s a third variant: a physical security key (a USB/NFC stick, say) that stores passkeys bound to hardware. For most people, the smartphone or manager passkey is the right choice – convenient, no extra device, secure enough for everyday accounts. A physical key is additionally worthwhile for particularly exposed groups (admins, journalists, people with a high risk profile) or as a backup factor for your own crown-jewel accounts – unlike a smartphone, it can’t be compromised remotely, but it does need to be kept physically secure in return.
Where passkeys already work today
Support keeps growing steadily, but it’s still concentrated in certain categories: major email and cloud providers, most operating-system accounts (Apple ID, Google Account, Microsoft Account), many payment services and, increasingly, online banking apps as well as larger social-media and developer platforms. Smaller providers and many government/corporate portals are catching up more slowly. The practical consequence: the switch doesn’t happen in a day, it happens gradually over years – anyone who glances at security settings with every login will hardly miss a relevant service once it offers the option.
The pragmatic switch, in four steps
- Decide on a storage location: platform sync (convenient if you live within one ecosystem) or a password manager with passkey support (flexible across platforms, see the article linked above).
- Crown jewels first: email account, Google/Apple ID, banking, password manager – the accounts through which everything else can be reset.
- Test recovery before it matters: set up a second device, print out recovery codes and file them physically – following the same principle as an off-site copy in our 3-2-1 backup article.
- Then go opportunistic: whenever a service offers the passkey switch at login, take it. The switch isn’t a project, it’s a habit that builds itself over months.
The most common mistakes when switching
- Setting it up on only one platform and forgetting other devices. Fix: work out beforehand which devices need access, and choose the storage location accordingly.
- Never printing recovery codes. Fix: build the emergency kit immediately at initial setup, not only once access is already gone.
- Leaving the old password unchanged after setting up a passkey. Fix: replace the password with a new, strong one where possible, or ask the service to deactivate it.
- Starting with a rarely used account. Fix: start with the accounts carrying the most damage potential – email and identity providers first.
- Not additionally securing the sync account itself. Fix: the account managing your passkeys deserves a second factor – it’s now the central keyring.
The bottom line
Passkeys are the rare case where the more secure option is also the more convenient one. The transition phase is messy, because platforms and services adopt them at different speeds – but anyone who switches their most important accounts today, and tests recovery beforehand, has structurally solved the phishing problem for their most sensitive access points, not just shrunk it. The time investment for a complete switch is smaller than it feels: the four crown-jewel accounts can be converted in one evening, and everything else happens on its own once services offer the option. The next sensible step isn’t retiring passwords entirely over one weekend – it’s the first login screen that offers the option on its own.