Skip to main content
Identity Authority
Category: FIDO & Passkeys

Device-Bound Passkey

Also known as: device-bound FIDO credential
Simply put

A device-bound passkey is a type of passkey login credential that stays on the single physical device where it was created and does not sync to other devices or to the cloud. This differs from synced passkeys, which can be shared across a user's devices. Because it never leaves its original device, a device-bound passkey is often stored on a dedicated security key.

Formal definition

A device-bound passkey is a FIDO2/WebAuthn credential whose private key is generated and stored on a single physical authenticator and does not leave that device, in contrast to synced (multi-device) passkeys that can be replicated across a user's devices. In most deployments the private key resides on a hardware security key or a platform authenticator (for example, an authenticator app or a device's secure hardware), and authentication proceeds by producing a signed assertion over a server-provided challenge without the private key ever being exported. As a possession-based, phishing-resistant credential under the WebAuthn/FIDO2 model, its non-syncing property is often cited as offering stronger control over where the credential exists; however, exact behavior, recovery implications, and attestation support depend on the authenticator, relying party configuration, and vendor implementation. This entry addresses the credential's binding and storage characteristics; it does not cover authorization decisions made after authentication, which are out of scope.

Why it matters

Device-bound passkeys address a specific concern that synced passkeys introduce: control over where a credential can exist. Because a device-bound passkey's private key is created and stored on a single physical authenticator and never leaves it, an organization can reason about exactly which physical devices hold a given credential. In most deployments this non-syncing property is cited as offering stronger control and is often considered more secure than a synced credential that can be replicated across a user's devices and, in some configurations, held in a cloud account whose recovery mechanisms are outside the relying party's control.

For security architects and IAM engineers, the tradeoff is between assurance and convenience. Synced passkeys ease recovery and multi-device use, while device-bound passkeys keep the credential confined to one authenticator, typically a hardware security key, at the cost of portability. As a phishing-resistant, possession-based credential under the WebAuthn/FIDO2 model, a device-bound passkey resists credential replay and phishing regardless of binding type, but its binding characteristic is what matters for high-assurance scenarios where an organization wants to guarantee a credential cannot be silently copied elsewhere.

The practical implications, however, depend heavily on implementation. Recovery is a particular consideration: because the private key never leaves its device, loss or failure of that device generally means the credential cannot be recovered and must be re-enrolled, so deployments typically plan for backup authenticators or fallback enrollment. Attestation support, which lets a relying party verify what kind of authenticator produced a credential, also varies by authenticator and configuration and should not be assumed.

Who it's relevant to

Security Architects
Architects designing high-assurance authentication may prefer device-bound passkeys where it is important to guarantee that a credential cannot be silently copied across devices or to the cloud. They should weigh this control against the recovery and portability advantages of synced passkeys, and confirm attestation support and authenticator types against their assurance requirements rather than assuming them.
IAM Engineers
Engineers implementing WebAuthn/FIDO2 registration and authentication flows need to account for the fact that a device-bound private key never leaves its authenticator, meaning recovery typically requires enrolling backup authenticators. Exact behavior, including whether a credential is treated as device-bound or synced, depends on relying party configuration and the authenticator in use.
System Administrators
Administrators managing enrollment and lifecycle should plan for the operational reality that loss or failure of a device holding a device-bound passkey generally means the credential must be re-enrolled, since it cannot be synced or recovered elsewhere. Fallback enrollment paths and multiple registered authenticators help avoid lockout.
Compliance Officers
For requirements that emphasize phishing-resistant, possession-based credentials with tight control over where a credential can exist, device-bound passkeys offer a defensible option because the private key is confined to a single physical device. Officers should note that specific properties such as attestation vary by authenticator and vendor implementation and should be verified per deployment.

Inside Device-Bound Passkey

Device-bound credential
A FIDO2/WebAuthn credential whose private key is generated and stored on a single authenticator and, by design, is not exportable or synchronized to other devices. This contrasts with synced passkeys, which are replicated across a provider's cloud ecosystem.
Hardware-backed key storage
In most deployments the private key resides in a hardware security element such as a TPM, secure enclave, or a discrete security key. The key material typically never leaves that hardware boundary; authentication is performed by the authenticator producing a signed assertion.
Public-key credential pair
During registration the authenticator creates a key pair, retains the private key locally, and returns the public key to the relying party. The relying party stores the public key and later verifies signed assertions during authentication ceremonies (inherence or possession factor plus optional user verification).
Attestation
An optional statement, produced during registration, that conveys information about the authenticator's make or model and its security properties. Attestation formats and whether they are requested or enforced vary by relying party configuration and privacy considerations.
User verification
A local gesture such as a biometric or PIN that unlocks use of the private key on the authenticator. This can combine a possession factor (the device holding the key) with a knowledge or inherence factor, supporting multi-factor authentication in a single ceremony depending on configuration.
Relationship to passkeys, FIDO2, and WebAuthn
A device-bound passkey is a passkey (a FIDO2 discoverable credential) that is not synced. WebAuthn is the browser/platform API and FIDO2 the broader specification set; the device-bound property refers to the key's non-exportability, not to a distinct protocol.

Common questions

Answers to the questions practitioners most commonly ask about Device-Bound Passkey.

Are device-bound passkeys and synced passkeys the same thing?
No. Both are WebAuthn/FIDO2 credentials, but they differ in how the private key can move. A device-bound passkey has its private key generated and retained on a single authenticator (for example, a hardware security key or a platform authenticator) and, in most implementations, cannot be exported or copied to another device. A synced passkey, by contrast, is designed to be replicated across a user's devices through a credential provider's syncing mechanism. The distinction matters for assurance and recovery planning: device-bound credentials typically offer stronger guarantees that the key exists in exactly one place, while synced passkeys prioritize availability and recoverability. Neither is universally superior; the right choice depends on your risk model and deployment context.
Does a device-bound passkey by itself count as multi-factor authentication?
It depends on how the authentication ceremony is performed, and this is often misunderstood. A passkey demonstrates possession of the authenticator holding the private key. Whether the overall authentication is multi-factor depends on whether a second distinct factor is also verified during the ceremony, such as a local user-verification step (a PIN as a knowledge factor, or a biometric as an inherence factor) performed by the authenticator. When user verification is required and satisfied, the ceremony can combine possession with knowledge or inherence. When only user presence (not user verification) is checked, the assurance is closer to single-factor possession. Check the authenticator's reported flags and your relying-party policy rather than assuming; behavior varies by authenticator and configuration.
How can a relying party require that only device-bound passkeys are registered?
The mechanism available in WebAuthn is attestation, which can convey information about the authenticator's characteristics at registration time. Relying parties that require device-bound credentials typically request attestation and evaluate the authenticator's reported properties, sometimes against metadata such as the FIDO Metadata Service, to make a policy decision. Be aware that attestation availability, format, and trustworthiness vary by authenticator and platform, and some platform authenticators limit or omit attestation. Whether you can reliably distinguish device-bound from synced credentials depends on the authenticators in your population and the attestation your policy is prepared to accept; treat this as configuration-dependent and validate against your actual device fleet.
What should our account recovery strategy be when users rely on device-bound passkeys?
Because a device-bound passkey's private key does not, in most implementations, leave its authenticator, loss or replacement of that device typically means the credential is unrecoverable and the user must re-enroll. Plan for this by supporting registration of more than one authenticator per user (for example, a primary and a backup device or hardware key), and by defining a vetted re-enrollment or recovery flow. The security of that recovery path is important, since a weak fallback can undermine the assurance the passkey provides. The specific options and their trade-offs depend on your identity platform and enrollment policies.
Where does a device-bound passkey fit relative to step-up authentication?
A device-bound passkey can serve as a primary authentication credential and can also be used as a step-up factor for higher-risk operations, depending on how your policy engine is configured. Because the authentication is a runtime enforcement concern, the decision to require or re-invoke a passkey ceremony for a sensitive action is driven by your authorization and access policies rather than by the credential itself. Whether re-authentication or an additional user-verification step is prompted depends on your relying-party settings and the capabilities of the authenticator.
How do device-bound passkeys interact with provisioning and lifecycle management?
Registering a device-bound passkey is an enrollment event tied to a specific authenticator, and it should be reflected in the identity's credential inventory so that governance processes can account for it. Deprovisioning or offboarding should include revoking or de-registering the associated credential on the relying-party side, since disabling an account is a separate step from removing the credential binding. Keep these lifecycle actions distinct from the runtime authentication ceremony itself; the exact provisioning and de-registration workflows depend on your identity platform and any SCIM or directory integration in use.

Common misconceptions

Device-bound passkeys and synced passkeys are interchangeable and behave identically.
Both are FIDO2/WebAuthn credentials, but they differ in key portability. A device-bound passkey's private key stays on one authenticator and is not replicated, whereas a synced passkey is copied across a provider's ecosystem. This affects recovery, availability across devices, and assurance assumptions.
A device-bound passkey performs authentication and authorization together.
A passkey addresses authentication by proving control of the private key (and optionally user verification). What a principal may then do is a separate authorization decision handled by the relying party or a downstream policy engine, and is out of scope for the credential itself.
Because the key is device-bound and hardware-backed, the authentication data is encrypted end to end.
The authenticator signs assertions with its private key; signing proves origin and integrity but is not the same as encryption. Whether the surrounding transport or any tokens are encrypted depends on the channel (typically TLS) and relying party configuration, not on the device-bound property.

Best practices

Decide explicitly whether your assurance requirements call for device-bound or synced passkeys, since non-exportable keys typically raise assurance but reduce cross-device availability and complicate recovery.
Plan account recovery and enrollment of backup authenticators in advance, because a device-bound credential cannot be synced and is unavailable if its single authenticator is lost.
Register more than one authenticator per user where availability matters, so the loss of one device does not lock the principal out.
Determine your attestation policy based on privacy and assurance needs, requesting or enforcing attestation only where authenticator provenance is genuinely required by configuration.
Configure user verification appropriately when you need the ceremony to satisfy multi-factor requirements, and document which factors (possession, knowledge, inherence) each flow actually provides.
Keep authentication and authorization concerns separate: treat a successful passkey ceremony as proof of identity only, and enforce access decisions through your policy layer independently.
Promotional banner for the Pentest Readiness checklist download