What is account binding?

A device key identifies a device, not a person. A username or display name identifies nothing at all, because anyone can type one. Something has to connect the key on a particular phone to the account a person already has, and record that connection somewhere others can rely on. That step is account binding.

NIST’s authentication guidelines use the same word. SP 800-63B defines authenticator binding as establishing an association between a specific authenticator and a subscriber account, so that the authenticator can authenticate for that account. The provider must keep a record of every authenticator bound to each account. WebAuthn describes the same idea for passkeys: its registration ceremony creates a public key credential and associates it with a user account, after which the user can sign in with it.

The pattern is short, and each step closes a specific gap:

1. Authenticate the account first. The person signs in with a method the account already trusts. NIST requires authentication at the account’s highest available assurance level, or at the level the new authenticator will be used at if that is lower, and a notice to the subscriber through a separate channel when an authenticator is added. A key added through a weak sign-in is only as trustworthy as that sign-in.
2. Issue a fresh nonce. The server generates a random value that has never been used and remembers it.
3. Sign it on the device. The device signs the nonce, and ideally the account and purpose, with its private key, and sends the signature with its public key.
4. Verify and record. The server checks the signature against the public key, checks the nonce is the one it issued and has not been used, and only then stores the binding: account, public key, device and time.

The nonce is what makes this challenge-response proof of possession rather than a replay. WebAuthn states that its challenges must be randomly generated by the relying party in an environment it trusts, such as the server, and that the returned value must match, because the protocol depends on randomised challenges to avoid replay attacks. A signature over something predictable could have been made earlier and copied.

Where an identifier is derived from the public key, such as a self-certifying identifier, the server should also recompute it from the key and check it matches, so the account is bound to the identifier other devices will actually see.

Binding needs the account server, so it normally happens while the device is online. What happens next decides whether the binding is useful offline. If the server signs a statement that says “this key belongs to this account”, an issuer-signed credential, any device holding the server’s public key can check that statement later with no connection.

Offline Protocol’s documentation follows this pattern. Its device identity guide says that for an existing account directory you bind the device key to the account by verifying a signature over a fresh server-issued nonce, checking the derived address, then storing the verified binding. OfflineID can then issue a signed credential linking the account, username and device address, with issue and expiry times and an Ed25519 signature; issuance fails if the account has no bound address. The docs add that a cached credential permits offline signature verification but does not establish current account status or replace application authorisation.

A related idea binds a token to a key rather than a key to an account. OAuth 2.0 Demonstrating Proof of Possession (DPoP, RFC 9449) sender-constrains access and refresh tokens: the client proves it holds a private key each time it uses the token, which lets the server detect a token replayed by someone who copied it. The two combine well. Account binding says which key belongs to the account, and proof of possession makes each later use show that key.

• It does not prove who the person is. It inherits whatever trust the original sign-in had.
• It does not grant permissions. Authorisation is a separate decision made against the account.
• It does not last for ever. NIST describes invalidation, sometimes called revocation, as removing the binding between the authenticator and the account, and requires it promptly when an authenticator is compromised or the subscriber asks.

Removing a binding on the server is instant. Telling offline devices about it is not, because they only learn of the change when updated information reaches them. Short expiry on signed bindings, and a plan for revocation while devices are offline, close that gap.