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 explains what a passkey is, how it works under the hood, why it is phishing-resistant compared with passwords and SMS or code-based MFA, how platform passkeys differ from hardware passkeys, and how to run an enterprise migration without getting stuck on account recovery.

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 MFA recommended by CISA and INCIBE.

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.

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.

Passkey versus password and code-based MFA

The advantage of a passkey is not convenience, it is threat model. These are the four forms of credential theft it removes at the root:

• Phishing and adversary-in-the-middle (AitM) attacks. Because there is no secret to type and the signature is bound to the domain, an Evilginx-style proxy kit gets nothing usable. This is the property that TOTP and push do not have. You can dig deeper in how to avoid phishing and the types of phishing.
• Credential stuffing and password reuse. There is no password to replay against other services. This is the vector analysed in credential stuffing.
• Database breaches. The server holds only public keys, useless to an attacker.
• Keyloggers and SIM swapping. There are no keystrokes to capture and no SMS to intercept, because a passkey sends no one-time code.

Compared with a password plus a traditional second factor, a passkey is not an added factor, it is a change of paradigm. If you want the head-to-head comparison with a verdict, we develop it in 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 (CTAP hybrid, 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. NIST itself now recognises syncable authenticators as a valid option, generally placing them at AAL2, 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 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, and measurably so. They eliminate the four major routes of credential theft: phishing, credential stuffing, database breaches and keyloggers. 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. 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.

Do passkeys replace passwords?

That is the direction, but the transition takes years. A passkey offers more security and a better experience, and on many services it can already be the sole login method. Passwords persist through the inertia of legacy applications and recovery cases. The reasonable goal in 2026 is passkey-first where possible and password only as a fallback where there is no alternative.

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.

Related resources

• What Is FIDO2: Phishing-Resistant MFA and Passkeys
• Passkey vs Password: Which Is More Secure in 2026
• What Is MFA: Multi-Factor Authentication
• What Is IAM: Identity and Access Management
• What Is Credential Stuffing: Attack and Defense

Passkeys with Secra

At Secra we help B2B organisations adopt phishing-resistant authentication without breaking operations. We assess your identity stack, define the mix of platform passkeys and physical keys by criticality, solve recovery before it becomes a problem and align everything with your regulatory framework. If your organisation wants to retire SMS and TOTP and adopt passkeys, contact Secra or review our GRC consulting services.