直接答案：2026-08-25，WebAuthn Level 3 成为 W3C Recommendation；NIST SP 800-63B-4（2025-07 发布）则把“可同步的 passkey”写进了 AAL2：syncable authenticator 可以用于 AAL2，但不能用于 AAL3——因为同步意味着密钥可导出，违反 AAL3 的 non-exportable 要求。AAL2 必须提供抗钓鱼（phishing-resistant）选项，AAL3 要求抗钓鱼 + 非导出密钥 + 两个不同因素。落地时先回答四个问题：你要 AAL2 还是 AAL3？passkey 是 multi-device（BE）还是 single-device？UV（用户验证）是否为 true？丢失设备/恢复流程是否达标？WebAuthn L3 新增的 BE/BS 标志、conditional UI、hybrid transport、JSON 序列化、related origins、signal methods，正好对应这些工程问题。
本文面向产品、身份认证、前端/后端、风控和 IT 团队，解释 WebAuthn Level 3 与 NIST 800-63B-4 对 passkey 的要求、AAL2/AAL3 选型、multi-device/single-device 凭证、BE/BS/UV 标志、conditional UI/hybrid、账户恢复、常见失败模式和 90 天落地清单。规则来自 W3C WebAuthn Level 3 Recommendation（2026-08-25）、NIST SP 800-63B-4（2025-07，含 Appendix B syncable authenticators）与 FIDO Alliance Passkey 资料，均于 2026-11-08 访问。本文把“官方规则事实”“编辑建议”和“待确认项”分开写，不构成合规或采购建议。
① Passkey 不是“一个东西”：可同步的 multi-device 凭证适合 AAL2；AAL3 必须用 non-exportable 的硬件/设备绑定密钥。② 只看“有没有 WebAuthn”不够：要检查 UV、BE、BS 标志，决定是否接受同步凭证、是否按多因素处理。③ 恢复流程是 passkey 项目的一半：丢失设备、同步关闭、恢复码/恢复联系人、通知，都要在灰度前跑通，否则用户会被锁在门外。
时间与标准：WebAuthn L3 + NIST 800-63B-4
WebAuthn Level 3 在 2026-08-25 成为 W3C Recommendation，替代 2021 年的 Level 2；NIST SP 800-63B-4 在 2025-07 发布，替代 2020 年的 800-63B，并在 Appendix B（normative）专门讨论 syncable authenticators。两者叠加的结果是：passkey 不再是“实验性登录”，而是有明确保证等级、标志位和恢复要求的身份认证方案。对消费级网站，AAL2 通常足够；对高价值/企业/政府场景，才需要 AAL3 的硬件绑定密钥。
| 标准/版本 | 日期 | 对 passkey 的意义 |
|---|---|---|
| W3C WebAuthn Level 3 | 2026-08-25 Recommendation | BE/BS、conditional UI、hybrid、JSON、related origins、signal methods |
| NIST SP 800-63B-4 | 2025-07 | AAL2 允许 syncable authenticator；AAL3 要求 non-exportable |
| NIST SP 800-63B-4 Appendix B | normative | 同步密钥加密、访问控制、AAL2-equivalent MFA、UI 展示 |
| FIDO Alliance Passkey 资料 | 持续更新 | passkey 术语、UX/实施指南、认证项目 |
来源：W3C WebAuthn Level 3 Recommendation（2026-08-25）；NIST SP 800-63B-4（2025-07）；FIDO Alliance Passkey Central（访问 2026-11-08）。表中为编辑整理；具体条款以标准原文为准。
AAL 选型：passkey 能用到哪一级
NIST 的定义很直接：AAL1 单因素；AAL2 需要两个不同因素，并且必须提供抗钓鱼选项；AAL3 需要抗钓鱼 + non-exportable authentication key + 两个不同因素。syncable passkey 的密钥会进入同步云，天然可导出，所以只能支持 AAL2；AAL3 必须用设备绑定/硬件密钥（如 FIDO2 security key）或其它满足 non-exportable 的协议。另一个关键点：如果 UV（User Verified）没有为 true，验证方应把该认证器当作单因素处理，不能直接算 AAL2 的多因素。
| 保证等级 | NIST 要求 | passkey 可用性 | 典型场景 |
|---|---|---|---|
| AAL1 | 单因素；广泛认证器 | 可用（但不是必须） | 低风险账户/内容站 |
| AAL2 | 两个不同因素；必须提供抗钓鱼选项 | 可同步 passkey 可用（需满足 Appendix B） | 电商、SaaS、消费者账户 |
| AAL3 | 抗钓鱼 + non-exportable key + 两个因素 | 同步 passkey 不可用 | 企业管理员、高价值/政府 |
| UV=false | 按单因素处理 | 不能单独满足 AAL2 多因素 | 需额外因素/step-up |
| 同步云访问 | AAL2-equivalent MFA | 同步 fabric 本身要保护 | 平台/密码管理器责任 |
来源：NIST SP 800-63B-4 第 2 节、Appendix B.2/B.3（2025-07）。表中为编辑整理；“passkey 可用”指满足标准要求的前提下，具体实现仍要看平台/认证器。
multi-device vs single-device：BE/BS 标志怎么读
WebAuthn Level 3 给认证器数据增加了 BE（Backup Eligible） 和 BS（Backup State） 两个标志：BE 表示该凭证是否允许被备份/同步，是创建时确定的永久属性；BS 表示当前是否已被备份，可能随时间变化。BE=true 的凭证叫 multi-device credential（常见 passkey），BE=false 的叫 single-device credential（设备绑定）。注意“可同步”不等于“已同步”：BE=true、BS=false 表示允许同步但当前还没同步；高保证场景可以用 BE/BS 限制只接受 single-device 或要求 BS=true/false。
| 标志/术语 | 含义 | 工程用法 |
|---|---|---|
| BE=Backup Eligible | 凭证是否允许备份/同步；永久属性 | 决定是否接受 multi-device passkey |
| BS=Backup State | 当前是否已备份；可变 | 风控/合规策略可参考；不要当永久属性 |
| multi-device credential | BE=true，可跨设备同步 | 消费者 passkey 的默认形态 |
| single-device credential | BE=false，设备绑定 | AAL3/高保证/企业管理员 |
| UV=User Verified | 本地是否验证了用户（生物/PIN） | UV=false 按单因素处理 |
| UP=User Present | 是否有用户在场/交互 | 验证方应确认 UP |
来源：W3C WebAuthn Level 3（§6.1、§6.1.3、§18.1.1 新增 BE/BS）；NIST SP 800-63B-4 Appendix B.3（UP/UV/BE 的验证要求）。表中为编辑整理。
WebAuthn L3 新能力：UX 与运维直接相关
Level 3 不是只改协议细节，它补上了 passkey 规模化的工程能力：conditional mediation 让 passkey 出现在输入框自动填充里（create/get 都支持）；hybrid transport 让桌面浏览器用手机作为认证器；JSON 序列化简化前后端；related origins 支持同一组织多域；signal methods 让 RP 通知认证器“凭证已删除/已更新”；BE/BS 让 RP 判断同步状态。这些能力直接影响转化率、支持工单和账户恢复。
| 能力 | 作用 | 落地注意 |
|---|---|---|
| Conditional UI | passkey 出现在用户名/登录输入框自动填充 | create/get 都支持；要处理浏览器不支持 |
| Hybrid transport | 桌面用手机/跨设备认证 | 依赖二维码/蓝牙；做好超时/降级 |
| JSON (de)serialization | 简化前后端传输 | 服务端仍要校验 origin/RP ID/challenge |
| Related origins | 同一组织多域共享凭证 | 严格配置；避免跨租户串用 |
| Signal methods | 通知认证器凭证变更/删除 | 用于清理孤儿凭证、恢复后同步状态 |
| BE/BS flags | 判断同步资格/当前状态 | 策略不要假设 BS 永久不变 |
| Cross-origin iframe create | 嵌入式场景创建凭证 | 权限/隐私政策要允许 |
来源：W3C WebAuthn Level 3 §18.1.1 “Substantive Changes”（2026-08-25）。表中为编辑整理；具体 API/浏览器支持以实现和兼容性表为准。
账户恢复：passkey 项目最容易翻车的地方
NIST 800-63B-4 对恢复有明确要求：未做身份验证的账户，恢复必须用 saved/issued recovery code 或 recovery contact；AAL2 账户要“两种不同方法的 recovery code”或“一个 recovery code + 一个绑定账户的单因素认证器”，或重新做身份验证；AAL3 在 IAL1/2 时同 AAL2，在 IAL3 时要重新做生物比对并可能出示原始证据；所有恢复都要通知用户。对消费级 passkey，最低实践是：至少两个 passkey/安全密钥 + 恢复码 + 恢复联系人 + 恢复通知，不要把“短信/邮件重置”当成默认后门。
| 场景 | NIST 要求 | 产品建议 |
|---|---|---|
| 未身份验证账户 | saved/issued recovery code 或 recovery contact | 注册时强制生成恢复码 |
| AAL2 | 两种不同方法的 recovery code；或 1 code + 单因素认证器；或重新身份验证 | 至少两种恢复路径，避免单点 |
| AAL3（IAL1/2） | 同 AAL2 | 企业管理员额外硬件密钥 |
| AAL3（IAL3） | 生物比对 + 可能出示原始证据 | 线下/受控流程 |
| 恢复通知 | 所有恢复都要通知 | 邮件/短信/站内信 + 延迟生效 |
| 设备丢失 | 及时 suspend/invalidate/destroy | 自助挂失 + 客服流程 |
来源：NIST SP 800-63B-4 第 4.2.2/4.2.3/4.3 节（2025-07）。表中为编辑整理；消费级产品不当然受 NIST 约束，但可作为高价值账户的基线。
落地路径：先可选，再默认
不要一上来把密码删掉。先做“可选 passkey + 密码/其它因素并存”，用 conditional UI 提升发现率，观察创建率、登录成功率、恢复工单和跨设备成功率；再逐步把 passkey 设为推荐/默认，最后才考虑对高价值账户强制。每一步都要有降级路径：浏览器不支持、用户拒绝、UV 失败、同步关闭、设备丢失，都能回到安全且可恢复的流程。
| 阶段 | 动作 | 退出条件 |
|---|---|---|
| 0. 评估 | 确定 AAL、账户价值、合规要求；盘点登录/注册/恢复流程 | AAL/凭证类型/恢复策略签字 |
| 1. 可选 | 注册/登录加 passkey 选项；保留密码/OTP | 创建率、成功率、错误率可观测 |
| 2. UX | conditional UI、hybrid、清晰文案、设备管理页 | 转化提升、支持工单下降 |
| 3. 恢复 | 多 passkey、恢复码、恢复联系人、通知、挂失 | 恢复演练通过；无单点 |
| 4. 推荐 | 登录页优先 passkey；新用户引导创建 | passkey 登录占比稳定 |
| 5. 强制/高保证 | 高价值账户要求 AAL2/AAL3；限制 BE/同步 | 风险/合规评审通过 |
编辑整理的落地路径，不是官方模板；具体 AAL、强制范围和恢复要求以业务风险、NIST/行业规则和法务意见为准。
常见失败模式
passkey 的失败很少是“加密算法不对”，更多是产品/运维：用户以为 passkey 一定跨设备、结果换了手机没了；RP 没检查 UV，把单因素当多因素；BE/BS 策略写死，用户同步后反被拒；conditional UI 不支持时没有降级；related origins 配错导致跨租户串用；账户恢复仍靠短信/邮件，绕过 passkey；企业强制 AAL3 却发了可同步 passkey；signal methods 没接，删除的凭证还在认证器里。
| 失败模式 | 症状 | 控制 |
|---|---|---|
| 把 passkey 当必然跨设备 | 换机/同步关闭后无法登录 | 多设备/多 passkey + 恢复码 |
| UV 未检查 | 单因素被当 AAL2 | 要求 UV=true 或 step-up |
| BE/BS 策略写死 | 同步后凭证被拒 | BS 可变；策略留余量 |
| 无 conditional UI 降级 | 部分浏览器看不到入口 | 特性检测 + 传统按钮 |
| related origins 配错 | 跨租户/跨品牌串用 | 严格白名单 + 测试 |
| 恢复靠短信/邮件 | 绕过 passkey 的抗钓鱼性 | 恢复码/联系人/延迟通知 |
| AAL3 用可同步 passkey | 不满足 non-exportable | 硬件密钥/设备绑定 |
| signal methods 未接 | 删除的凭证仍可用 | 删除/恢复后通知认证器 |
编辑整理的常见问题，不是官方清单；具体错误/兼容性以 WebAuthn 规范、浏览器/平台文档和 NIST 要求为准。
90 天落地清单
先用 90 天把“AAL/凭证类型、注册/登录 UX、恢复、监控”跑通。顺序是：评估 → 可选 passkey → conditional UI/hybrid → 恢复/挂失 → 指标 → 推荐/强制。不要在没有恢复演练的情况下强制 passkey；也不要把“支持 WebAuthn”当成“满足 AAL2”。
| 阶段 | 动作 | 产出 |
|---|---|---|
| 第 1–2 周 | 确定 AAL、账户分层、合规/恢复要求；盘点登录/注册/找回 | AAL/凭证策略 |
| 第 2–3 周 | 注册/登录加 passkey 选项；保留密码/OTP | 可观测的创建/登录漏斗 |
| 第 3–5 周 | conditional UI、hybrid、错误文案、设备管理页 | UX 版本、兼容性矩阵 |
| 第 5–7 周 | 多 passkey、恢复码/联系人、挂失、恢复通知 | 恢复 SOP、演练报告 |
| 第 7–9 周 | 检查 UV/BE/BS；接 signal methods；风控策略 | 策略配置、日志 |
| 第 9–11 周 | 灰度到推荐；监控创建率/成功率/工单 | 灰度报告 |
| 第 11–12 周 | 评估强制/高保证；更新合规文档 | 强制范围、审计材料 |
编辑整理的落地建议，不是官方模板；具体 AAL、强制范围、恢复和合规要求以业务风险、NIST/行业规则和法务意见为准。
常见问题
Passkey 能满足 AAL2 吗？
可以。NIST 800-63B-4 允许 syncable authenticator 用于 AAL2，前提是满足 Appendix B：密钥加密、同步云访问用 AAL2-equivalent MFA、用户可查看同步状态等。AAL2 还要求提供抗钓鱼选项。
Passkey 能满足 AAL3 吗？
可同步 passkey 不行，因为同步意味着密钥可导出，违反 AAL3 的 non-exportable 要求。AAL3 要用设备绑定/硬件密钥（如 FIDO2 security key）或其它满足 non-exportable 的协议。
BE 和 BS 有什么区别？
BE（Backup Eligible）是凭证是否允许备份/同步，创建时确定、永久不变；BS（Backup State）是当前是否已备份，可变。BE=true 是 multi-device credential，BE=false 是 single-device credential；“可同步”不等于“已同步”。
UV 重要吗？
重要。NIST 要求验证方检查 UV；如果 UV 不为 true，应把认证器当作单因素，不能直接算 AAL2 的多因素。高保证场景应要求 UV=true，或做 step-up。
Conditional UI 是什么？
WebAuthn L3 的 conditional mediation 让 passkey 出现在用户名/登录输入框的自动填充里，create/get 都支持。它能提升发现率，但要做浏览器特性检测和传统按钮降级。
用户丢了手机怎么办？
至少要有第二个 passkey/安全密钥、恢复码/恢复联系人、挂失流程和恢复通知。NIST 对 AAL2 恢复要求“两种不同方法的 recovery code”或“1 code + 单因素认证器”等；不要用短信/邮件重置绕过 passkey 的抗钓鱼性。
企业/高价值账户怎么选？
按风险定 AAL：一般员工 AAL2 可用 passkey；管理员/高价值/政府 AAL3 用 non-exportable 硬件密钥，并限制 BE/同步。具体强制范围要经风险/合规评审。
要不要做 attestation？
消费级 passkey 通常不需要强 attestation；企业/AAL3 可用 attestation 验证认证器能力/来源。attestation 会带来隐私/兼容性成本，按场景决定。
研究方法与局限
本文把“官方规则事实”和“编辑建议”分开：WebAuthn Level 3 的 Recommendation 日期、BE/BS、conditional UI、hybrid、JSON、related origins、signal methods，来自 W3C WebAuthn Level 3（2026-08-25，§18.1.1）；AAL1/2/3 定义、AAL2 抗钓鱼选项、AAL3 non-exportable、syncable authenticator 仅 AAL2、UV/UP/BE 验证、Appendix B 的同步密钥/访问控制要求，来自 NIST SP 800-63B-4（2025-07）；账户恢复要求来自第 4.2.2/4.2.3/4.3 节。落地路径、失败模式和 90 天清单为编辑整理；FIDO Alliance Passkey 资料用于术语/UX 背景。
局限有八个：① 不构成合规/法律/采购建议；② 未逐一核对浏览器/平台对 WebAuthn L3 的支持；③ 未覆盖所有认证器/密码管理器的同步实现；④ 未展开 attestation、PRF、largeBlob 等扩展；⑤ 未评估具体产品的 AAL 认证/审计；⑥ 未覆盖企业 IdP/SSO 的集成细节；⑦ 未做真实用户转化/支持工单测试；⑧ 标准/实现会更新，落地前应复核 W3C/NIST/平台文档。
数据来源与口径
- W3C, Web Authentication: An API for accessing Public Key Credentials — Level 3（Recommendation, 2026-08-25）：w3.org/TR/webauthn-3。BE/BS、conditional UI、hybrid、JSON、related origins、signal methods、§18.1.1 变更。访问 2026-11-08。
- NIST, SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management（2025-07）：csrc.nist.gov/pubs/sp/800/63/b/4/final。AAL1/2/3、Appendix B syncable authenticators、UV/UP/BE、恢复要求。访问 2026-11-08。
- NIST, SP 800-63B-4 PDF：nvlpubs.nist.gov/.../NIST.SP.800-63b-4.pdf。Appendix B 与第 4.2 节原文。访问 2026-11-08。
- FIDO Alliance, Passkey Central：fidoalliance.org/passkeys。passkey 术语、实施/UX 资料。访问 2026-11-08。
资料截止 2026-11-08；标准/实现以 W3C、NIST、FIDO 与平台文档为准；本文不构成合规、法律或采购建议。