Category: FIDO & Passkeys

Authenticator Binding

Also known as: authenticator-to-account binding, credential binding

Simply put

Authenticator binding is the process of linking a specific authenticator, such as a security key, phone app, or passkey, to a particular user account so that authenticator can later be used to prove the account holder's identity. Once bound, presenting the authenticator during sign-in demonstrates that the person is the legitimate owner of the account. This binding is what makes an authenticator meaningful for authentication rather than just an anonymous device.

Formal definition

Authenticator binding is the establishment of an association between a specific authenticator and a subscriber account, enabling that authenticator to be used to authenticate the subscriber (NIST CSRC). It is an identity-and-authentication concern distinct from authorization; binding determines which authenticator is recognized for a given account, not what that account may access. Per NIST SP 800-63B, the binding may be established through several mechanisms, such as choosing an associated authenticator secret or deriving an authenticator secret using a verifier identifier; the exact method depends on the authenticator type and deployment profile. In WebAuthn/FIDO2 contexts, binding typically links a device-resident authenticator (or a device-bound passkey) to the account via registered credentials, though specific behaviors, such as whether a passkey is device-bound or syncable, vary by platform and configuration. Note that this entry addresses the binding of an authenticator to an account; the enrollment and identity-proofing steps that precede it, and runtime token validation that follows authentication, are out of scope here.

Why it matters

Authenticator binding is the step that turns a possession or inherence factor into meaningful proof of account ownership. Without a correct binding between an authenticator and a subscriber account, presenting even a cryptographically strong authenticator proves nothing about who the holder is, the device is anonymous until it is associated with a specific account. In most deployments, the integrity of the entire authentication flow depends on this association being established correctly and protected against tampering, because everything that follows sign-in assumes the bound authenticator genuinely belongs to the legitimate account holder.

Because binding determines which authenticator is trusted for a given account, weaknesses in the binding process are a recurring target. If an attacker can bind an authenticator they control to a victim's account, or intercept the binding step during enrollment, they can subsequently authenticate as that user without ever needing to defeat the authenticator's cryptography. This is why the mechanism used to establish the binding, and the assurance that surrounds it, matters as much as the strength of the authenticator itself. Per NIST SP 800-63B, the binding may be established through several mechanisms, such as choosing an associated authenticator secret or deriving one using a verifier identifier, and the appropriate method depends on the authenticator type and deployment profile.

Authenticator binding also shapes recovery and portability behavior. In WebAuthn/FIDO2 contexts, whether a bound credential is device-bound or syncable affects how an account can be recovered if a device is lost and how tightly the credential is tied to specific hardware. For example, passkeys in Microsoft Entra's Authenticator app are described as device-bound, meaning the passkey does not leave the device on which it was created. These distinctions have direct consequences for operational resilience and should be evaluated per platform and configuration rather than assumed.

Who it's relevant to

IAM Engineers

Engineers implementing authentication flows need to choose and configure a binding mechanism appropriate to the authenticator type and deployment profile, for example, whether binding relies on an associated authenticator secret or a secret derived from a verifier identifier, as described in NIST SP 800-63B. In WebAuthn/FIDO2 deployments, they must account for how credentials are registered and whether resulting passkeys are device-bound or syncable, since this affects recovery paths and portability.

Security Architects

Architects designing authentication assurance depend on sound authenticator binding, because the trust placed in a strong authenticator is only as good as the association linking it to the correct account. They should evaluate how binding is established and protected, keeping in mind that binding behavior, such as device-bound versus syncable passkeys, varies by platform and configuration and must be assessed per deployment rather than assumed.

Compliance and Audit Leads

Because authentication requires some form of binding between an identity and the authenticator used to confirm it, auditors reviewing authentication controls should verify that binding is established through recognized mechanisms and aligns with the relevant NIST SP 800-63B guidance for the target assurance level. They should treat binding as an authentication control distinct from authorization and separate from the identity-proofing steps that precede it.

System Administrators

Administrators managing enrolled authenticators handle the practical consequences of binding decisions, including how users register devices and recover access when a device is lost. Where credentials are device-bound, such as passkeys in the Microsoft Entra Authenticator app, which do not leave the device on which they were created, recovery planning must account for the fact that the bound authenticator cannot simply be moved to another device.

Inside Authenticator Binding

Authenticator

The cryptographic device, software module, or credential (for example a FIDO2 security key, platform authenticator, or passkey) that a subscriber uses to prove possession of a factor during authentication.

Binding Event

The registration or enrollment step in which an authenticator is associated with a specific identity or account, typically establishing a durable link between the credential and the subscriber's identity record.

Subscriber Identity

The identity or account to which the authenticator is bound; binding presumes the identity was established through prior identification and, in most deployments, identity proofing appropriate to the assurance level.

Cryptographic Association

For public-key-based authenticators such as those built on FIDO2 and WebAuthn, the binding typically records a public key (and credential identifier) associated with the account, while the private key remains held by the authenticator. This binding supports later authentication, not authorization.

Binding Assurance Context

The conditions under which the binding occurred, such as whether it happened during initial enrollment, self-service addition of a new authenticator, or an administrator-driven action, which affects the trust that can be placed in the binding depending on configuration.

Common questions

Answers to the questions practitioners most commonly ask about Authenticator Binding.

Does binding an authenticator to a user's account authenticate the user?

No. Authenticator binding is a registration-time (enrollment) step that establishes an association between an authenticator and an identity or account. Authentication is the separate, subsequent runtime step in which that bound authenticator is used to verify a claimed identity. Binding creates the relationship; it does not by itself prove who is present at any given moment. In most deployments the binding ceremony should itself be protected by an appropriate level of assurance, because a weak binding process can undermine every later authentication that relies on it.

Is authenticator binding the same as authorization or granting access?

No. Binding is neither authorization nor access enforcement. It is concerned with establishing which authenticator belongs to which principal, which supports later authentication. What that principal is subsequently permitted to do is an authorization decision governed by an access control model such as RBAC, ABAC, PBAC, or ReBAC, and typically evaluated at runtime by a policy decision point. Conflating binding with authorization blurs the distinct steps of identification, authentication, and authorization.

How is a FIDO2/WebAuthn authenticator bound to an account during registration?

In a WebAuthn registration ceremony the authenticator typically generates a key pair and returns a public key credential, which the relying party stores and associates with the user account. The private key remains on the authenticator. This association is the binding. Depending on configuration, the relying party may also evaluate attestation to gain assurance about the authenticator's characteristics, though attestation handling varies by deployment and is sometimes disabled. Note that passkeys are WebAuthn credentials and may be synced or device-bound depending on the implementation, which affects what exactly is bound.

What assurance should the binding ceremony itself carry?

Because subsequent authentication strength is limited by the trust established at binding, the enrollment step should generally be protected commensurate with the intended assurance level. In many deployments this means requiring an existing authenticated session, step-up authentication, an identity-proofing step, or an out-of-band verification before a new authenticator is bound. The appropriate approach depends on your risk model, applicable assurance frameworks, and vendor capabilities; treat first-authenticator binding and adding additional authenticators as potentially distinct risk scenarios.

How should authenticator unbinding and rebinding be handled in the identity lifecycle?

Unbinding (removing an authenticator association) and rebinding (replacing or adding one) are lifecycle events that typically belong to identity governance and administration processes as well as self-service flows. Common considerations include revoking or invalidating the stored credential, ensuring recovery paths do not become a weaker binding channel than primary enrollment, logging the change for audit and certification purposes, and confirming that a user retains at least one usable authenticator to avoid lockout. The exact controls depend on configuration and vendor support.

Where is binding information stored, and how does it relate to directories and provisioning?

The association between an authenticator and an account is typically persisted by the relying party or identity provider, often alongside or referenced from the user record in a directory such as an LDAP-backed store or an IdP's user store. Provisioning protocols like SCIM generally manage account and attribute lifecycle rather than the cryptographic credential material itself, so authenticator binding data may be handled through provider-specific mechanisms rather than SCIM. Exact storage location and format vary by vendor and deployment, and should be documented as part of your architecture.

Common misconceptions

Binding an authenticator to an identity determines what that identity is allowed to do.

Authenticator binding is an authentication concern: it associates a credential with an identity so the subscriber can later prove who they are. What the authenticated principal may do is an authorization decision handled separately, typically by a PDP/PEP against RBAC, ABAC, PBAC, or ReBAC policy.

FIDO2, WebAuthn, and passkeys are interchangeable terms for the same thing being bound.

These are related but distinct: WebAuthn is the web API, FIDO2 encompasses WebAuthn together with the authenticator-side protocol, and passkeys are FIDO2/WebAuthn credentials, often discoverable and syncable, that get bound to an account. The binding records the resulting credential regardless, but the terms should not be treated as synonyms.

Once an authenticator is bound during enrollment, the binding provides the same assurance throughout its lifecycle.

Binding assurance depends on how and when the binding occurred and on ongoing lifecycle management. Self-service addition of a new authenticator, recovery flows, or administrative resets can weaken the trust in a binding depending on configuration, which is why binding is governed alongside credential lifecycle events.

Best practices

Treat authenticator binding strictly as an authentication-layer control and keep authorization decisions in a separate policy path so that possession of a bound credential never implicitly grants entitlements.

Require identity proofing or verification appropriate to the target assurance level before binding an authenticator during initial enrollment, and record the binding context for later audit.

For public-key authenticators based on FIDO2 and WebAuthn, store and manage the associated public key and credential identifier while ensuring private keys remain in the authenticator, and note that a signed assertion is not the same as an encrypted one.

Apply step-up or re-authentication before allowing self-service addition, replacement, or removal of a bound authenticator, since these lifecycle events can otherwise weaken binding assurance depending on configuration.

Govern binding and unbinding as part of the credential lifecycle, including timely deprovisioning of bound authenticators when an identity is deactivated, so stale bindings do not persist.

Log binding, rebinding, and revocation events with sufficient detail to support access reviews and certification, keeping these governance records distinct from runtime token validation events.