What Is a Passkey? A Plain Guide for App Builders
A passkey replaces your password with a key stored on your device, unlocked by biometrics. How it works, why phishing fails on it, and when to add one.
A passkey is a replacement for a password: a secret stored on your device and unlocked with your fingerprint, face, or device PIN. According to passkeys.dev, "a password is something that can be remembered and typed, and a passkey is a secret stored on one's devices, unlocked with biometrics." For an app builder, the appeal is that there is no password to steal, reuse, or phish.
How a passkey works
A passkey uses public key cryptography. When a user creates one, their device generates a pair of keys. The private key stays on the device, unlocked by biometrics. Your server stores only the public key. Passkeys.dev puts it this way: relying party servers store public keys, and even services that help sync passkeys across devices cannot access the private keys.
At sign-in, your server sends a challenge. The device proves it holds the private key by signing the challenge, after the user unlocks it with a fingerprint or face. Your server checks the signature with the public key it stored. No secret travels over the network, so there is nothing for a data breach to leak that an attacker could replay.
Why phishing does not work on passkeys
This is the part that matters most. A phishing site tricks people into typing a password because a password works anywhere. A passkey does not.
Passkeys.dev says that "browsers and operating systems enforce that passkeys are only ever used for the appropriate service." MDN's documentation for the Web Authentication API explains the mechanism: an attacker who creates a fake login website cannot log in as the user, because the signature changes with the origin of the website.
So the user's judgment is taken out of the loop. They cannot be fooled into handing over something that only works on your real domain. Passkeys are also automatically unique per service, with no chance of reuse, which removes the habit of using one password everywhere.
Passkeys versus passwords and codes
Password | Password plus SMS or app code | Passkey | |
|---|---|---|---|
Can be typed into a fake site | Yes | Yes, along with the code | No, tied to the real origin |
Reused across services | Often | Often | No, unique each time |
What your server stores | A hash of the secret | A hash plus a second factor | A public key |
User effort | Remember and type | Remember, type, wait for a code | Biometric or device unlock |
Passkeys do not make everything safe. A stolen, unlocked device or a hijacked account recovery process is still a way in. The point is that the most common attack, tricking someone into entering a credential on a fake page, stops working.
Where the technology comes from
On the web, passkeys are implemented using the Web Authentication API, known as WebAuthn. MDN notes that it enables strong authentication with public key cryptography, allowing passwordless authentication and multi-factor authentication without SMS texts. It is available only in secure contexts, meaning HTTPS.
Should your app offer passkeys?
If your app has user accounts and you control sign-in, probably yes as an option alongside your existing method. The reasons are practical: fewer password reset requests, less password-related liability, and a stronger answer to credential theft. Microsoft's 2026 report puts credential compromise at 20% of observed initial access, which we covered in the Microsoft Digital Defense Report summary.
Our recommendation, and it is ours rather than a standard: do not write the WebAuthn flow yourself. The cryptography is not the hard part. The hard parts are registration and recovery edge cases, multiple devices per user, and what happens when someone loses their phone. Use the passkey support in your authentication provider or library, and ask your AI builder to wire that in rather than generate a custom implementation. If an agent will touch your sign-in code at all, read what to allow when you let an AI coding agent touch your auth code first. If you are choosing between sign-in styles, passwordless magic links are a simpler first step, and two-factor authentication remains useful for users who keep passwords.
What to ask your AI builder
Which authentication provider are we using, and does it support passkeys?
What is the account recovery path if a user loses every device?
Can a user register more than one passkey?
Does sign-in stay on HTTPS in every environment?
Then test it on a real phone and a real laptop. The same checks belong in your pre-launch routine.
FAQ
What is a passkey in simple terms?
It is a digital key stored on your device that replaces your password. You unlock it with a fingerprint, face, or device PIN, and it only works on the real site it was created for.
Are passkeys safer than passwords?
They resist phishing and reuse, because they are bound to the real website and unique for each service. Account recovery and device theft remain risks to plan for.
Do passkeys use biometrics stored on a server?
According to passkeys.dev, the private key stays on the user's device and servers store public keys. Biometrics unlock the key on the device.
Do I need to build WebAuthn myself?
Not usually. For a small app, use your authentication provider's passkey support and spend your effort on recovery and testing.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
