The password has reached the end of its useful life as a security control. After decades as the main guardian of corporate accounts, it has become the most exploited vector in incidents: it is phishable, reusable and leaks at scale. Passkeys, built on the open FIDO2 and WebAuthn standards, offer an alternative that eliminates the shared secret and, with it, an entire class of credential-theft attacks. This guide explains, for technical teams and for those leading the decision, what passkeys are, how they work and how to conduct the migration to passwordless authentication in environments ranging from 1 to more than 100,000 employees.
Why the password is dying
A password is a shared secret: the user knows it and the server keeps a copy (ideally a hash). This model carries three structural flaws that no amount of training fully resolves.
The first is phishing. If the user can type the password, they can be convinced to type it in the wrong place. Cloned pages, social-engineering campaigns and real-time reverse proxies capture credentials even when there is a second factor, because the code is also typed and relayed.
The second is reuse. People manage dozens of accounts and recycle passwords. A leak at a low-relevance service becomes the key to the corporate environment through credential stuffing attacks, which test leaked pairs en masse.
The third is leakage at scale. Credential databases are compromised routinely and feed criminal markets. Once exposed, the secret is permanently burned, and periodic password rotation only masks the problem without eliminating it.
Add to that the operational cost: password resets are among the most frequent tickets at any service desk. The password is expensive, fragile and hated by users. The way out is not a longer password, but abandoning the shared secret.
What passkeys are
A passkey is a cryptographic credential based on public-key cryptography, specified by the FIDO2 and WebAuthn standards. Instead of a secret the user memorizes, there is a key pair: a private key, which stays protected on the device, and a public key, which is handed to the service during registration.
When the user logs in, the server sends a random challenge. The device signs that challenge with the private key and returns the signature. The server verifies the signature with the public key it already holds. At no point does the private key travel over the network, and the server never has to store a secret that could be stolen. If the service's database leaks, attackers obtain only public keys, mathematically useless for forging a login.
The decisive point is that the passkey is bound to the origin. At registration, the browser ties the credential to the exact domain of the service. In a phishing attempt, the fake domain does not match the registered domain, the browser cannot find the right credential and produces no signature at all. Phishing resistance does not depend on the user's attention: it is a property of the protocol.
How they work in practice
For the user, the experience is simple: when accessing a service, they confirm their identity with biometrics (fingerprint or face) or a local PIN. This gesture does not send the biometric data anywhere; it merely unlocks the private key stored on the device, whether in the phone's secure enclave, the computer's TPM or a physical security key.
Behind the scenes, the flow follows three steps. At registration, the device generates the key pair for that service and sends the public key. At authentication, the service sends a challenge, the device signs it with the private key after local user verification, and the service validates the signature. At synchronization, when applicable, the private key is replicated in encrypted form across the user's devices via the platform provider.
This design combines, in a single gesture, something the user has (the device with the key) and something they are or know (the biometric or PIN). That is why a passkey already constitutes, by nature, strong multi-factor authentication. It is worth emphasizing that the biometric data always stays confined to the device's secure hardware and is never transmitted to the server: it serves only as a local authorization gesture to release the private key.
Synced vs. device-bound passkeys
There are two credential models, and the choice defines the balance between convenience and assurance.
Synced passkeys are copied in encrypted form across the user's devices by the provider (Apple, Google, Microsoft or a dedicated password manager). The benefit is convenience and natural recovery: switching phones does not mean losing access. They are ideal for the general workforce, where the adoption barrier must be minimal.
Device-bound passkeys never leave the hardware where they were created, such as a FIDO2 security key in USB or NFC form. They deliver the highest possible assurance, because there is no copy of the private key in any cloud. They are the recommended standard for privileged accounts, infrastructure administrators and scenarios with strict compliance.
A mature strategy combines both: synced for the day-to-day of the majority and device-bound for the most critical access, always with more than one authenticator registered to eliminate the single point of failure.
FIDO2, CTAP and WebAuthn explained
Three acronyms describe the pieces of the standard, and it is worth distinguishing them.
WebAuthn (Web Authentication) is the API standardized by the W3C that browsers and web applications use to create and use credentials. It is what allows a site to ask the browser to register or sign a challenge.
CTAP (Client to Authenticator Protocol) is the protocol that connects the client (the browser or operating system) to the authenticator, whether internal, such as the device's biometric sensor, or external, such as a USB key. It is CTAP that makes it possible to use the phone as an authenticator to log into a nearby computer.
FIDO2 is the umbrella that brings WebAuthn and CTAP together under the governance of the FIDO Alliance. When people talk about a passkey, they are really talking about a FIDO2 credential exposed through the WebAuthn API and unlocked by an authenticator that speaks CTAP.
Phishing-resistant MFA: why OTP and SMS are not enough
Not every second factor is equal. Codes via SMS, email or authenticator apps improve security over the password alone, but they remain secrets the user types, and so they stay phishable. A modern reverse proxy intercepts the code in real time and relays it to the legitimate service, hijacking the session. SMS also suffers from SIM swapping and network interception.
The passkey breaks this pattern because there is no code to type or relay: the signature is only produced for the correct domain. This is exactly what reference bodies call phishing-resistant MFA, the recommended standard for sensitive access. To go deeper into factor levels and what characterizes strong MFA, see our material on MFA.
| Method | Phishing-resistant? | User experience |
|---|---|---|
| Password | No | Poor (memorize, type, reset) |
| Password + SMS OTP | No (SIM swap, relay) | Average (wait for and type code) |
| Password + authenticator app (TOTP) | No (phishable code) | Average (open app and type) |
| Push notification with approval | Partial (subject to MFA fatigue) | Good (one tap) |
| Synced passkey | Yes (bound to origin) | Excellent (biometrics in one gesture) |
| Device-bound passkey / FIDO2 key | Yes (maximum assurance) | Good (tap the physical key) |
Enterprise adoption: IdP and migration roadmap
At enterprise scale, the passkey does not live isolated in each application. It is registered with the identity provider (IdP) that already centralizes access. The user authenticates with a passkey at the IdP and, from there, reaches all applications through SSO and identity federation (SAML and OIDC). Concentrating the passkey at the IdP means policy, auditing and migration in a single point of control.
A pragmatic migration roadmap usually follows these phases: inventory where passwords are used; enable passkey registration at the IdP; assign synced passkeys to the workforce and device-bound ones to privileged users; run a pilot with a technical team; expand in waves while monitoring adoption; and, finally, make the password read-only before removing it as a login path. The goal is not to add one more factor, but to eliminate the shared secret.
Account recovery: the new link to protect
When the password is removed, the recovery flow becomes the attackers' preferred target. There is no point in making login phishing-resistant while leaving an account reset that depends on a code via email or SMS, because the adversary simply attacks that weaker path.
Good practices are clear: require at least two authenticators per user (for example, the phone plus a physical key), offer provider-based recovery for synced passkeys and, in the corporate environment, maintain a verified, controlled recovery flow run by the help desk, with robust identity validation. Recovery must be as strong as the login it restores.
Relationship with Zero Trust
Passkeys are a natural pillar of a Zero Trust architecture, whose principle is never to trust by default and always to verify. An identity proven by phishing-resistant authentication is the foundation on which conditional access decides what to allow.
By feeding policies with strong authentication signals, the organization can grant granular access according to context: who the user is, which device, what security posture and which resource is being requested. Without a trusted identity at the base, the rest of Zero Trust operates on fragile assumptions. The passkey provides that trust in a verifiable and scalable way.
References
- FIDO Alliance — FIDO2 specifications and the definition of passkeys, maintained by the alliance that governs the standard.
- W3C — Web Authentication (WebAuthn), the recommendation that standardizes the credential API in the browser.
- NIST SP 800-63B — Digital Identity Guidelines, which define authentication assurance levels and characterize phishing-resistant MFA as the recommended standard for sensitive access.
Passwordless authentication in practice, with Decripte
For companies of any size, migrating to passkeys is not a cosmetic convenience project: it is the most effective way to end the largest source of credential incidents and, at the same time, reduce support cost and user friction. The path begins with an identity inventory and a well-measured pilot, evolves in waves anchored at the IdP and culminates in disabling the password as a login factor. Decripte supports this roadmap end to end, from designing the phishing-resistant MFA policy to integrating it with your Zero Trust strategy.
Want to know where your organization is exposed today? Start for free by assessing your identity posture, or explore our plans to conduct the migration with end-to-end security.