Passkeys — what really changed.
Passkey is the consumer-facing brand. Under the hood it's a WebAuthn credential with a specific posture: discoverable (resident on the authenticator), capable of cross-device flows, and — on consumer ecosystems — synced through the platform vendor. The critical engineering question isn't "what is a passkey", it's "is this passkey backup-eligible?".
BE / BS — the only flags that matter for posture
WebAuthn level 3 added two flag bits to authenticatorData:
- BE (Backup Eligible) — the credential is allowed to be backed up. Set at registration; immutable for the lifetime of the credential.
- BS (Backup State) — the credential is currently backed up. Can change over time as the user enables / disables sync.
The four combinations:
| BE | BS | Posture |
|---|---|---|
| 0 | 0 | Device-bound. Hardware key, smart card, TPM-bound platform credential. Lives where it was created. Highest assurance. |
| 1 | 0 | Backup-eligible, not yet backed up. Transitional state. Treat as if BS could become 1 at any time. |
| 1 | 1 | Synced passkey. Lives in iCloud Keychain, Google Password Manager, 1Password, etc. Convenience-first; recovery is platform-vendor's recovery. |
| 0 | 1 | Reserved / invalid combination. Should never appear. If it does, reject. |
For workforce identity in regulated industries, set policy BE = 0: only accept device-bound credentials, where compromise of the credential requires physical access to the authenticator.
For consumer login, accept everything — passkeys radically improve recoverability for users who would otherwise reuse passwords.
Discoverable vs non-discoverable
A discoverable credential (also called resident in CTAP1 parlance) lives on the authenticator and includes the userHandle. The authenticator can produce assertions without the RP supplying a credentialId — enabling true username-less flows. This is what makes "passwordless" feel passwordless: tap, pick an account from the device, done.
A non-discoverable credential is encoded inside the credentialId itself (as encrypted data the authenticator can decrypt). The credential lives on the server. To assert, the RP supplies allowCredentials — the user has already typed a username.
Discoverable credentials require storage on the authenticator. Limits range from ~25 (low-end smart cards) to thousands (platform authenticators). Non-discoverable have no storage limit on the authenticator side.
Cross-device authentication (hybrid transport)
The hybrid transport (formerly "caBLE") lets a passkey on one device authenticate a session on another. Mechanics: laptop browser shows a QR code, phone scans, both establish a BLE proximity check to prevent attacker-in-the-middle, and the phone’s passkey signs the laptop's WebAuthn ceremony.
Hybrid is what makes "sign in with your phone" possible without provisioning a new credential per laptop. The phone never leaves your hand; the laptop never gains access to the credential.
Enterprise policy — the practical levers
Three policy decisions decide whether your passkey rollout meets workforce requirements:
- BE policy — require
BE == 0for device-bound, allowBE == 1for convenience-first. - Attestation policy —
attestation: 'direct'+ AAGUID allow-list for high assurance;'none'for consumer. - UV policy — require
UV == 1for sensitive actions;UPalone for low-risk session refresh.
OnePass Card and OnePass USB Key both ship as BE = 0 — device-bound by construction. That is the right default for workforce deployments.
Companion reading
Passkeys vs Traditional MFA
What changes when MFA stops being a code and starts being a hardware-bound signature.
Read → PillarPlatform vs Roaming Authenticators
Choosing the right form factor — and the matching enrolment path.
Read → PillarDesigning Enterprise Passwordless Systems
What an end-to-end deployment really looks like.
Read →