WebAuthn backup eligibility and backup state answer different passkey questions
Two flags in WebAuthn authenticator data describe a credential's backup posture. Backup Eligibility, or BE, says whether the credential can be backed up. Backup State, or BS, says whether it is currently backed up. The names are close enough to invite shortcuts. The flags answer questions about credential storage, not about the person using the authenticator or the security of every device in a sync group.
The BE flag is set when a credential is created and is not expected to change. A credential that is not backup-eligible is a single-device credential. A backup-eligible credential may be synchronized by a passkey provider or restored through a backup service. The BS flag can change as the provider updates the credential's backup status. A relying party should not reinterpret those flags as a guarantee that a specific human owns the account or that a compromised provider cannot copy the credential.
Policy still belongs to the relying party. A high-risk administrative action may require a device-bound credential, a managed authenticator, an additional approved factor, or a recent user-verification ceremony. A consumer application may deliberately accept synced passkeys because recovery and multi-device access matter more than resisting every possible credential-copy scenario. Either decision is defensible when the threat model and recovery path are explicit.
Rejecting every backup-eligible credential is a common but blunt rule. It can exclude security keys that implement backup poorly, operating-system passkey providers, or users who cannot afford a second device. A better design records the registration flags, explains why a specific authenticator is unacceptable, and offers a supported alternative. If the flags are not available from the client or are inconsistent with the attestation policy, fail closed only for the flows that genuinely require the stronger property.
The back-end should store the credential identifier, public key, sign count, AAGUID if available, and the registration-time BE value. Record BS as observed state, with a timestamp and the source ceremony. Do not silently overwrite the original registration facts when a later assertion reports a different BS value. Audit the change and decide whether the policy for that account or role should change.
Signature counters are weak evidence for synced credentials because the authenticator implementation decides whether to increment them. A zero or unchanged counter is not automatically proof of cloning. Use counter anomalies as one signal among device history, session context, impossible travel, and account recovery events. If a credential is cloned through a provider compromise, the relying party may see valid signatures with no counter anomaly at all.
Recovery deserves as much design attention as authentication. A user who loses a synced provider should be able to enroll a new credential through a controlled process. An attacker who compromises the account should not be able to keep an old credential active by completing the recovery flow. Revoke the old credential record, invalidate its sessions, notify the account owner through a separate channel, and test the change with a fresh authentication ceremony.
The flags are useful facts about a passkey's storage model. They become misleading when they are treated as a full identity assurance score. Define the authentication property each application needs, capture the evidence that supports it, and document the exception path for users who cannot meet it.
Top comments (0)