Direct answer: on 25 August 2026, WebAuthn Level 3 became a W3C Recommendation. NIST SP 800-63B-4 (published July 2025) explicitly covers syncable passkeys at AAL2: syncable authenticators may be used at AAL2 but not at AAL3, because syncing means the key is exportable and violates AAL3's non-exportable requirement. AAL2 must offer a phishing-resistant option; AAL3 requires phishing resistance, a non-exportable key and two distinct factors. Before rollout, answer four questions: Are you targeting AAL2 or AAL3? Is the passkey multi-device (BE) or single-device? Is UV (user verification) true? Does device-loss/recovery meet the bar? WebAuthn L3's BE/BS flags, conditional UI, hybrid transport, JSON serialization, related origins and signal methods map directly to these engineering questions.
This guide is for product, identity/authentication, frontend/backend, risk and IT teams. It explains WebAuthn Level 3 and NIST 800-63B-4 requirements for passkeys, AAL2/AAL3 selection, multi-device vs single-device credentials, BE/BS/UV flags, conditional UI/hybrid, account recovery, common failure modes and a 90-day rollout checklist. Rules come from the W3C WebAuthn Level 3 Recommendation (25 August 2026), NIST SP 800-63B-4 (July 2025, including Appendix B on syncable authenticators) and FIDO Alliance passkey material, all accessed 8 November 2026. Official facts, editorial advice and items to confirm are kept separate. This is not compliance or procurement advice.
(1) A passkey is not one thing: syncable multi-device credentials fit AAL2; AAL3 requires non-exportable hardware/device-bound keys. (2) "We support WebAuthn" is not enough: inspect UV, BE and BS flags to decide whether to accept synced credentials and whether to treat the authenticator as multi-factor. (3) Recovery is half the project: lost devices, disabled sync, recovery codes/contacts and notifications must work before rollout, or users get locked out.
Timing and standards: WebAuthn L3 + NIST 800-63B-4
WebAuthn Level 3 became a W3C Recommendation on 25 August 2026, replacing Level 2 from 2021. NIST SP 800-63B-4 was published in July 2025, replacing 800-63B from 2020, and its normative Appendix B is dedicated to syncable authenticators. Together, passkeys are no longer "experimental login": they have explicit assurance levels, flags and recovery requirements. For consumer sites, AAL2 is usually enough; AAL3's hardware-bound keys are for high-value, enterprise or government scenarios.
| Standard/version | Date | What it means for passkeys |
|---|---|---|
| W3C WebAuthn Level 3 | 25 Aug 2026 Recommendation | BE/BS, conditional UI, hybrid, JSON, related origins, signal methods |
| NIST SP 800-63B-4 | July 2025 | AAL2 allows syncable authenticators; AAL3 requires non-exportable |
| NIST SP 800-63B-4 Appendix B | Normative | Synced-key encryption, access control, AAL2-equivalent MFA, UI disclosure |
| FIDO Alliance passkey material | Ongoing | Passkey terminology, UX/implementation guidance, certification programs |
Sources: W3C WebAuthn Level 3 Recommendation (25 August 2026); NIST SP 800-63B-4 (July 2025); FIDO Alliance Passkey Central (accessed 8 November 2026). Editorial summary; specific clauses follow the standards.
AAL selection: where passkeys fit
NIST is direct: AAL1 is single-factor; AAL2 requires two distinct factors and must offer a phishing-resistant option; AAL3 requires phishing resistance plus a non-exportable authentication key plus two distinct factors. A syncable passkey's key enters a sync fabric and is inherently exportable, so it can only support AAL2; AAL3 needs a device-bound/hardware key (such as a FIDO2 security key) or another non-exportable protocol. Another key point: if UV (User Verified) is not true, the verifier should treat the authenticator as single-factor, not as AAL2 multi-factor.
| Assurance level | NIST requirement | Passkey usability | Typical use |
|---|---|---|---|
| AAL1 | Single-factor; broad authenticators | Usable (not required) | Low-risk accounts/content sites |
| AAL2 | Two distinct factors; must offer phishing-resistant option | Syncable passkeys usable (subject to Appendix B) | E-commerce, SaaS, consumer accounts |
| AAL3 | Phishing-resistant + non-exportable key + two factors | Syncable passkeys not usable | Enterprise admins, high-value/government |
| UV=false | Treated as single-factor | Cannot alone satisfy AAL2 multi-factor | Needs another factor/step-up |
| Sync-fabric access | AAL2-equivalent MFA | The sync fabric itself must be protected | Platform/password-manager responsibility |
Sources: NIST SP 800-63B-4 Section 2 and Appendix B.2/B.3 (July 2025). Editorial summary; "passkey usable" assumes the standard's requirements are met; implementation depends on the platform/authenticator.
Multi-device vs single-device: reading BE/BS flags
WebAuthn Level 3 adds BE (Backup Eligible) and BS (Backup State) flags to authenticator data: BE says whether the credential may be backed up/synced and is a permanent property set at creation; BS says whether it is currently backed up and may change over time. BE=true credentials are multi-device credentials (common passkeys); BE=false are single-device credentials. "Eligible" does not mean "actually synced": BE=true, BS=false means syncing is allowed but has not happened yet. High-assurance scenarios can use BE/BS to accept only single-device credentials or require a particular BS state.
| Flag/term | Meaning | Engineering use |
|---|---|---|
| BE = Backup Eligible | Whether the credential may be backed up/synced; permanent | Decide whether to accept multi-device passkeys |
| BS = Backup State | Whether it is currently backed up; can change | Risk/compliance policy can reference it; do not treat as permanent |
| Multi-device credential | BE=true, can sync across devices | Default consumer passkey form |
| Single-device credential | BE=false, device-bound | AAL3/high assurance/enterprise admins |
| UV = User Verified | Whether the user was verified locally (biometric/PIN) | UV=false is treated as single-factor |
| UP = User Present | Whether a user was present/interacted | Verifiers should confirm UP |
Sources: W3C WebAuthn Level 3 (§6.1, §6.1.3, §18.1.1 BE/BS additions); NIST SP 800-63B-4 Appendix B.3 (UP/UV/BE verification requirements). Editorial summary.
WebAuthn L3 capabilities that affect UX and operations
Level 3 is not just protocol cleanup; it adds the engineering pieces passkeys need at scale: conditional mediation puts passkeys in the username/login autofill (create and get); hybrid transport lets a desktop browser use a phone as the authenticator; JSON serialization simplifies client/server exchange; related origins supports multiple domains under one organization; signal methods let the RP tell the authenticator that a credential was deleted/updated; BE/BS lets the RP evaluate sync state. These directly affect conversion, support tickets and account recovery.
| Capability | Purpose | Rollout note |
|---|---|---|
| Conditional UI | Passkeys appear in username/login autofill | Works for create/get; handle unsupported browsers |
| Hybrid transport | Desktop uses a phone/cross-device authenticator | QR/Bluetooth; handle timeouts/fallback |
| JSON (de)serialization | Simplify frontend/backend transport | Server still validates origin/RP ID/challenge |
| Related origins | Share credentials across an organization's domains | Strict configuration; avoid cross-tenant leakage |
| Signal methods | Notify authenticators of credential changes/deletion | Clean up orphaned credentials; sync after recovery |
| BE/BS flags | Determine sync eligibility/current state | Do not assume BS is permanent |
| Cross-origin iframe create | Create credentials in embedded contexts | Permissions/privacy policy must allow it |
Sources: W3C WebAuthn Level 3 §18.1.1 "Substantive Changes" (25 August 2026). Editorial summary; API/browser support follows implementation and compatibility tables.
Account recovery: where passkey projects fail
NIST 800-63B-4 has explicit recovery requirements: accounts without identity proofing must use saved/issued recovery codes or a recovery contact; AAL2 accounts require "two recovery codes from different methods", or "one recovery code plus a single-factor authenticator bound to the account", or repeated identity proofing; AAL3 at IAL1/2 follows AAL2, while IAL3 requires a biometric comparison and possibly the original evidence; all recovery must notify the user. For consumer passkeys, the minimum practice is: at least two passkeys/security keys + recovery codes + a recovery contact + recovery notifications; do not make SMS/email reset the default backdoor.
| Scenario | NIST requirement | Product advice |
|---|---|---|
| No identity proofing | Saved/issued recovery code or recovery contact | Require recovery-code generation at enrollment |
| AAL2 | Two recovery codes from different methods; or one code + single-factor authenticator; or re-proofing | At least two recovery paths; avoid a single point |
| AAL3 (IAL1/2) | Same as AAL2 | Enterprise admins additionally use hardware keys |
| AAL3 (IAL3) | Biometric comparison + possibly original evidence | In-person/controlled process |
| Recovery notification | All recovery must notify | Email/SMS/in-app + delayed activation |
| Device loss | Suspend/invalidate/destroy promptly | Self-service loss reporting + support process |
Sources: NIST SP 800-63B-4 Sections 4.2.2/4.2.3/4.3 (July 2025). Editorial summary; consumer products are not automatically bound by NIST, but this is a useful baseline for high-value accounts.
Rollout path: optional first, default later
Do not delete passwords on day one. Start with optional passkeys alongside passwords/other factors, use conditional UI to improve discovery, and observe creation rate, login success, recovery tickets and cross-device success; then make passkeys recommended/default, and only later require them for high-value accounts. Every step needs a fallback: unsupported browser, user refusal, UV failure, sync disabled, lost device must all lead to a secure, recoverable path.
| Stage | Action | Exit criteria |
|---|---|---|
| 0. Assess | Choose AAL, account value, compliance; inventory login/registration/recovery | AAL/credential/recovery strategy signed off |
| 1. Optional | Add passkeys to registration/login; keep password/OTP | Creation, success and error rates observable |
| 2. UX | Conditional UI, hybrid, clear copy, device-management page | Conversion up, tickets down |
| 3. Recovery | Multiple passkeys, recovery codes/contact, notifications, loss reporting | Recovery drill passes; no single point |
| 4. Recommended | Prioritize passkeys on login; prompt new users to create | Passkey login share stable |
| 5. Require/high assurance | High-value accounts require AAL2/AAL3; restrict BE/sync | Risk/compliance review passes |
Editorial rollout path, not an official template; AAL, enforcement scope and recovery requirements follow business risk, NIST/industry rules and legal advice.
Common failure modes
Passkey failures are rarely "the crypto is wrong"; they are product/operations issues: users assume a passkey always syncs and lose it when changing phones; the RP does not check UV and treats single-factor as multi-factor; BE/BS policy is hard-coded and rejects users after syncing; conditional UI has no fallback; related origins are misconfigured and leak across tenants; recovery still relies on SMS/email and bypasses the passkey; an enterprise mandates AAL3 but issues syncable passkeys; signal methods are not integrated, so deleted credentials remain in authenticators.
| Failure mode | Symptom | Control |
|---|---|---|
| Assuming passkeys always sync | Cannot log in after device change/sync off | Multiple devices/passkeys + recovery codes |
| UV not checked | Single-factor treated as AAL2 | Require UV=true or step-up |
| BE/BS policy hard-coded | Credential rejected after syncing | BS can change; leave room in policy |
| No conditional UI fallback | Some browsers show no entry point | Feature detection + traditional button |
| Related origins misconfigured | Cross-tenant/brand credential leakage | Strict allowlist + testing |
| Recovery uses SMS/email | Bypasses passkey phishing resistance | Recovery codes/contacts + delayed notice |
| AAL3 uses syncable passkeys | Non-exportable requirement not met | Hardware keys/device-bound credentials |
| Signal methods not integrated | Deleted credentials still work | Notify authenticators after delete/recovery |
Editorial failure list, not an official checklist; errors/compatibility follow the WebAuthn spec, browser/platform documentation and NIST requirements.
90-day rollout checklist
Use the first 90 days to connect AAL/credential type, registration/login UX, recovery and monitoring. The order is assess, optional passkeys, conditional UI/hybrid, recovery/loss reporting, metrics, recommended/required. Do not enforce passkeys without a recovery drill, and do not treat "WebAuthn support" as "AAL2 compliance".
| Phase | Action | Output |
|---|---|---|
| Weeks 1-2 | Choose AAL, account tiers, compliance/recovery requirements; inventory login/registration/recovery | AAL/credential strategy |
| Weeks 2-3 | Add passkeys to registration/login; keep passwords/OTP | Observable creation/login funnel |
| Weeks 3-5 | Conditional UI, hybrid, error copy, device-management page | UX release, compatibility matrix |
| Weeks 5-7 | Multiple passkeys, recovery codes/contact, loss reporting, notifications | Recovery SOP, drill report |
| Weeks 7-9 | Check UV/BE/BS; integrate signal methods; risk policy | Policy config, logs |
| Weeks 9-11 | Graduate to recommended; monitor creation/success/tickets | Graduation report |
| Weeks 11-12 | Assess enforcement/high assurance; update compliance docs | Enforcement scope, audit material |
Editorial rollout advice, not an official template; AAL, enforcement and recovery/compliance requirements follow business risk, NIST/industry rules and legal advice.
FAQ
Can passkeys satisfy AAL2?
Yes. NIST 800-63B-4 allows syncable authenticators at AAL2 if Appendix B is met: key encryption, AAL2-equivalent MFA for sync-fabric access, user visibility into sync state, etc. AAL2 also requires a phishing-resistant option.
Can passkeys satisfy AAL3?
Not syncable passkeys: syncing means the key is exportable, violating AAL3's non-exportable requirement. AAL3 uses device-bound/hardware keys (such as a FIDO2 security key) or another non-exportable protocol.
What is the difference between BE and BS?
BE (Backup Eligible) says whether the credential may be backed up/synced; it is set at creation and permanent. BS (Backup State) says whether it is currently backed up and can change. BE=true is a multi-device credential; BE=false is single-device. "Eligible" does not mean "already synced".
Does UV matter?
Yes. NIST requires verifiers to inspect UV; if UV is not true, treat the authenticator as single-factor, not AAL2 multi-factor. High-assurance scenarios should require UV=true or perform step-up.
What is conditional UI?
WebAuthn L3 conditional mediation puts passkeys into username/login autofill; create and get are supported. It improves discovery, but implement feature detection and a traditional-button fallback.
What happens when a user loses a phone?
Provide at least a second passkey/security key, recovery codes/contact, a loss-reporting process and recovery notifications. NIST AAL2 recovery requires "two recovery codes from different methods" or "one code + a single-factor authenticator", etc. Do not use SMS/email reset to bypass passkey phishing resistance.
How should enterprises/high-value accounts choose?
Choose AAL by risk: AAL2 passkeys for general staff; AAL3 non-exportable hardware keys for admins/high-value/government, with BE/sync restrictions. Enforcement scope needs risk/compliance review.
Should we use attestation?
Consumer passkeys usually do not need strong attestation; enterprise/AAL3 can use attestation to verify authenticator capabilities/source. Attestation adds privacy/compatibility costs, so decide by scenario.
Research method and limitations
This article separates "official rule facts" from "editorial advice." The WebAuthn Level 3 Recommendation date, BE/BS, conditional UI, hybrid, JSON, related origins and signal methods come from W3C WebAuthn Level 3 (25 August 2026, §18.1.1). The AAL1/2/3 definitions, AAL2 phishing-resistant option, AAL3 non-exportable key, syncable authenticators only at AAL2, UV/UP/BE verification and Appendix B sync-key/access-control requirements come from NIST SP 800-63B-4 (July 2025). Account-recovery requirements come from Sections 4.2.2/4.2.3/4.3. The rollout path, failure modes and 90-day checklist are editorial; FIDO Alliance passkey material provides terminology/UX background.
Eight limitations: (1) this is not compliance/legal/procurement advice; (2) browser/platform support for WebAuthn L3 is not checked individually; (3) all authenticator/password-manager sync implementations are not covered; (4) attestation, PRF, largeBlob and other extensions are not expanded; (5) product-specific AAL certification/audit is not assessed; (6) enterprise IdP/SSO integration details are not covered; (7) no real user conversion/support-ticket testing is included; (8) standards/implementations may change, so recheck W3C/NIST/platform documentation before rollout.
Sources and basis
- W3C, Web Authentication: An API for accessing Public Key Credentials — Level 3 (Recommendation, 25 August 2026): w3.org/TR/webauthn-3. BE/BS, conditional UI, hybrid, JSON, related origins, signal methods, §18.1.1 changes. Accessed 8 November 2026.
- NIST, SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management (July 2025): csrc.nist.gov/pubs/sp/800/63/b/4/final. AAL1/2/3, Appendix B syncable authenticators, UV/UP/BE, recovery requirements. Accessed 8 November 2026.
- NIST, SP 800-63B-4 PDF: nvlpubs.nist.gov/.../NIST.SP.800-63b-4.pdf. Appendix B and Section 4.2 text. Accessed 8 November 2026.
- FIDO Alliance, Passkey Central: fidoalliance.org/passkeys. Passkey terminology and implementation/UX material. Accessed 8 November 2026.
Data cut-off 8 November 2026; standards/implementations follow W3C, NIST, FIDO and platform documentation; this is not compliance, legal or procurement advice.