FIDO2 Passkeys
FIDO Passkeys are a modern passwordless authentication standard based on FIDO2 technology. They replace passwords with cryptographic credentials that are always strong and inherently resistant to phishing, because the private key never leaves the user's authenticator and the credential is bound to the origin it was created for. Passkeys come in two forms — device-bound passkeys, which stay on a single device, and multidevice passkeys, which sync across a user's platforms through a credential manager — and the choice between them is the central deployment decision, trading recoverability and reach against the number of places a credential can exist.
Two Forms, Two Risk Profiles
A device-bound passkey is generated inside one authenticator and stays there: a hardware security key, or a platform authenticator backed by a TPM or Secure Enclave. Its private key never exists anywhere else, so there is no sync channel to attack and no cloud provider whose compromise would matter. The cost is that the credential shares the fate of the device — losing it means account recovery, and a new device means re-registration — so device-bound deployments need a deliberate backup strategy, typically a second enrolled authenticator rather than a recovery code.
A multidevice passkey is held by a credential manager such as iCloud Keychain, Google Password Manager, or a third-party password manager, and is synchronized to the user's other devices. It remains cryptographically strong and phishing-resistant, and it solves the practical problems that made device-bound credentials hard to deploy to a general population: a lost phone is no longer a lockout, and a new device is usable immediately. What changes is the trust boundary. The credential's availability now depends on the provider's account security and on end-to-end encryption of the synced material, which reputable providers implement, and takeover of the ecosystem account (Apple ID, Google Account) becomes a path to the credentials it holds. For most workforce and consumer scenarios that is a modest increase in attack surface for a large gain in usability; for high-assurance roles the argument still favours device-bound credentials in hardware.
Authentication in Practice
Signing in means approving the request the same way the user unlocks their device — a fingerprint, a face scan, or a device PIN. The passkey replaces username and password together, so there is no shared secret to type, reuse, leak, or phish. One enrolment covers every subsequent sign-in at that relying party, on every device the credential is available on.
- Security: Immune to phishing, credential stuffing, and password database breaches, because there is no shared secret and the credential is scoped to a single origin
- Simplicity: Users authenticate with a gesture they already perform many times a day
- Convenience: One-time enrolment, no re-registration per session or per application
- Privacy: Credentials are scoped per relying party, so they cannot be correlated across sites
- Recovery: For multidevice passkeys, the credential is present on a replacement device without any relying party involvement
Credential Portability
The most common enterprise objection to passkeys is commercial rather than cryptographic: a synced credential is created inside a particular credential manager, and leaving that provider used to mean re-enrolling with every relying party individually, at a pace those relying parties set. Two FIDO Alliance Credential Exchange specifications now define how one credential manager hands credentials to another:
- Credential Exchange Format (CXF) — an extensible JSON model of what a credential store holds, covering passkeys, passwords, one-time-password seeds, and their metadata, so an export is a lossless description of a credential rather than a spreadsheet of secrets. A Proposed Standard.
- Credential Exchange Protocol (CXP) — the transfer itself, protected end-to-end with Hybrid Public Key Encryption (HPKE) so credentials are never written to an intermediate file. Still a Working Draft, which makes the format the stable part.
Support already runs ahead of that status: Apple moves credentials between apps on the same device with CXF alone, and Android exposes Credential Exchange import and export through Google Play services, carrying passwords and passkeys between Google Password Manager and managers such as 1Password, Bitwarden, and Dashlane.
What this changes for an IAM team is that exportability turns a property of the credential into a property of the provider's policy. "The private key cannot leave the credential store" still holds by construction for a security key, which has nothing to export; for a synced passkey it becomes a statement about a specific credential manager, enforced through managed endpoint and credential manager configuration because the relying party can neither enforce nor observe it — attestation and the AAGUID identify the provider that created a credential, never the one holding it now. So the device-bound versus synced decision gains a third axis alongside security and convenience: who can take the credential somewhere else. Two limits: portability is not backup, being a point-in-time move rather than replication or escrow, so recovery planning is unchanged; and a bulk export driven by an attacker who already holds an unlocked device is authenticated, encrypted, and indistinguishable from a legitimate migration, which makes it a high-signal event for Identity Threat Detection and Response rather than a routine endpoint action.
Lifecycle Considerations
Enrolment. Passkeys are created during account setup or when a user adds an authentication method, and the organization's job is to make the choice of passkey type a guided one rather than an accident of which device the user happened to be holding. Offering both forms is legitimate — different populations and different risk tiers justify different answers — provided the guidance says which is expected where.
Operation. Adoption is the metric that matters, and it is driven by friction: enrolment rates and user feedback surface the flows where people fall back to a password. Fallback mechanisms need to exist during the transition and need an end date, because a password that remains valid as a fallback is still a phishable credential and keeps the phishing-resistance benefit theoretical.
Device changes. Multidevice passkeys appear on a new device within the same ecosystem without relying party involvement; device-bound passkeys require re-registration, which is what device upgrade communications have to prepare users for. Moving between credential managers rather than between devices is the separate problem the Credential Exchange specifications above address.
Recovery. A lost device holding a device-bound passkey means an account recovery flow, and that flow is then the weakest authenticator on the account — a phishing-resistant credential recovered by a knowledge-based question inherits the strength of the question. Re-establishing who is asking is identity proofing performed a second time, and it deserves the assurance level the original enrolment was held to rather than a service desk script. A compromised ecosystem account calls for revoking and re-enrolling the passkeys it held. Secure recovery mechanisms — a second enrolled passkey, recovery codes, or trusted contacts — are part of the passkey design, not an afterthought.
Revocation. Users need to see and remove their registered passkeys, devices reported lost or stolen should trigger revocation automatically, and enterprise deployments need an audit trail of these lifecycle events. Server-side removal alone leaves the credential offered by the user's credential manager, which is what the WebAuthn Level 3 signal methods described in the FIDO2 article exist to correct.
Migration and sunset. Password-to-passkey migration needs a coexistence period, a stated strategy for users who cannot or will not adopt passkeys, and careful communication before legacy authentication is switched off. Provider-to-provider migration is a distinct exercise, planned against CXF and CXP support in the credential managers actually in use.
Deployment Considerations
Passkeys are deployable today across consumer and workforce scenarios, as the primary authentication method or alongside passwords for both sign-in and account recovery, and the remaining work in most environments is organizational rather than technical: choosing the permitted credential managers, deciding where device-bound credentials are required, and removing the password fallbacks that would otherwise cap the benefit. Passkeys authenticate the user at login; binding the session that follows to the same device is the separate concern addressed by Device Bound Session Credentials (DBSC).