Why passkeys are safer — and when they aren't

What it is

A passkey replaces your password with a key on your device

You unlock it the way you already unlock your phone: fingerprint, face or PIN. That is the whole experience.

Underneath, a passkey is a pair of keys. The split between them is the point.

• The private key never reaches the site. Signing in proves you hold it, without ever sending it. Where it lives is up to your device and provider: a security key keeps it in dedicated hardware, most phones and laptops use a Secure Enclave or TPM, and a synced passkey travels only through your provider's end-to-end encrypted sync (or a share you choose to make).
• Your fingerprint or PIN unlocks that key on the device. It is never sent to the site either. The site learns only that a real person unlocked this device.
• The site keeps only the matching public key. It is safe to leak.

So one touch proves two things at once: you have the device, and a person is present. Neither secret ever reaches the site.

Why it's safer

Passwords get stolen two ways. Passkeys close both.

Phishing: nothing to type means nothing to hand over. A passkey is tied to the real site it was made for. Your browser offers it only on that site, and the site checks where every sign-in came from.

On a lookalike page the passkey is never offered, so the attacker cannot even ask for it.

A password or a one-time code is different. You can type it into any page, and a convincing fake will take it. That is the big one, because “two-factor” codes are no exception: SMS codes, authenticator apps and “Approve?” taps are all things a fooled user can hand to the wrong site.

Breaches: the passkey leaves nothing worth stealing. For each passkey the server keeps only a public key, and a public key cannot sign anyone in. The passkey itself gives an attacker nothing to crack. If the account ever had a password, its hash stays on the server: passkey-only stops that password from signing in but does not delete it.

Each passkey is also unique to one site. A leak at one place is worthless everywhere else, so the password reuse that powers “credential stuffing” is gone.

Here is where the common sign-in methods sit. One hard line divides them. Below it, you hand over something an attacker can catch and reuse. Above it, your device signs a one-time challenge and hands over nothing.

The intuition-buster

So why does my bank pile on hoops, and Google doesn't?

Your bank may ask for an OTP, a card PIN and a security question, and it still feels fragile. Google asks for a single glance, and it feels bulletproof.

Google isn't being careless. The lesson is that friction is not the same thing as security.

Why banks show visible hoops

Mostly, the hoops are not a security choice. Regulation requires them: the EU's PSD2 and India's RBI both require two factors for payments. They also shift fraud liability, and decades-old systems and auditors favour a visible, logged code.

The irony is that the factor banks most often chose, the SMS OTP, is itself phishable. The RBI says it never mandated SMS in particular, and it now allows other factors, including phishing-resistant ones.

Why Google feels effortless, yet is safer

Google didn't skip authentication. It moved the work into the background, on top of a passkey.

A risk engine quietly scores each sign-in on device, location and behaviour, and interrupts you only when something looks off. The strong factor is still there. It just doesn't make you type anything.

The evidence is plain. Google made security keys mandatory for its more than 85,000 employees in early 2017, and by mid-2018 it reported no phishing takeovers of their work accounts. Google also found that signing in with a security key took about half the time of an SMS code.

The keys also cut Google's support costs. Security and convenience were never the same lever. Better authentication gives you both.

For payments

A recommended pattern for approving payments

Payments often need two factors. You can meet that without an SMS code: pair the passkey with a short transaction PIN, in this order.

It is the same idea as UPI: something you have (there, your phone and SIM; here, the passkey on your device) plus something you know (the UPI PIN; here, the transaction PIN). The passkey unlock often already uses the device's own PIN or biometric. The transaction PIN adds a second secret that your server holds and checks, not the device.

Compared with an SMS OTP it is safer and more dependable. There is no SMS code to phish or relay, since the passkey sends nothing an attacker can reuse. There is also no waiting on an SMS that arrives late or not at all.

This is a pattern your site or app builds. The passkeys app provides the confirmation step; showing the amount and payee, storing and checking the PIN, the attempt limit and the lockout are your code. Meeting the payment rules that apply to you stays your responsibility.

When they aren't enough

What passkeys don't fix

Passkeys do one thing superbly: they make the login itself phishing-resistant. They leave real gaps elsewhere.

If you are deciding whether to turn them on, plan around these three.

Do that, and the login is both stronger and easier. It is the rare change that costs your users nothing.

The app is open source (MIT): read the install guide and the security model, or browse the project on GitHub.

From Andrometiq

Passkeys for your Frappe site

We built Frappe Passkey for our own ERPNext, where our bank transactions run. It adds passkey sign-in, as the only login or as a second factor, and a fresh passkey confirmation before a sensitive action runs. It is free and open source under the MIT licence.

See Frappe Passkey →