A WebAuthn credential carries two flags. Backup eligibility (BE) says whether it can be copied to other authenticators, and backup state (BS) says whether it currently is. A site can read both to tell multi-device passkeys from single-device ones and set recovery and risk rules to match.
What a passkey is, in spec terms
The WebAuthn specification lists "passkey" as a term for a discoverable credential, also called a resident key. It is a credential the authenticator stores so that it can produce an assertion given only the relying party ID, without the site supplying a credential ID.
Credentials are scoped to a relying party. The RP ID, set at creation, is a core property that decides where the credential can be used, and the browser and authenticator enforce it together. That is why a passkey does not work on a look-alike phishing domain.
The two flags
Backup eligibility (BE). Set by the authenticator at creation and permanent. Backup eligible credentials are multi-device credentials. Others are single-device credentials.
Backup state (BS). Shows whether a multi-device credential is currently backed up, meaning a copy may exist on another authenticator through peer to peer sync, cloud sync or manual import and export. It can change over time.
The spec does not spell out "synced equals multi-device and device-bound equals single-device" in so many words, but the definitions point that way.
Why a relying party should care
| Credential | Convenience | Loss of one device | Risk consideration |
|---|---|---|---|
| Multi-device (BE set) | High | Survives | Security also depends on the sync provider account |
| Single-device (BE not set) | Lower | Credential is gone | Tied to one authenticator |
Practical consequences:
- Users with only single-device credentials need a tested recovery path, or they lock themselves out. See passkey recovery design.
- For sensitive actions you may want a single-device credential, a security key, or an extra check, depending on your risk model.
- Store the flags at registration and check them at sign in. The BS value may change, which can be a signal worth logging.
User verification caution
The spec says a relying party may treat the user verification flag as an authentication factor only once the credential's uvInitialized value is true. Until then, do not rely on the UV flag.
Attestation
Attestation gives verifiable evidence about an authenticator's origin. Many consumer sites do not need it. If you do, plan how you will validate it and what you will do with the answer.
Implementation checklist
- Record BE and BS at registration, and BS at each sign in.
- Offer at least two credentials per account, ideally on different authenticators.
- Build and test recovery before you remove passwords.
- Decide which actions need a stronger or single-device credential.
- Explain to users, in plain words, where their passkey lives.
Quick check
Can BE change after creation?
No. It is permanent. BS can change as the credential is backed up or removed from backup.
Does a synced passkey work on a fake site?
No. The RP ID scoping means the credential is only offered to origins belonging to the real relying party.
Sources
Last reviewed: 19 October 2026.
