多因素认证升级清单：先补恢复路径，再为关键账户启用通行密钥

升级认证方式之前，值得先问一个更朴素的问题：如果明天丢了那部随身设备，你还进得去自己的账户吗？很多人在启用了更强的登录方式之后，反而把自己锁在了门外——因为新方式绑定在唯一一台硬件上，而恢复路径从来没被检查过。

所以这份清单的顺序是刻意安排的：先把恢复路径补齐，再为最关键的账户启用通行密钥。顺序反了，风险不降反升。

为什么通行密钥值得纳入清单

按照 Google 的通行密钥开发者文档，passkeys 是一类基于 FIDO 的凭据，登录时会与站点来源（origin）绑定，因此天然具备抗钓鱼特性：即使被诱导到伪装页面，凭据也不会被”喂”给错误的域名。需要区分的是，通行密钥并非只有一种形态——有的会随账户在多台设备间同步，有的只绑定单一设备。两者在日常可用性上不同，在设备丢失后的影响也不同：同步型更不容易把自己锁在门外，单设备型则把风险集中在那一台硬件上。理解这一差异，是安排恢复路径的前提。

用 AAL 判断哪些账户先升级

不必对所有账户一刀切。NIST SP 800‑63B 用认证保证级别（AAL）来描述认证强度的层级，其核心思路是：认证方式的强度应当与账户的重要性相匹配，而不是无差别地要求最高强度。落到实践上，可以先按重要程度给账户排序——邮箱、身份中枢、涉及资金或关键数据的账户排在前面——优先为这些账户选择更强的层级，其余账户逐步跟进。这样既避免了在低价值账户上过度投入，也确保关键入口先得到加固。

操作清单

下面的顺序刻意把”恢复”放在”启用”之前。如果只启用了通行密钥却没有安排设备丢失后的备用登录方式，反而可能把自己锁在门外——因此以下步骤请按序执行。

盘点账户并按重要性排序，标出邮箱、身份中枢等一旦失守会波及其他账户的”关键入口”。
先为这些关键账户补齐恢复路径：记录并妥善保存恢复码、确认备用登录方式可用，确保它们与主设备相互独立。
确认恢复方式真的能用——在启用新方式前，先验证备用入口不依赖你即将改动的那台设备。
为排在前面的关键账户启用通行密钥，并留意所用的是同步型还是单设备型。
若使用单设备型 passkey，考虑在第二台设备上注册一枚，避免把登录能力集中在唯一硬件上。
完成后做一次演练：模拟”主设备不在手边”，走通恢复或备用登录，再把清单向次要账户推进。

先分清账户的层级

不必对所有账户一视同仁。按「失守之后会波及什么」排序，优先级自然就清楚了。

层级	典型账户	为什么排在这里
关键入口	主邮箱、身份提供方、密码管理器	它们是其他账户的找回途径
高价值	涉及资金、工作数据、云存储	直接损失大
一般	社交、购物、订阅服务	可逐步跟进
低价值	一次性注册、临时试用	更值得做的是减少注册本身

先把第一层做扎实，收益远大于把清单铺得很长。最后一层与其加固，不如参考把账户信息与验证记录最小化，从源头减少账户数量。

同步型与单设备型的差别

通行密钥并非只有一种形态：有的会随账户在多台设备之间同步，有的只绑定单一设备。日常使用时两者感受接近，但在设备丢失之后差别很大——同步型通常还能从另一台设备登录，单设备型则把风险集中在那一台硬件上。

因此如果你用的是单设备型，务必在第二台设备上也注册一枚，或者确保另有可用的恢复方式。这不是可选项，而是这种形态的必要配套。

推进节奏：一次一个账户

选一个关键账户开始，先补恢复路径并验证可用。
再为它启用新的登录方式，并留意是同步型还是单设备型。
用另一台设备实际登录一次，确认不依赖你刚改动的那台。
确认无误后，再进行下一个账户，不要一晚上全改完。
每完成一个就记一行：账户、方式、恢复途径、日期。

升级前的自查清单

这个账户的恢复路径，我验证过它现在可用吗？
恢复方式是否独立于我即将改动的那台设备？
我用的是同步型还是单设备型？
第二台设备上是否也有可用的登录方式？
我一次只改了一个账户吗？

常见问题

可以在多台设备上都注册吗？

多数服务允许，而且这正是降低「设备丢失即失去访问」风险最直接的做法。注册完记得逐台验证一次能否独立登录。

启用之后还需要保留密码吗？

多数服务仍保留密码作为备用登录方式。在你确认新方式在所有常用设备上都可用之前，不要急着删掉旧的途径。

工作账户和个人账户要分开处理吗？

要。工作账户通常受单位策略约束，可用的方式与恢复流程由管理方决定；个人账户则完全由你安排。两者混在一起容易出现「以为设过了」的错觉。

换手机会丢失吗？

同步型通常随账户迁移，单设备型则不会。换机前先确认属于哪一种，并按需在新设备上重新注册。

所有网站都支持吗？

并非如此，支持情况仍在变化。因此现实的做法是：支持的账户逐步启用，不支持的先用强密码加多因素认证。

它能防住所有攻击吗？

不能。它主要解决凭据被诱导交出与转发的问题，与设备本身被控制、账户恢复流程被滥用等风险是不同的层面。