Passkey 部署还需要覆盖新设备、凭证丢失、恢复核验与旧会话处置。提供产品和运维可共同验收的清单。
网站支持 Passkey 之后，登录页面可能更简单了，但账号生命周期并没有变简单。用户换设备、凭证不可用或被盗用时，恢复入口仍然决定整个账号体系的安全边界。下面是一份适合产品、客服和安全团队共同讨论的验收清单。
先明确你支持哪一类凭证
FIDO Alliance 将 Passkey 描述为基于公私钥、具备抗钓鱼特性的登录凭证，并区分可同步与设备绑定等使用方式。不同平台和管理策略会影响换机体验，因此不要承诺所有用户都能通过同一个动作恢复。
上线前应记录支持的平台、浏览器和使用方式，并在说明中解释凭证由何处管理。账号页面应让用户识别已添加的凭证、添加时间及相关使用记录；界面展示的信息不得暴露私钥或其他认证秘密。
至少覆盖四个真实场景
- 仍有一台可信设备：用户能否在重新认证后添加新凭证，并收到变更通知。
- 全部凭证不可用：是否有预先设计的恢复路径，能否清楚说明核验步骤和等待条件。
- 设备丢失：能否移除相关凭证，同时评估是否撤销旧会话。
- 恢复渠道也失控：是否有升级处理流程，避免客服仅凭可公开查询的信息恢复高价值账号。
管理员账号、财务操作账号与普通阅读账号的恢复要求可以不同，但差异需要明确记录。不要为了减少客服工单，让一个薄弱的备用入口绕过所有正常认证要求。
把凭证变更当作敏感操作
新增和移除 Passkey、修改恢复渠道、查看或重新生成恢复码，都应按风险要求进行再次核验。恢复码若使用，应支持安全保存、单次使用与撤销，并避免出现在日志和普通客服记录里。发出的通知应提供清晰的异常反馈路径。
成功恢复后还要决定哪些旧会话继续有效。仅删除一个凭证，通常不能作为所有会话均已结束的证据；需要结合服务端会话策略验证。可使用独立测试账号在两台设备上演练，记录恢复前后各入口的状态。
验收以结果为准
分别测试正常登录、跨设备使用、取消操作、丢失凭证和客服升级处理。记录用户是否被锁在循环流程中，以及异常恢复是否产生审计记录。Passkey 的抗钓鱼优势不能替代设备安全、会话保护和恢复流程本身的设计。
参考：FIDO Alliance：Passkeys。资料核对：2026-10-04。
