Binding Sessions to Credential Backup State

The backup bits tell you whether the credential that just signed a user in would survive them losing the device. Carrying that into the session turns two common policies — prompting for a second passkey, and weighting a risk decision — from guesswork into something concrete. This page covers what to record, when to write it, and why durability must not be conflated with assurance. It sits under Server-Side Session Management with Passkeys.

Bit Reference

BE BS Meaning What it should drive
clear clear device-bound; lost with the hardware prompt for a second credential
set clear eligible, not currently synced suggest enabling sync, or a second credential
set set synced; survives device loss no prompt needed
clear set contradictory treat as malformed

The bits appear in authenticatorData on every ceremony, registration included, so a credential’s durability is known from the moment it is created.

What the backup bits let a session express Recording durability alongside assurance turns two vague policies into concrete ones. Four decisions, all currently made by guesswork nag or do not nag prompt for a second credential only where BE is clear risk weighting a change in BS is context, not an alarm recovery guidance tell a user with a device-bound credential what will happen if they lose it audit narrative explain later why an account was or was not considered resilient

Root Cause Analysis

1. Never reading them. The most common state, and the reason products either nag everybody to add a second passkey or nag nobody. Both are wrong for half the population.

2. Reading them once at registration. The state changes: a user enables sync, restores a device, or moves to a platform account without backup. A value captured at enrolment and never refreshed will be wrong for a growing share of credentials.

3. Treating a change as a security event. The bits move for entirely ordinary reasons, and alerting on the transition buries the signals that matter under routine platform behaviour.

4. Conflating durability with assurance. A synced credential is not less trustworthy than a device-bound one; it is more likely to still exist next month. Weighting a risk score as though sync were suspicious punishes exactly the configuration the ecosystem is moving towards.

Carrying the bits forward Read on every assertion, persisted when changed, and copied into the session alongside the verification result. One conditional write on a path that already writes the counter assertion flags byte read compare against the stored values persist only when changed session durability recorded alongside assurance Persisting only on change keeps the write off the hot path for the overwhelming majority of assertions.

Step-by-Step Resolution

Step 1 — decode both bits at the parse boundary

Named booleans, produced once, alongside the user-verification flag.

Step 2 — reject the contradictory combination

Backup state set with eligibility clear is not a state the specification defines. Treat the response as malformed.

Step 3 — persist on change only

Compare against the stored values and write only when they differ, with a timestamp. This is one conditional update on a path that is already writing the signature counter.

Step 4 — put durability in the session

Alongside the credential reference, the verification result and the authentication time. Downstream policy then has everything it needs without a second query.

Step 5 — drive the prompt from the bits, not from a count

“You have only one passkey” is the wrong test; a single synced passkey is resilient. “This passkey will not survive losing this device” is the right one, and it is answered by the eligibility bit.

Durability is not assurance How strongly a person was verified and how likely the credential is to survive are independent axes. Two axes that are frequently collapsed into one assurance — how strongly verified the user-verification bit the freshness of the ceremony which credential signed durability — how likely to survive backup eligibility current backup state whether a second credential exists Collapsing them produces policies that nag resilient users and ignore fragile ones.

Verification and Testing

Configure a virtual authenticator to report each combination in turn and assert that your parse, your persistence and your prompt logic behave correctly for all three valid states plus the malformed one.

Test the transition explicitly: two assertions for the same credential with different backup states, asserting that the second updates the stored value and that a session issued afterwards carries the new one. A persistence layer that upserts only on first sight will silently fail this.

Assert that a synced credential does not trigger the second-credential prompt. It is the case most likely to regress, because the naive implementation counts credentials rather than reading bits.

Pitfalls

1. Counting credentials instead of reading bits. Produces prompts for users who need none and silence for users who need one.

2. Writing on every assertion. Unnecessary; the values change rarely.

3. Surfacing the bit names to users. Translate them: “saved to your account and available on your other devices” is the sentence that means something.

Frequently Asked Questions

Do the backup bits reveal anything about the user’s platform account?

Only that the credential is eligible for synchronisation and whether it currently is. They do not name the account, the provider or the other devices, and they are not a fingerprinting surface — every synced passkey on a given platform reports the same pair.

Should a device-bound credential be treated as higher assurance?

Only if you have a written requirement that credentials must not be syncable, in which case attestation rather than these bits is the mechanism you need. On its own, a device-bound credential is simply less durable, which is a reason to ask for a second one rather than to trust it more.

What if the bits change in the middle of a session?

Nothing needs to happen immediately. Record the new state, and let the next session or the next policy evaluation pick it up. A change is information about the credential’s durability rather than about the legitimacy of the current session.

Can I use these bits to decide whether to allow a sensitive action?

Indirectly and cautiously. Durability is not assurance: a synced credential is not a weaker proof of possession. Where a genuine requirement exists for hardware-bound credentials on high-value actions, express it through attestation and record it at enrolment rather than inferring it from these bits.

Should the settings page show backup state?

In translated form, yes. Telling a user which of their passkeys will survive losing a device is genuinely useful and is the information that makes the second-credential suggestion make sense when it appears.

Do the bits appear during registration too?

Yes, in the same place. Recording them at enrolment gives you a starting state and lets the post-registration prompt fire immediately when the credential is device-bound, which is a better moment than any later one.

What does a healthy distribution of these bits look like?

In a consumer product, heavily weighted towards both bits set, because synced platform passkeys dominate new enrolments. A meaningful share of eligible-but-not-backed-up credentials usually means a population that has sync disabled — worth knowing, because those users are one lost device away from recovery and are invisible if you only count credentials. A large device-bound share points at either hardware keys or a managed-device population, both of which are legitimate and both of which should be driving a second-credential prompt.

Tracking that distribution over time is also the cheapest way to notice a platform behaviour change, since a shift in the mix usually precedes any announcement and shows up first as a change in how many of your users appear to need a second credential.

Should the prompt for a second credential ever be mandatory?

No. Blocking access until a user adds a second passkey converts a helpful suggestion into a lockout for anyone who is not currently holding a second device, which includes most people at the moment they are being asked. Show it after a successful sign-in, cap how often it appears, record dismissals per account rather than per device, and let it be dismissed permanently. A prompt that cannot be escaped teaches people to distrust the whole feature.

Related