VPN 验证器丢失：停用 MFA 之前先替换

有人丢了手机，工单却以“VPN 坏了”提交。这个定性错了两处：账户仍然存在，网关仍然信任身份提供方，所以真正坏掉的只是这个人不再持有的某一个因素。应当把它当作恢复而不是故障：核验申请人，登记替代方式，注销丢失的方法，然后证明账户可用。这一切都假设计划在丢失之前就已写好，因为临场发挥正是 MFA 最终被对所有人关掉的原因。

第 1 步：从记录里读取已登记的因素，而不是凭记忆

第一个问题不是丢了哪台设备，而是账户还能用什么。一个账户可能同时有密码加推送、基于时间的验证码、硬件密钥和打印的恢复码，丢掉其中一个与丢掉唯一一个是完全不同的事件。请从身份系统读取方法清单，而不是让用户自己回忆，在 Microsoft Entra 租户中这条查询只有一行：

Get-MgUserAuthenticationMethod -UserId [email protected]

然后在账户仍可用时写好恢复记录：账户标识、已登记因素、恢复码存放位置、谁能独立核验申请人，以及账户能访问哪些系统。把它放进团队已在使用的受保护清单，绝不要放进同时存有有效验证码的笔记。这五个字段把惊慌的来电变成检查表，而 NIST 的认证器生命周期指南 把恢复视为凭据的一部分，而不是例外。

把核验渠道单独记为一个字段，因为人们跳过的正是这一部分。当提出请求的人同时控制手机时，绑定在账户上的电话号码就不是独立渠道。

第 2 步：在故障路径之外核验申请人

通过不依赖 VPN、邮箱或丢失设备的渠道做身份核验。回拨人事记录中的号码，或者与已在目录中的主管当面核验，两者都可行；用正在恢复的账户发来的聊天消息则不可行。核验针对的是这个人，而不是他回答账户问题的能力，因为账户细节会泄露。记录谁在何时核验了请求，因为下一位审核人两者都需要。

当请求带着紧迫感和跳过核验的压力到来时，正是应该放慢的时刻。恢复欺诈看起来就像一个着急的热心同事。

第 3 步：登记替代方式，然后注销旧因素

通过正常登记流程注册新的验证器，绝不要走管理员绕过。然后显式移除丢失的方法，因为登记替代方式会让此前的验证器一直处于授权状态，直到有人注销它。如果旧设备可能落在他人手里，就把移除当作紧急事项，走事件流程而不是恢复流程。在同一次操作中撤销现有会话，因为变更之前建立的会话可能比变更活得更久：

Revoke-MgUserSignInSession -UserId [email protected]

替所有人移除该因素，或者放宽网关的证书检查，都是拿一个人的恢复去换影响整个部署的故障。把变更限制在单个账户内，如果证据指向更大范围的失陷就上报。在工单中注明注销了哪个因素、由哪个替代。

第 4 步：证明账户在两个方向上都可用

用受支持的客户端以新因素登录一次，然后确认账户仍能访问丢失前可访问的资源。测试一个需要隧道的资源和一个不需要的资源，让故障指向正确的层。用已注销的因素尝试登录，应得到拒绝而不是提示，这证明移除已生效。从现有已登记设备失败的挑战 是提示问题，不是重新登记一切的理由。

然后请用户在无人指导的情况下完成同样的登录。你的测试成功证明配置正确，他的尝试证明交接完成。

用成功登录的时间戳和当前使用的因素名称关闭工单。在同一次操作中更新恢复记录，让下一次丢失从准确的清单而不是过期的清单开始。

第 5 步：消除让这件事变得痛苦的条件

每一次恢复来电都是关于登记设计的证据。如果账户只有一个因素，就要求该组所有人都有第二个。如果恢复码放在丢失的笔记本上，就改变存放位置。如果核验需要一位休假中的主管，就指定代理人。每项修正只花一个下午，却能消掉下一次事件中最糟糕的那一小时。

然后拿第一步的记录对照现实重读一遍。它列出的是真实存在的因素吗，核验渠道还能触达真人吗？无人更新的运行手册，会退化成人们在当初写它的那通电话里直接忽略的文档。