01Why passwords are the problem
A password is a secret that both you and the service know. That is exactly the design flaw.
When both sides know the same secret, it can be lost in three places. At the service, when its database is stolen. In transit, when a fake page tricks you into typing it. And with you, when you reuse the same password and one copy of it surfaces somewhere.
This is not a fringe problem. Switzerland’s Federal Office for Cybersecurity (BACS) logged almost 65,000 reports in 2025, and nearly one in five concerned phishing.
Phishing works because a password does not know where it is being entered. Type it into a page that looks like your bank but is not your bank, and it is gone. No length and no special character changes that. The problem is not a weak password, the problem is the principle of the password.
02What a passkey is
A passkey is not a better password. It is not a password at all.
Instead of a shared secret, a key pair is created. A private key that stays on your devices and is synced encrypted between them, and a public key that is stored with the service. Anyone may know the public key, you cannot sign in with it alone. You keep the private one, and it is released with Face ID, a fingerprint, or your device PIN.
Signing in no longer means “show a secret”, it means “prove that I hold the private key”, without handing it over. You have nothing to remember, nothing to type, nothing to manage in a password manager.
03Why this is safer
Three attacks that work against passwords every day run into a dead end with passkeys.
Phishing falls away. A passkey is bound to the real domain. If the address bar does not show the right service, the device does not even offer the key. A rebuilt login page gets nothing, because there is nothing to grab.
Database leaks become harmless. The service holds only the public key. If the database is stolen, the attacker has a list of public keys they cannot do anything with. Like a list of mailboxes without the matching keys.
Reuse is no longer an issue. A separate key pair is created for every service. There is no “same one everywhere” that could be tried elsewhere after a leak.
04How you use passkeys
In practice it is less effort than a password, not more.
When you set one up, the service asks once whether you want to create a passkey. You confirm with Face ID, a fingerprint, or the device PIN, done. The passkey lands in the iCloud keychain at Apple, in the password manager at Google, in the account at Microsoft, and is therefore in sync across your devices. A new phone has your passkeys automatically once it is set up.
When you sign in, you pick your account and confirm again with face, finger, or PIN. No typing, no reset email, no “forgot password”.
If you have a service whose passkey lives on only one device, you can sign in on someone else’s computer via a QR code. The computer shows the code, you scan it with the phone that holds the passkey, and confirm there. The private key stays on the phone the whole time.
05Under the hood: WebAuthn
For anyone who wants to know what happens technically. No code, just the principle.
The standard is called WebAuthn, part of FIDO2, carried by the FIDO Alliance and the W3C. Browsers and operating systems ship it today, you build none of it yourself.
When you register, the device generates a key pair using asymmetric cryptography. The private key is stored in the device’s secure hardware element, the Secure Enclave at Apple, the equivalent on Android and Windows. With synced passkeys it is additionally stored encrypted in the provider’s keychain, so that it reaches new devices. The public key goes to the service and is associated with the account.
When you sign in, a challenge-response runs. The service sends a random challenge, the device signs it with the private key, the service verifies the signature with the stored public key. The signature is different every time, so a recording is useless. The decisive part is that the challenge is bound to the domain, hence the phishing resistance: a foreign domain never gets the signature in the first place.
Unlocking with Face ID or a fingerprint only releases local access to the private key. Your biometric trait never leaves the device and never ends up on a server.
06What this means for a login architecture
You do not build passkeys yourself, you enable them.
Implementing WebAuthn properly means managing key pairs, device binding, recovery paths, and fallbacks correctly. That belongs in the same category as password hashing, MFA, and token rotation, the things that turn three days of building a login into three months. More on that in the post Never build your own login system.
On AWS, Amazon Cognito ships passkeys. At SCMC.ch they have been in production since day 1, without me writing a single line of WebAuthn crypto. That is exactly how it should be done: enable the shell that Swiss law and your users expect, and put the weeks into the product nobody else builds.
FAQ
Are passkeys really safer than a long password with special characters?
Yes, because the problem is not length, it is the shared secret. A passkey never hands over a secret that could be phished or read from a stolen database. Phishing, credential stuffing, and leaks all run into a dead end.
What happens if I lose my phone?
Passkeys are synced through your provider’s keychain, iCloud at Apple, the password manager at Google, the account at Microsoft. A new device has your passkeys back once you sign in to the account. On top of that, you can store several passkeys per service, for example one on your phone and one on your laptop.
Do I need a new device or special hardware for passkeys?
No. Current iPhones, Android devices, Macs, and Windows machines support passkeys out of the box, as do the common browsers. Unlocking the device with Face ID, a fingerprint, or a PIN is enough.
Can I use a password and a passkey side by side?
Yes. Most services offer passkeys as an additional method and keep the password as a fallback until enough users have switched. You can migrate gradually.
Do I have to implement WebAuthn myself as a provider?
No, and you should not. Identity platforms like Amazon Cognito or Keycloak ship passkey support. You enable and configure it instead of writing your own cryptography.