What Is a Passkey? Passwordless Login Explained

A passkey is a passwordless login credential that replaces your password with a cryptographic key pair: a private key that never leaves your device and a public key held by the service. Instead of typing a secret that travels across the network and can be stolen, your phone or laptop proves who you are by signing a cryptographic challenge that you unlock with your fingerprint, your face or a local PIN. Passkeys are the practical implementation of the open standard from the FIDO Alliance and the W3C, and by 2026 they are the login method Apple, Google and Microsoft offer by default across hundreds of services.

This guide is the definitional reference: it explains what a passkey is, how it works under the hood, how platform passkeys differ from hardware passkeys, when to choose a synced or a device-bound credential, and how to run an enterprise migration without getting stuck on account recovery. The threat-by-threat comparison against the password is covered separately, in passkey vs password.

Key takeaways on passkeys

• A passkey is a FIDO2/WebAuthn discoverable credential: a key pair bound to a single service, with the private key held in secure hardware.
• There is no shared secret: the server stores only the public key, so a breach of its database leaks nothing reusable.
• It is phishing-resistant because the credential is bound to the domain (origin) and will not sign for a spoofed site.
• Passkeys come in synced flavours (convenient, replicated to the cloud) and device-bound flavours (no sync, strongest assurance).
• It maps to NIS2, ISO 27001 A.5.17, the Spanish ENS and the NIST SP 800-63B AAL levels, and it is the form of phishing-resistant MFA that CISA names as the gold standard (FIDO/WebAuthn).

What a passkey is

A passkey is an authentication credential based on public-key cryptography that replaces the password. Technically it is a discoverable credential (formerly called a resident key) from the WebAuthn standard, which is part of the FIDO2 framework. When you register with a passkey, your authenticator (your phone, your laptop or a physical key) generates a unique key pair for that service. The private key stays protected by secure hardware (Apple's Secure Enclave, a TPM 2.0 on Windows, StrongBox or the Titan M2 on Android, or the secure element of a key), and the public key is sent to the server and tied to your account.

The essential difference from a password is that there is no secret a user can read, type or paste. A passkey is not something you "know": it is used, and it activates only after a local user verification (biometrics or PIN) that unlocks the private key for one specific operation. That is why a passkey cannot be reused elsewhere, cannot be leaked in a breach and cannot be typed into a fake website.

A passkey is not a password manager

This is a common confusion. A password manager stores secrets that are still passwords: they autofill, but they travel to the server and can end up on a phishing site. A passkey has no secret to send. Many modern managers (1Password, Bitwarden, Dashlane) now act as passkey providers through the platform APIs, but what they store is no longer a reusable text string, it is a private key that only produces signatures bound to an origin.

How a passkey works

A passkey operates through two ceremonies of the WebAuthn protocol, both triggered by the browser or the operating system through the Web Authentication API.

During registration, the web application calls navigator.credentials.create(). The authenticator generates the key pair for the service identifier (the rpId, usually the domain), stores the private key and returns the public key together with a credential ID. From that point on the service no longer needs to store any secret of yours.

During authentication, the application calls navigator.credentials.get() with a random challenge. The authenticator asks you to verify (fingerprint, face or PIN), signs the challenge with the private key and returns the signature. The server validates it with the public key it stored. No reusable secret ever crosses the network. If you want the protocol detail on WebAuthn and CTAP, we cover it in the FIDO2 guide.

The critical element is the origin binding: the browser only allows the passkey to be used on the domain it was created for. Even if you land on a look-alike domain, the authenticator will not sign, and the credential is useless outside its legitimate service. That binding is what makes a passkey a phishing-resistant factor in the sense described by the CISA fact sheet on phishing-resistant MFA, and it is why a phishing proxy obtains nothing reusable. How that property plays out against each attack type (AitM phishing, credential stuffing, breaches, keyloggers) compared with passwords and code-based MFA is broken down in the head-to-head threat model of passkey vs password.

Platform passkeys versus hardware passkeys

Not all passkeys are the same. The most important practical distinction is where the private key lives and whether it syncs.

Platform passkeys (synced). These are created by the operating system and replicated to the provider's cloud: iCloud Keychain in the Apple ecosystem, Google Password Manager on Android and Chrome, or Windows Hello, plus the third-party managers mentioned above. They sync across your devices, so they survive the loss or replacement of a device. Their security depends on the cloud account that holds them.

Hardware passkeys (device-bound). These live on a physical security key (YubiKey 5, Google Titan, Feitian, Token2) and never leave the device's secure element. They do not sync, so they require a physical backup, but they are immune to a cloud provider compromise and to endpoint malware.

To sign in on a device other than the one holding the passkey there is hybrid transport (defined in the FIDO Alliance CTAP 2.2 specification and formerly known as caBLE): you scan a QR code with your phone and a Bluetooth proximity check confirms both devices are near each other. That lets the phone authenticate a laptop login without ever exposing the key.

Synced versus device-bound: which to choose

The decision criterion is criticality. For the general workforce, synced platform passkeys deliver a huge improvement over passwords with minimal friction. For administrators, privileged accounts and regulated environments, the recommendation is still device-bound hardware, aligned with NIST SP 800-63B AAL3. Revision 4 of NIST SP 800-63B devotes an appendix to syncable authenticators and accepts them as a valid option at AAL2 provided its conditions on key custody, encrypted sync and provider control are met, a nuance worth documenting in your access policy.

Passkey adoption in 2026

By 2026 passkeys are no longer a promise. Apple, Google and Microsoft offer them as the default method at account signup, and passkey autofill (the conditional UI, using mediation: 'conditional') surfaces them directly in the login field, so the user has nothing to remember. Many services already allow a passkey as the sole factor, retiring the password entirely.

The piece that was missing, portability across ecosystems, has also matured: the FIDO Alliance published the Credential Exchange specifications, the Credential Exchange Protocol (CXP) and the Credential Exchange Format (CXF), which allow passkeys to be moved between managers in an encrypted, standard way, without being locked into a single provider. This is a meaningful change for enterprise adoption, because it removes the fear of vendor lock-in.

The weak spot: recovery

If a user loses their only authenticator and the only way back is an SMS or a security question, you have reintroduced the very vector passkeys were meant to eliminate. Recovery must be designed before rollout: mandatory registration of two authenticators per user, custodied backup keys and, for edge cases, a service-desk assisted process with strong identity proofing, never a simple reset email.

Enterprise migration: passkey-first, password as fallback

A migration to passkeys rests on your identity provider (Microsoft Entra ID, Okta, Ping and Google Workspace support WebAuthn natively) and fits into your identity and access management as policy, not re-engineering. A realistic roadmap:

1. Pilot with privileged accounts using device-bound passkeys on a physical key. They are the highest-value target.
2. Platform passkeys for the general workforce, with conditional access requiring a phishing-resistant factor on sensitive resources.
3. Gradual retirement of weak factors: SMS first, then TOTP once passkey coverage is sufficient. Strong MFA living alongside an SMS fallback drops to the level of its weakest link.
4. Recovery solved in advance, with a second authenticator and an assisted process.

This approach fits the strong verification of a Zero Trust architecture, and satisfies requirements from NIS2, the Spanish ENS, ISO 27001 A.5.17 and the strong customer authentication (SCA) of PSD2. A passkey is not only better security: in many frameworks it is already the cleanest way to demonstrate compliance.

Frequently asked questions

How does a passkey work?

A passkey works with two keys. When you register, your device generates a key pair for that service: it stores the private key in secure hardware and sends the public key to the server. When you sign in, the server sends a random challenge, your device signs it with the private key after verifying your fingerprint, face or PIN, and the server validates the signature with the public key. No reusable secret is ever transmitted.

Are passkeys safe?

Yes. Because there is no shared secret and the credential is bound to the domain, neither an adversary-in-the-middle attack nor a fake website gets anything usable, and the server holds only public keys. The residual risk shifts to the device and, for synced passkeys, to the cloud account that replicates them, which should be protected with its own strong authentication. The detailed threat-by-threat comparison against the password is in passkey vs password.

What happens if I lose the device with my passkeys?

It depends on the type. A synced passkey is recovered as soon as you sign in on another device with your cloud account, because it was replicated. A device-bound passkey on a physical key does not sync, so you need a backup key registered in advance. That is why the good practice is to always register two authenticators per user.

Platform passkey or physical security key?

For most people's daily use, a synced platform passkey is sufficient and very convenient. For administrators, privileged accounts and regulated environments, a device-bound physical key is the recommendation, because it depends on no cloud account and reaches the highest assurance level. Many organisations combine both according to the criticality of the access.

Sources

• FIDO Passkeys: Passwordless Authentication | FIDO Alliance: official definition of a passkey as a FIDO2/WebAuthn discoverable credential and its synced and device-bound variants.
• Web Authentication API | MDN: reference for the registration and authentication ceremonies (navigator.credentials.create() and get()) a passkey relies on.
• SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management | NIST CSRC: AAL levels and treatment of syncable authenticators cited in the post.
• Implementing Phishing-Resistant MFA | CISA: official fact sheet positioning FIDO/WebAuthn as the gold standard for phishing-resistant MFA.

Related resources

• What Is FIDO2: Phishing-Resistant MFA and Passkeys: the protocol detail (WebAuthn and CTAP) a passkey is built on.
• Passkey vs Password: verdict and head-to-head threat model: the threat-by-threat comparison this post leaves out on purpose.
• What Is MFA: Multi-Factor Authentication: the general framework in which the passkey replaces weak factors.
• Phishing-Resistant MFA: what it requires and how to deploy it: the deployment requirements a passkey migration has to meet.
• What Is IAM: Identity and Access Management: where passkey policy sits inside the identity provider.

Conclusion

The decision that shapes the whole rollout is not synced versus device-bound, but how an account is recovered when the user loses their authenticator: if the way back is an SMS or a reset email, the very vector the passkey removed has been reintroduced. Worth measuring: the share of users with two registered authenticators, the share of privileged access that requires a phishing-resistant factor and how many applications in the inventory still do not accept WebAuthn. The usual mistake is keeping SMS or TOTP as a permanent fallback, which drops the whole chain to the level of its weakest link. If you want that starting point reviewed in your environment, you can do so through contact or our GRC consulting services.