SSOGEN / Learn / What Is a Passkey? How It Works, and Whether Your Device Has One
Learn
What Is a Passkey? How It Works, and Whether Your Device Has One
A passkey is a sign-in credential that lives on your device instead of in your head: you approve on the device and it proves who you are, with nothing typed and nothing a fake site can steal.
Updated
What is a passkey? A passkey is a pair of cryptographic keys created for one website. The private key stays on your phone, computer or security key; the website stores only the public key.
To sign in, you approve on the device with a fingerprint, your face or a PIN, and the device answers a challenge from the site. There is no password to type, remember or give away.
The FIDO Alliance describes a passkey as a credential based on FIDO standards that signs you in with the same gesture that opens your device.
How does a passkey work, step by step?
The diagram shows the two moments that matter: you register once, then sign in every time after.
- Registration. Your device creates a key pair bound to the site’s identity and hands over only the public key.
- Sign-in. The site sends a fresh random challenge. Your device asks for your fingerprint, face or PIN, signs the challenge with the private key and returns the signature. The site verifies it against the stored public key.
The challenge is new every time, so a recorded response is worthless later. The protocol is WebAuthn, defined by the W3C in Web Authentication, Level 3.
Does your device support passkeys right now?
Your own browser gives the quickest answer. The tool below runs entirely in this page: it calls the browser’s WebAuthn functions, asks four questions and shows the answers. It creates no passkey, stores nothing and sends nothing over the network.
This checks your current browser and device. Nothing is sent anywhere and no passkey is created.
What each row means:
| Row says | What it means | If the answer is No |
|---|---|---|
| Browser supports WebAuthn | The browser exposes the passkey API at all | Update the browser, or open the page in another one |
| Secure context (HTTPS) | Passkeys are only offered to pages served over HTTPS | You are probably on a plain HTTP or local address, so test on the real site |
| Built-in biometric or PIN | The device has its own screen lock that can approve a passkey (Face ID, Touch ID, Windows Hello, an Android screen lock) | Set up a screen lock, or use a hardware security key or a nearby phone |
| Passkey suggestions in the sign-in box | The browser can offer your saved passkey when you click the username field, with no extra button | Sign-in still works, but you may have to press a “Sign in with passkey” button first |
A “No” on the third row still leaves two options:
- A hardware security key can hold a passkey on a machine with no fingerprint reader.
- The FIDO Alliance defines cross-device sign-in: a nearby phone approves a sign-in on a computer, and a QR code plus Bluetooth confirm that the two are in the same room.
Where does a passkey actually live?
A passkey lives in one of three places, and that choice decides what happens when you lose a device.
The FIDO Alliance distinguishes synced passkeys from device-bound passkeys. WebAuthn marks the same split with two flags, backup eligibility and backup state, described in the terminology and authenticator data sections of the specification.
| Where | How it is kept | If you lose the device |
|---|---|---|
| Phone or computer, synced | Copied to your other devices through a cloud account (that of the phone or browser vendor), end-to-end encrypted | The passkey is still on your other devices and returns when you sign in to the account on a new one |
| Phone or computer, device-bound | Never leaves that one device | It is gone with the device |
| Hardware security key | On a small physical key | It is gone with the key, which is why you register a second one |
According to the FIDO Alliance, device-bound passkeys on security keys offer the highest security assurance.
What does the website store?
The website stores only the public key and an identifier for the credential. The specification’s credential record lists the credential public key as the item the site must keep.
The private key never leaves the authenticator:
- A breach exposes only public keys. A public key cannot sign a challenge.
- A stolen user table is useless for signing in. A stolen table of password hashes, by contrast, can be cracked offline.
Why can a fake site not get a usable answer?
A passkey is scoped to the site that created it. This is what separates it from a password and from a typed six-digit code.
WebAuthn states that the credential can only be accessed by origins belonging to its Relying Party, and the browser and the authenticator enforce that together. The browser also writes the page’s real origin into the data that gets signed.
For example, an Acme Corp employee has a passkey for login.acme.example. A phishing email sends them to login-acme.example, which looks identical.
The browser does not offer the Acme passkey to a different site, and any signature made there would carry the wrong origin.
When the real server verifies an assertion, the specification’s verification procedure (section 7.2) requires it to check four things:
- the origin, against the origins it expects;
- the challenge, against the one it sent;
- the hash of the site identity;
- the signature, against the stored public key.
A response gathered by a fake site fails the first check. The person cannot be talked into handing the credential over either, because they never type anything.
A password has no such check. Neither does a code from an authenticator app, which a fake site can relay to the real one within its 30-second window. Compare all the methods in MFA types.
How is a passkey different from a password and a code?
The short version, from an attacker’s side:
| Password | Code from an app | Passkey | |
|---|---|---|---|
| Secret that travels to the site | Yes, every sign-in | A short-lived code | None |
| What the site stores | A hash of the secret | A shared secret | A public key |
| Works on a fake site | Yes | Yes, if relayed fast | No |
| Reused across sites | Often | n/a | Never, one pair per site |
For the long version, read passkey vs password.
What if I lose the device?
Complete this checklist before it happens:
- Register at least two passkeys: your phone plus a security key kept in a drawer, or two devices.
- Find out whether your passkeys sync. If they do, know which account holds them, and protect that account with its own strong sign-in.
- Keep a fallback your organization approves, such as recovery codes stored offline.
- If a device goes missing, sign in from another one and remove the lost device’s passkey.
- Tell the help desk, so they record the lost device and remove its passkeys.
How to use a passkey
- Sign in to the service as usual and open its security settings.
- Choose to add a passkey. The browser or device shows its own prompt.
- Approve with a fingerprint, face or PIN, or by inserting your security key.
- Next time, enter your username or click the field, then approve the same way. If the service offers passkey suggestions, your passkey appears directly in the box.
Passkeys and single sign-on
A passkey is a sign-in method; it does not replace single sign-on. With SSO, the identity provider verifies the passkey once and the applications behind it trust that result.
- Users. Approve one prompt instead of one per application.
- Administrators. Can require a stronger method for sensitive applications.
In SSOGEN, people add passkeys themselves in My Account, and a policy set to Passkey or security key accepts nothing else for the applications it governs.
Setup steps are in the multi-factor authentication guide and My Account sign-in and security. For the product overview, see passkey authentication; for the wider picture, see MFA software.
What to do on Monday, as an administrator
- Run the device check above on the main laptop and phone models your employees use, and note any “No” rows.
- Choose the applications where a stolen password does the most damage, and protect those first.
- Ask users to add two passkeys before you change any policy. Anyone with no usable method cannot sign in once a policy requires one.
- Then require a passkey or security key on those applications only.
- Write the lost-device procedure from the checklist above and give it to the help desk.
Questions people ask
Is a passkey the same as a password manager entry?
No. A password is a secret you send. A passkey is a key pair, and only the public key ever leaves the device.
Can I remove a passkey?
Yes. Most services list your passkeys with a remove option, and revoking one makes the copy on the device or key useless.
Can I use one passkey on many sites?
No. Each site gets its own key pair.
What if my phone is stolen?
A thief still needs your fingerprint, face or PIN to approve the passkey. Sign in from another device and remove the stolen device’s passkey.
Do I still need a password?
Often, for now. Many services still offer both, so keep the password as a fallback.
Where to go next
- Methods. Compare the methods in MFA types.
- Passwords. Read passkey vs password.
- Biometrics. Face ID or Touch ID releases the passkey but is not the passkey itself; see biometric authentication.
- Hardware keys. A hardware key is another place to keep one; see what a security key is.
- Keep reading. Return to the Learn hub.
Sources, all read 2026-10-09: FIDO Alliance passkeys, W3C Web Authentication Level 3.