Passkeys make authentication easier because users can sign in without a password and, on many platforms, reuse a credential across devices. That convenience changes the evidence available to a relying party. A credential that can be restored from a cloud account is not equivalent to a single hardware key that never leaves one device. WebAuthn exposes signals that help an application reason about that difference, but the signals need careful interpretation.
The Web Authentication specification defines authenticator data fields that describe whether a credential is backup eligible and whether it is currently backed up. The terminology matters. Backup eligibility describes whether the credential can be backed up at all. Backup state describes whether the authenticator reports that it is currently backed up. A relying party should not treat either flag as a complete security assessment by itself.
Why the flags exist
A synced passkey may be stored by a platform credential manager and made available on more than one device. This can improve account recovery and reduce the chance that a lost phone locks a user out. It also creates a new trust dependency on the credential manager account, its recovery process, and the devices that can access the synchronised material.
A device-bound credential has different properties. It may be more resistant to remote account takeover, but it can be lost with the device and may require a separate recovery process. Neither model is universally better. The relying party needs to know which assurance properties it is making decisions about.
For a workforce application that administers critical infrastructure, a synced credential may still be appropriate for normal sign-in while an additional device-bound factor or approval step is required for sensitive actions. For a consumer service, requiring a hardware security key for every user may create a recovery burden that leads to weaker workarounds. The control should match the action and the threat model.
Registration is where to record the signal
Read the authenticator data during registration and store the reported backup eligibility and backup state alongside the credential. Do not infer the values from the authenticator's display name or the user's device type. A platform authenticator can support multiple storage models, and a security key can be used in ways that do not reveal the entire device history.
Record when the values were observed and through which authenticator model or transport, where available under the platform's privacy constraints. The registration record becomes a historical statement, not a permanent description of the credential. A credential may be eligible for backup and later be reported as backed up or not backed up depending on the authenticator's state.
If authentication responses include updated flag values, compare them with the record and define how the application handles a transition. A transition can be legitimate, such as a user enabling cloud synchronisation. It can also indicate an unexpected authenticator change. The response should depend on risk: step up, notify the user, require an administrator review, or simply update the record.
Do not turn a flag into a pass/fail verdict
A backup-eligible credential is not automatically insecure. The credential manager may provide strong device binding, encrypted recovery, and phishing-resistant authentication. A backup state of true can improve availability and still be acceptable for many accounts.
Conversely, a claim that a credential is device-bound is not proof that it is immune to theft. Malware on the device, a compromised browser process, or a malicious extension may still influence an authentication ceremony. The flag describes an authenticator property; it does not describe the endpoint's health.
Use the flag as one input in a policy that also considers user role, device posture, network context, session age, and action sensitivity. Avoid writing a policy that silently rejects every synchronised credential without providing a recovery path. Users who cannot complete the stronger path may otherwise create shadow accounts or store recovery codes in insecure places.
Test the policy against real user journeys
Build test cases for new registration, normal sign-in, credential migration, device loss, account recovery, and a changed backup state. Verify the application's behavior when the flags are absent, malformed, or inconsistent with the credential record. A missing value is not evidence of a safer credential.
Test cross-platform flows with more than one browser and authenticator provider. Some authenticators present a credential as discoverable, while others require a username or a different flow. The user experience should still communicate why a sensitive action is being challenged and what the user can do next.
Provide an administrator path for exception review. The reviewer should see the credential's recorded properties, the authentication history, and the business reason for the exception. Do not let a help-desk operator change the credential's assurance classification without an audit trail.
Keep recovery inside the same trust boundary
A passkey is only one part of account security. The recovery process can bypass it if an attacker can reset the account through email, SMS, or a support agent. Review the recovery channel, the identity proofing used to authorize a reset, and the notifications sent after a credential change.
Require reauthentication before adding a new passkey or changing the recovery method. Notify the user through a channel that does not depend on the account being recovered. Log the credential identifier, event type, user agent, and policy decision, but avoid storing unnecessary biometric or device identifiers.
Set a session lifetime that is appropriate for the credential assurance and action. A successful WebAuthn ceremony proves control of a credential at that moment. It does not prove that a long-lived session remains safe after the device is lost or the user changes role.
A useful signal, not a complete model
The backup eligibility and backup state flags give application teams a standard way to distinguish some credential storage models. They do not replace risk-based policy, endpoint security, recovery design, or user support. The right implementation records the signal, keeps it current, and explains how it changes access for specific actions rather than using it as a blanket label.