What is a passkey anyway?

I think we've managed to make passkeys sound much more complicated than they need to be.

Ask what a passkey is and you'll probably hear something about cryptography, authenticators, and FIDO. All true, but not terribly helpful if you're standing there wondering how to get into your account.

I prefer to start with the boring bit: what you actually do. The boring bit is also what makes them so good.

Creating one is pretty uneventful

Say you've signed in to a website and it asks if you'd like to create a passkey. You agree. Your phone or computer asks for the same face check, fingerprint, or PIN you already use to unlock it. A moment later, you're done.

No new password to invent. No six-digit text message to copy. You don't need to know anything about cryptography to use it.

I wish we explained passkeys this way more often. Most people already know how to do the hard-looking part. Their phone has been asking for a face, fingerprint, or PIN for years.

Signing in isn't much different

The next time you visit that website, you choose your passkey, approve the prompt, and you're in. Some services can even offer it before you type your username.

People sometimes ask whether the website gets a copy of their fingerprint or face. It doesn't. Your device uses that check to decide whether you're allowed to use the passkey. The website never needs your biometric information.

A device PIN can do that job too. It's the PIN for your device, not a new password you're sending to the website.

I think that's an underrated change. We've spent years asking people to create secrets, remember them, and then somehow know when not to type them. Passkeys take most of that responsibility off the person signing in.

Okay, what actually is a passkey?

Underneath that simple sign-in is a clever bit of mathematics.

When you create a passkey, your device or credential manager creates two related keys. One is private and stays protected by your authenticator or passkey provider. The website keeps the other one, the public key.

When you sign in, the website sends a fresh challenge. Your device uses the private key to sign the right information, and the website checks it with the public key it already has.

The part I like is that the private key doesn't have to travel to the website. You're proving you have it without handing it over. And somebody who steals the public key can't use it to work backwards and create the private one.

There's also a built-in check on which website is asking. A phishing page might look identical to the real sign-in screen, but it can't simply ask your authenticator to use the legitimate site's passkey for a different domain.

That's a much nicer answer than telling everyone to squint at the address bar and hope they spot a fake.

Do I need one for the app and another for the website?

This one comes up more often than I'd have expected. Someone enrols a passkey on their phone and then wonders why they would need to do the whole thing again when they open the website on a computer.

They don't necessarily need to.

A passkey is associated with your account and the service you're signing into. It's not inherently a separate credential for the mobile app and the website. When the service has set up the relationship between its app and website correctly, the same passkey can be used for both.

Where that passkey is available is a slightly different question.

If you use a credential manager that syncs passkeys, it may already be available on your other supported devices. That depends on the provider, your settings, and which platforms you're using. Not every combination works the same way.

And if your laptop doesn't have that passkey? Your phone may still be able to help.

Your phone can sign you in on another computer

You've probably seen a sign-in screen offer to use a passkey from another device. The computer shows a QR code, you scan it with your phone, approve the sign-in there, and the website opens on the computer.

Your phone and computer establish a secure connection, including a nearby-device check. The computer gets a valid sign-in. It doesn't get a copy of the passkey to keep.

I think this is one of the nicest parts of the design, and we don't explain it nearly enough. We sometimes talk about passkeys as if choosing a different screen means starting over with a different identity. It doesn't have to.

There are perfectly good reasons to register an additional passkey, especially if you're planning for a lost device. But that's a choice about how you want access to work, not a rule that says mobile app equals one passkey, website equals another.

Are passkeys the end of account takeovers?

I wish it were that simple.

Someone can still steal an authenticated session. A compromised device is still a problem. And if the account-recovery process lets an attacker talk their way past the stronger sign-in, the passkey won't rescue that design.

This is where I think implementations deserve a bit more attention than the shiny new sign-in button. What happens when somebody loses their phone? What if they move to a different passkey provider? Can the support team help without accidentally giving an attacker an easier way in?

I'm a big fan of passkeys, but I wouldn't judge an implementation by whether the demo looks good. I'd want to see a real person register one, use it on their other devices, lose access to a device, and recover without being sent through a maze of weaker options.

Done well, passkeys make signing in easier and remove some of the things attackers have spent years stealing. It's not often we get to make both sides of that equation better. I'd like us to take advantage of it.