企业通行密钥部署挑战与解决方案

1. 简介：企业通行密钥的运营现状#

通行密钥已经进入工作场所。问题不再是“技术有效吗？”。现在的问题是“我们如何大规模运营它？”。摩擦点已经转移到运营层：初始注册（引导）的“鸡和蛋”问题，设备绑定通行密钥和同步通行密钥的区别，跨平台互操作性，以及不退回到密码等不安全机制的恢复方法。

本指南解决了在 Microsoft Entra ID 环境中部署通行密钥的实际挑战，涵盖了配置陷阱、操作工作流程和恢复策略。具体来说，我们将解决以下问题：

1. 在 Entra ID 中，设备绑定通行密钥和同步通行密钥有什么区别？
2. 如何在没有密码的情况下为新员工引导通行密钥？
3. 当用户换了新手机并失去对其身份验证器的访问权限时，他们如何恢复？
4. 哪些配置错误会导致通行密钥注册失败？
5. 当需要防网络钓鱼的 MFA 时，我该如何处理 B2B 来宾？
6. 我应该使用硬件安全密钥（YubiKeys）还是移动通行密钥？
7. 在通行密钥部署中，如何处理 macOS 设备以及 Windows 设备？
8. 哪些主动措施可以防止因更换手机而导致服务台超载？

2. 了解 Microsoft Entra 中的通行密钥#

在 Entra 中，“通行密钥” = FIDO2/WebAuthn 凭据。用户不是使用密码，而是证明拥有存储在身份验证器中的私钥。它是防网络钓鱼的，因为 WebAuthn 将凭据与真实的登录源绑定（因此外观相似的钓鱼网站无法重放它）。请参阅微软在通行密钥 (FIDO2) 概念文档中的概述。

Entra 实际上支持两种行为不同的通行密钥“模式”。

2.1 Entra 中设备绑定的通行密钥#

这些通行密钥绑定到一个物理设备（不可同步）。私钥存在于特定的硬件元件中（笔记本电脑上的 TPM，YubiKey 上的安全元件）。它是不可导出的。

在 Entra 中，设备绑定模式通常转化为：

• Microsoft Authenticator 通行密钥
• Windows Hello 或 Windows Hello for Business (WHfB) 通行密钥（截至 2026 年 1 月为非同步）
• FIDO2 安全密钥（像 YubiKeys 这样的硬件密钥）
• 智能卡 (Smartcards)

微软关于设备绑定通行密钥的基线设置指南可在此处找到： https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

使用场景： 高特权访问，“应急 (break-glass)”账户，共享工作站环境。缺点： 摩擦高。丢失设备意味着丢失凭据。高运营成本（例如邮寄 YubiKeys）。

2.2 Entra 中的同步通行密钥#

这些通行密钥存储在提供商生态系统中，并在用户的设备间同步（例如 iCloud Keychain、Google Password Manager 或第三方提供商）。私钥已加密并存储在云提供商的同步结构中。

截至 2026 年 1 月，在 Entra 中，同步通行密钥通过预览功能处理： 同步通行密钥（预览版）。要启用和控制同步通行密钥，Entra 使用 通行密钥配置文件（预览版）。

监管一致性： 最近被 NIST SP 800-63B 补充 1 验证为符合 AAL2 要求。这是巨大的监管胜利，验证了同步通行密钥具有足够的“防网络钓鱼”能力，适合普通员工使用。

使用场景： 知识工作者，BYOD 用户，高管便利。缺点： 比硬件的保证“低”。依赖云提供商帐户恢复流程的安全性。

在这里您可以找到 Entra 支持的同步通行密钥提供商概述：

在用户的安全信息页面中，同步通行密钥和设备绑定通行密钥得到了明确区分。在下面，您可以看到同步通行密钥（来自 1Password）和设备绑定通行密钥（YubiKey 5C NFC）是如何显示的：

2.3 监管一致性：NIST AAL 级别#

• AAL3 在历史上要求使用利用不可导出私钥的基于硬件、设备绑定的身份验证器（如 YubiKeys 或智能卡）。
• 根据 NIST 指南，AAL2 现在可以通过同步通行密钥来实现。
• 细微差别： 虽然同步通行密钥（如 iCloud 中的那些）非常适合标准用户，但它们可能无法严格满足最高权限级别的 AAL3“不可导出性”要求。因此，需要采取分段策略：管理员使用硬件密钥 (AAL3)，普通员工使用同步通行密钥 (AAL2)。

2.4 设备就绪要求#

为确保设备为防网络钓鱼的无密码身份验证做好准备，它们必须运行以下最低版本：

较旧的操作系统可能需要外部身份验证器（FIDO2 安全密钥）以支持防网络钓鱼的无密码身份验证。

除了最低版本要求外，浏览器端功能支持因平台而异。根据 Corbado 通行密钥基准 2026 WebAuthn 客户端能力分析，2026 年第一季度的浏览器对 Conditional Get 和 Hybrid Transport 的支持在 97–100% 之间，但对于典型消费者浏览器组合上的 Conditional Create 只有 83–92% —— 这一限制在 Windows 上尤为明显，因为 Windows Hello 不是 Conditional Create 路径，并且 Edge 在同一数据集中特别报告了非常低的 Conditional Create 支持。该基准测试涵盖了面向消费者的 B2C 部署，而不是工作场所环境，但相同的底层浏览器/操作系统能力天花板仍适用于 Entra ID 推出；重度使用 Edge 的企业人群的支持率可能会大幅低于 83–92% 的混合 Conditional Create 范围。

2.5 用户角色的凭据建议#

微软建议对凭据部署采用基于用户角色的方法。不同角色具有不同的安全要求和可接受的摩擦级别：

便携式凭据（可跨设备使用）：

本地凭据（设备特定）：

最终目标：大多数用户应该至少拥有一种便携式凭据，以及每个计算设备上的本地凭据。

3. 实时通行密钥部署经验#

在与已经部署通行密钥的组织交谈时，可以认识到一些现实的摩擦点和模式。

3.1 运营转变#

“挑战不在于技术栈，而在于运营层。” 这证实了诸如“通行密钥未注册”错误或在个人设备上无法看到 Windows Hello 选项等技术障碍并非独特的异常现象，而是生态系统当前成熟度固有的系统性摩擦点。对于企业运营来说，关键是在监控中分离预期和意外的故障。将 WebAuthn 错误明确分类，并将 NotAllowedError、AbortError 和 Credential Manager 通行密钥错误作为不同的信号进行跟踪。我们的身份验证分析剧本提供了一个框架来分类这些信号，而通行密钥分析涵盖了特定的通行密钥 KPI（如激活和登录率）。

3.2 注册：“成败”时刻#

注册是部署中最困难的阶段，需要进行重大的变更管理。

• 预注册的复杂性： 为没有先前凭据的新员工办理入职手续是主要的瓶颈。依赖于管理员介入的注册创建了一种脱节的用户体验。
• 平台碎片化： 由于浏览器、操作系统和密码管理器的独立迭代而引起的“用户对步骤的挫败感”。这导致了暂时的不一致，例如在 Chrome/Windows 上可行的流程在 Safari/macOS 上失败，或者在未托管的个人设备上失败但在公司设备上成功。

3.3 心智模型差距#

“用户不需要密码学，他们需要一个心智模型”。术语的混乱造成了认知负荷：

• 通行密钥 (Passkey)
• 安全密钥 (Security Key)
• 硬件密钥 (Hardware Key)
• YubiKey
• 无密码 (passwordless)
• Windows 安全 (Windows Security)
• Windows Hello
• Windows Hello for Business (WHfB)
• Microsoft Authenticator
• 手机登录 (Phone Sign-in)

对于非技术熟练用户或即便是技术熟练的用户来说，如果这些术语不明显，差异是很难理解的。

我们建议在与最终用户的通信中避免使用诸如“防网络钓鱼”或“密钥对”等行话。相反，应关注“解锁”概念：“用您的脸解锁企业系统”，就像解锁他们的手机一样。

3.4 沟通的局限性#

一开始就有较高的采用率对成功至关重要，但沟通的作用是有限的。你不能经常发送电子邮件要求用户检查他们的认证方法。一般来说，你无法很好地规划用户行为。 这一现实要求采取积极的技术措施，而不是仅仅依赖用户教育。

4. Microsoft Entra ID 配置深入解析#

在企业环境中部署通行密钥需要了解并设置相互依赖的策略。通行密钥绝不仅仅是一个可以简单打开的功能，因为它对每个员工的日常工作都有着巨大的影响。

4.1 身份验证方法策略#

旧版的 MFA 和 SSPR 门户已被弃用。所有 FIDO2 配置必须在统一的身份验证方法策略边栏中进行。

• FIDO2 安全密钥方法： 必须启用并定向。建议定向到“所有用户”进行启用，但通过条件访问来控制实施。
• 密钥限制 (AAGUID)： 每个 FIDO2 设备（例如 YubiKey 5 NFC、iOS 上的 Microsoft Authenticator、Google Password Manager）都有一个独特的 Authenticator Attestation GUID (AAGUID)。作为最佳实践，对于高安全性环境，利用“强制密钥限制”设置来仅允许特定且经批准的 AAGUID。这防止用户注册廉价、未经核实的“灰市”安全密钥。

4.2 证明：关键的决策点#

最重要的配置决策之一是**“强制执行证明 (Enforce Attestation)”**。

• 它的作用： 强制身份验证器在注册期间向 Entra ID 加密证明其品牌和型号。
• 冲突： 同步通行密钥（存储在软件提供商中，如 iCloud Keychain、Bitwarden 或 Google Password Manager）通常不支持证明，因为它们是基于软件且与平台无关的。它们无法使用硬件批次证书签署挑战。
• 权衡：
  • 设置为 YES： 高保证 (AAL3) 所需。确保密钥是硬件绑定的。阻止基于软件的通行密钥提供商。
  • 设置为 NO： 允许同步通行密钥。略微降低保证 (AAL2)。启用基于软件的通行密钥提供商。

如果您有需要硬件密钥的高权限管理员，则不能应用全局的“无证明”策略。您必须使用 通行密钥配置文件（预览版）：

• 配置文件 A (管理员)： 强制执行证明 = Yes
• 配置文件 B (普通员工)： 强制执行证明 = No

4.3 通行密钥配置文件说明#

将 通行密钥配置文件 视为定义以下内容的机制：

• “这些用户可以使用同步通行密钥”
• “这些用户必须使用仅设备绑定”
• “要求证明与不需要证明”（因此：允许同步通行密钥与排除）
• “限制特定身份验证器类型 (AAGUID 限制)”

在下方，您可以看到 Microsoft Entra 管理中心内的 通行密钥 (FIDO2) 设置页面，您可以在此配置通行密钥配置文件：

在编辑通行密钥配置文件时，您可以配置证明实施、目标类型（设备绑定、同步或两者兼有）和特定的 AAGUID 限制：

4.4 条件访问与身份验证强度#

强制执行可以通过条件访问 (CA) 策略处理，利用 身份验证强度。

• 防网络钓鱼的 MFA 强度： 这种内置强度需要 FIDO2、Windows Hello for Business (WHfB) 或基于证书的身份验证 (CBA)。
• 锁定陷阱： 如果您创建一个要求所有“云应用”使用“防网络钓鱼的 MFA”的 CA 策略，并将其应用于“所有用户”，您将立即锁定每一个尚未注册通行密钥的用户。他们甚至无法登录以注册一个。
• “注册安全信息”悖论： 这是 CA 中的特定用户操作。如果您要求防网络钓鱼的 MFA 来执行操作 注册安全信息，您会创建一个循环依赖（鸡和蛋）。用户无法注册他们的第一个通行密钥，因为他们需要通行密钥来访问注册页面。

以下是哪些身份验证方法满足哪些强度要求的概览：

4.5 系统首选身份验证#

Entra ID 的“系统首选多因素身份验证”功能强制登录引擎提示用户输入最安全的已注册方法。

如果用户同时注册了 SMS 和通行密钥，系统将默认使用通行密钥。这将有机地推动通行密钥的采用，而无需硬性强制。一旦用户注册了凭据，它本质上就会自动“升级”用户的安全态势。

下面您可以看到通行密钥的登录体验。提示用户使用“人脸、指纹、PIN 或安全密钥”，并可从浏览器扩展或系统凭证管理器中选择其通行密钥：

4.6 macOS 注意事项：平台 SSO#

对于具有 Windows/macOS 混合环境的组织，macOS Platform SSO 提供了相当于 Windows Hello for Business 的 Apple 方案。与 MDM 解决方案结合使用，您可以实现：

• 绑定到 Mac 的 Secure Enclave 的设备绑定凭据
• 本机应用程序和 Web 应用程序间的 SSO 体验
• 满足 AAL2/AAL3 要求的防网络钓鱼身份验证

注意： macOS Platform SSO 需要 macOS 13+ 和适当的 MDM 配置。设置与 Windows WHfB 有显著差异，因此请计划独立的部署轨道。

5. 常见配置错误：为什么“它只适用于 Microsoft Authenticator”#

如果您的目标是在非受管设备上使用同步通行密钥，这些是最常见的障碍：

5.1 未启用/定向同步通行密钥#

仅在 Entra 中通常启用“FIDO2”是不够的。对于同步通行密钥，您通常需要：

• 在 同步通行密钥（预览版） 中描述的预览功能路径
• 使用 通行密钥配置文件 进行配置的配置文件

如果一个组没有被允许使用同步通行密钥的配置文件定向，您就会被拉回到“仅设备绑定”的世界中。

5.2 强制证明 (阻止同步通行密钥)#

这是安全意识较高的组织中最常见的问题：

• Entra 可以针对某些通行密钥场景要求证明 (有助于验证身份验证器类型/出处)
• 同步通行密钥不支持 Entra 中的证明，因此如果强制执行证明，同步通行密钥的注册将会失败，您将仅剩下设备绑定的选项。

5.3 AAGUID 白名单阻止了提供商#

Entra 允许您限制受允许的身份验证器 (通常通过 AAGUID 白名单/黑名单)。如果您仅将 Microsoft Authenticator (或一小部分身份验证器) 列入白名单，则第三方同步提供商可能会被隐式阻止。令人困惑的部分是，本地身份验证 (例如 Touch ID、Face ID、Windows 生物识别扫描) 是有效的，但随后 Entra 登录页面会显示错误。

5.4 条件访问强制要求特定通行密钥类型#

即使启用了通行密钥，条件访问也能有效地强迫用户使用一部分方法 (例如，“仅 Authenticator”或不许可预期通行密钥配置文件的强度配置)。在实践中，即便计划是使用同步通行密钥，这也会造成“Authenticator 依赖”。

5.5 B2B 来宾与成员账户#

如果外部合作伙伴是资源租户中的 B2B 来宾用户，关于他们可以在何处/如何注册身份验证方法存在已知限制。当意图是“合作伙伴在我们的租户中使用通行密钥”时，这经常是“为什么它不起作用”的隐藏原因。

6. 运营挑战与解决方案#

6.1 引导悖论#

最普遍的问题（“注册是最困难的部分”）是引导问题：您如何安全地向目前没有凭据（或只有低保证凭据）的用户颁发高保证凭据？

6.1.1 临时访问通行证 (TAP)#

临时访问通行证 (TAP) 是用于无密码初始化的架构方法。

• 它是什么： 一种有时间限制（例如 1 小时）的高熵密码，Entra ID 将其视为“强身份验证”方法。它绕过了对密码或现有 MFA 的需求。
• 工作流程：
  1. 身份验证： 新员工的身份得到验证（例如，通过 HR 流程或经理验证）。
  2. 颁发： 管理员（或自动化的 Logic App）为用户生成一个 TAP。
  3. “魔法”登录： 用户导航至 aka.ms/mysecurityinfo。他们输入其用户名和 TAP。
  4. 注册： 因为 TAP 满足“强认证”要求，所以允许用户访问安全信息边栏。他们点击“添加方法”并注册其通行密钥。
  5. 稳定状态： TAP 过期。用户现在拥有一个防网络钓鱼的凭据。他们从未输入过密码。

6.1.2 通过 Graph API 实现自动化#

对于大型组织，手动颁发 TAP 是不可扩展的。最佳实践是通过 Microsoft Graph API 自动化。

• 场景： 一名新员工在人力资源系统（Workday/SuccessFactors）中被处理。
• 触发器： 预置事件触发 Azure Logic App。
• 动作： Logic App 调用 Graph API POST /users/{id}/authentication/temporaryAccessPassMethods。
• 发送： TAP 安全地传递给用户的招聘经理或个人电子邮件（加密），用于第一天的访问。

6.1.3 用于高保证入职的 Microsoft Entra 验证 ID#

对于远程入职或需要高身份保证的场景，微软结合面部检查 (Face Check) 的 Entra 验证 ID 提供了一个无密码优先的注册路径：

1. 身份证明： 新用户通过 IDV 合作伙伴验证身份（政府 ID 扫描）。
2. 生物识别匹配： 面部检查 使用 Azure AI Vision 将实时自拍与身份证件照片进行比对。仅共享匹配置信度得分（没有原始生物特征数据）。
3. 颁发验证凭据： 用户收到一个已验证的 ID 凭据。
4. 颁发 TAP： 成功验证后，系统会发出临时访问通行证。
5. 通行密钥引导： 用户使用 TAP 注册他们的第一个通行密钥。

面部检查流程引导用户完成三个步骤：验证（分享凭据）、确认（执行面部扫描）和查看（查看匹配结果）：

这一流程支持从第一天起就实现真正无密码的账户。永远不会创建密码。

6.2 手机更换问题（隐藏的规模挑战）#

这通常是通行密钥部署中服务台来电的最大来源。拥有大量 BYOD 人群（例如超过 10,000 台设备）的组织会看到仅因用户获取新手机且不知道如何重新注册身份验证方法而产生的大量支持来电。

当您在组合中引入通行密钥时，这变得更加关键，因为：

• 用户在新手机上安装应用程序（如 Outlook）
• 这些应用程序提示进行身份验证
• MFA 提示出现在旧手机上（他们可能已经折价换新或擦除了数据）
• 用户被锁定并呼叫服务台

6.2.1 手机更换场景矩阵#

目标是尽可能多地将案例转移到前两行中，最大限度地减少服务台的干预。

6.2.2 Intune 注册技巧#

一个聪明的见解：要求通行密钥进行 Intune 注册会迫使用户立即在新手机上完成 Microsoft Authenticator 的设置——在他们能够访问公司应用程序之前。

• 今天： Intune 注册要求进行 MFA 升级。这意味着如果您想在新手机上登录，您需要在那儿安装 Outlook。然而，MFA 提示会发送到旧手机。
• 有了通行密钥要求： 用户必须首先在新手机上设置 Microsoft Authenticator 通行密钥，以完成注册。这发生得很快（换手机当天），而不是在几个月后旧手机消失的时候。

这并不能解决恢复问题，但它改变了时间线。用户在仍可访问旧设备时注册他们的新设备。

6.3 硬件安全密钥伴随着物流问题#

硬件密钥（YubiKeys 等）有时被定位为通用解决方案。理论上确实如此，但现实世界展示了更多的挑战：

• 物流噩梦： 以前部署过物理令牌（如 RSA SecurID）的组织常常花费数年试图淘汰它们。用另一个物理令牌程序替换旧的一个并没有吸引力。
• 直接发货： Yubico 可以直接将密钥运送给用户，而且它们不需要每隔几年更换一次电池（与 SecurID 不同）。但如果有人忘记带钥匙，他们就无法登录（对于共享桌面而言）。
• 本地 IT 负担： 本地主管不应成为遗忘密钥的实际 IT 支持人员。
• 成本： 硬件密钥增加了每个用户的成本，该成本随员工人数成比例增加。

硬件密钥合理的场景：

• 第 0 层管理员： 域管理员，“应急”帐户
• 共享工作站： 展台环境，工厂车间，现场平板电脑
• 没有 BYOD 的承包商： 不使用个人设备的外部用户

6.4 非托管设备的挑战#

许多用户抱怨他们无法在个人设备上看到使用通行密钥的选项。这是一个经典的“非托管设备”摩擦点。

6.4.1 “通行密钥未注册”错误分析#

用户可能无法在个人设备上添加通行密钥，而在公司设备上有效。这可能是由于 Intune 合规策略 与注册流程交互造成的。

• 机制： Windows Hello for Business (WHfB) 是一种平台凭据。它被绑定到特定设备的 TPM（设备绑定的通行密钥）。
• 约束： 为了注册 WHfB，设备通常必须加入（Entra Joined 或 Hybrid Joined）该租户。如果设备没有被完全托管或符合规定，则仅仅“注册”（Workplace Joined）的个人设备可能由于 Intune 应用的策略限制而阻止配置 WHfB 容器。请参阅 FIDO2 安全密钥登录要求。
• “通行密钥”选项： 在个人设备上，用户应尝试注册一个 FIDO2 安全密钥（漫游）或一个跨设备通行密钥（在他们的手机上），而不是 Windows Hello for Business（除非完全支持 BYOD 注册）。
• Entra ID 可见性问题： 如果“Windows Hello”未作为选项出现，则设备尚未完成必需的 MDM 注册。

6.4.2 跨设备身份验证 (CDA) 失败#

在非托管设备上，用户经常尝试跨设备身份验证 (CDA) 流程（在 PC 上用手机扫描二维码）。

• 蓝牙依赖： CDA 要求 PC 和手机同时开启蓝牙。它们不需要配对，但必须执行蓝牙低功耗（Energy，BLE）握手以证明接近性。查看 Microsoft Authenticator 中绑定的设备通行密钥 以了解详细信息。
• 公司策略阻碍： 如果出于“安全性”原因通过 BIOS 或 GPO 禁用了公司笔记本电脑上的蓝牙，那么您就已经破坏了漫游通行密钥的主要机制。
• Websocket 拦截： CDA 流程使用连接到 cable.ua5v.com 或 cable.auth.com 的 websocket 连接。激进的公司防火墙或 Zscaler 配置经常阻止这些域，导致 QR 码扫描挂起或无提示失败。请参阅 Microsoft Authenticator 通行密钥文档。

6.5 B2B 和外部身份#

企业的另一个痛点是处理外部顾问（B2B 来宾）。

• 问题： 一位顾问尝试访问 SharePoint 站点。租户执行条件访问策略，要求进行“防网络钓鱼的 MFA”。
• 故障： 该顾问尝试在资源租户中注册 FIDO2 密钥。这失败了。 Entra ID 不支持来宾用户在资源租户中注册 FIDO2 密钥。
• 修复：跨租户访问设置
  • 逻辑： 您不应强迫访客在您的租户中注册凭据，而应该信任他们在他们自己租户中使用的凭据。
  • 配置： 转到 外部身份 > 跨租户访问设置。选择合作伙伴组织。在 入站信任 下，选中 “信任来自 Microsoft Entra 租户的多因素身份验证”。
  • 结果： 当顾问使用其主租户中的 YubiKey 登录时，您的租户会收到声明说“MFA 已满足 + 防网络钓鱼”。授予了访问权限，而用户无需注册任何东西。这会将凭证生命周期管理外包给合作伙伴，从而减少您的责任和帮助台负荷。

7. 恢复策略#

通常，恢复决策仍落后于实际推出。根据您组织的需求存在多种恢复选项。

7.1 使用验证 ID 的自助帐户恢复 (SSAR)#

Microsoft Entra ID 的新自助帐户恢复 (SSAR) 流程（预览版）允许在无需服务台干预的情况下进行高保证恢复。

1. 触发： 用户无法登录。选择“恢复我的帐户”。
2. 身份验证： 用户被重定向至第三方身份验证 (IDV) 提供商（如 Onfido、IDemia）。
3. 证件检查： 用户使用手机摄像头扫描其物理驾驶执照、国民身份证或护照。
4. 活体检测： 用户进行自拍面部检查。此操作将与身份证件（可能还有 Entra ID 中存储的照片）进行匹配。匹配使用 Azure AI Vision 的面部 API，仅共享置信度分数。没有原始生物特征数据传递给应用程序。
5. 恢复： 成功后，系统会自动向用户发放一个 临时访问通行证 (TAP)。
6. 重新注册： 用户使用该 TAP 立即注册新的通行密钥。

建议： 这种自动化的、以生物识别技术为后盾的恢复路径优于“致电服务台”，后者容易遭受社会工程攻击（深度伪造语音攻击）。

7.2 与“我的员工 (My Staff)”一起使用的经理协助恢复#

如果您想减少服务台负载但又无法启用完全的自助服务，Microsoft Entra 包含一个称为 我的员工 (My Staff) 的原生委派管理功能。

• 工作原理： 将有限的权限委派给“团队经理”（通过 Entra 中的管理单元）。
• 流程： 如果用户失去访问权限，他们可以联系委派的本地管理员，后者可以使用 我的员工 门户进行支持的恢复任务，如重置密码或更新电话号码。
• 为何有帮助： 它将常见的账户恢复工作从中央服务台转移出去，并加快了支持速度。

7.3 自助服务恢复终端 (内部网)#

因为用户通常仍有一台可信的、通过 WHfB 保护的笔记本电脑，您可以建立一个简单的“应急”内部网页面。

• 构建： 一个简单的内部 Web 应用程序，需要通过 WHfB 登录 (强身份验证)。
• 行动： 一旦通过身份验证，用户点击“我有一部新手机”。应用程序利用 Microsoft Graph API (后台服务) 生成短期的临时访问通行证 (TAP) 并将其显示在屏幕上。
• 结果： 用户将 TAP 输入新手机以引导 Microsoft Authenticator 应用程序。零帮助台干预。

这是在不削弱策略的前提下减少“清除认证方法”重置的关键手段。如果您有一个强大的笔记本电脑作为引导的机制，您的沟通负担将大大降低，因为用户不需要知道完美的顺序就可以恢复。

8. 针对企业通行密钥部署的建议#

围绕成熟度阶段构建您的推出。承认摩擦（“技术已经就绪，操作很困难”），并应用这些缓解措施。

8.1 立即行动（“修复”阶段）#

1. 审查蓝牙与防火墙： 确保公司笔记本电脑允许蓝牙（用于接近性检查），并将 FIDO/WebAuthn 中继域 (\*.cable.auth.com) 加入白名单，以修复跨设备故障。
2. 启用跨租户信任： 停止尝试注册来宾通行密钥。为关键合作伙伴配置针对 MFA 的入站信任，以立即解决 B2B 访问问题。
3. 入职实施 TAP： 强制要求使用临时访问通行证进行所有新用户入职，以解决“鸡和蛋”的注册阻碍。

8.2 战略决策（“架构”阶段）#

1. 采用“混合保证”模型：
   • 第 0 层 (管理员)： 强制执行证明和密钥限制。仅允许使用 YubiKeys/硬件 (AAL3)。
   • 第 1 层 (员工)： 通过通行密钥配置文件禁用证明强制执行。允许同步通行密钥以减少摩擦和成本 (AAL2)。
2. 为 macOS 做计划： 利用您的 MDM 部署 Platform SSO，作为与 Windows WHfB 并行的轨道。

8.3 面向未来（“优化”阶段）#

1. 规划 SSAR： 使用验证 ID 启动自助帐户恢复的试点，以消除帮助台作为社交工程攻击的载体。
2. 系统首选的认证： 启用此策略，以便在用户注册后自动将其“升级”到通行密钥，在无需强制作业的情况下推动采用。
3. 部署恢复选项： 通过 My Staff 实现经理辅助的 TAP，和/或实现自助服务恢复终端。
4. Intune 通行密钥要求： 考虑将通行密钥作为 Intune 注册的要求，以迫使在新设备上尽早注册。

8.4 故障排除矩阵#

9. 使用防网络钓鱼无密码工作簿监控部署#

微软发布了 防网络钓鱼无密码工作簿，在 Azure Monitor 中包含日志的组织可以用来跟踪推出的进度。通过 Entra 管理中心内的 监控 > 工作簿 可以访问它：

该工作簿有两个主要部分：

9.1 注册准备度阶段#

使用此选项卡分析登录日志，以确定哪些用户已准备好进行注册，而哪些用户可能会被阻止。您可以根据操作系统平台 (Windows, macOS, iOS, Android) 和凭证类型 (Authenticator 应用通行密钥, FIDO2 安全密钥, 基于证书的身份验证) 进行过滤：

该工作簿显示：

• 准备好注册的用户/设备对：可以注册选定凭据类型的用户
• 尚未准备就绪的用户/设备对：可能遇到注册问题 (例如过时的操作系统版本) 的用户

您可以导出需要采取补救措施 (例如升级操作系统、更换设备或替代凭据选项) 的用户列表。

9.2 强制执行准备度阶段#

一旦用户准备好使用仅防网络钓鱼的身份验证，请使用“强制执行准备度”选项卡。首先，创建一个需要防网络钓鱼 MFA 的仅报告条件访问策略。这将用关于如果在激活执行后访问是否会被阻止的数据来填充登录日志。

仪表板显示：

• 范围内的总用户数
• 报告成功 - 可以通过执行的用户
• 未满足策略 - 会被阻止的用户 (调查这些！)
• 设备状态、设备平台和客户端应用 细分

使用进一步数据分析选项卡来调查为什么某些用户会被阻止。在启用执行之前，该数据帮助您精确定位需要补救的用户。

9.3 带有服务台监控的波次推出#

微软建议通过提供灵活日期范围的分波次进行部署。监控服务台工单量作为一个信号：

• 工单量增加： 减缓部署、通信和强制操作
• 工单量减少： 加速恢复活动

为每一波创建 Microsoft Entra ID 安全组，并逐步将安全组添加到您的策略中。这可防止不堪重负的支持团队。

10. 同步通行密钥试点清单#

如果目标是实现不依赖 Microsoft Authenticator 的同步通行密钥，请遵循这一试点的要求：

1. 启用同步通行密钥 (预览版) 遵循 同步通行密钥（预览版）。

2. 使用通行密钥配置文件 (预览版) 并定向给试点小组 创建/分配一个允许同步通行密钥的配置文件，如同在 通行密钥配置文件 中所述。

3. 不要强制执行证明 (至少针对试点组) 根据 通行密钥 (FIDO2) 概念文档，强制执行证明会排斥同步通行密钥。

4. 最初避免严格的 AAGUID 白名单 从宽容开始，以确认流程有效，然后在您知道您想要允许的提供商后收紧限制。查看 启用通行密钥 (FIDO2)。

5. 确认条件访问没有强制使用 Microsoft Authenticator 确保 CA/认证强度仍然允许您预期的通行密钥配置文件 (否则，它看起来像一个 Microsoft Authenticator 的依赖)。

6. 验证身份模型 (成员与访客) 如果用户是访客，请在花费时间调整配置文件之前，在您的租户模型中确认对支持范围的预期。

11. 结论#

企业通行密钥部署在操作上很复杂，但前方的道路是明确的。这里有一些关键的答案，它们回应了上面提出的主要运营问题：

1. 设备绑定与同步通行密钥： 设备绑定凭据 (例如 Microsoft Authenticator、Windows Hello、YubiKeys、智能卡) 严格与单一设备绑定，并满足 AAL3。同步通行密钥 (例如 iCloud Keychain、Google Password Manager) 可以跨设备工作，并满足 AAL2。大多数组织需要两者兼顾：适用于管理员的硬件认证器 (AAL3) 和适用于更广泛员工的同步通行密钥 (AAL2)。

2. 引导新员工： 使用临时访问通行证 (TAP) 解决入职时的鸡和蛋问题。对于大规模部署，可以通过 Graph API 自动化此过程。对于高保证的用例，使用 Entra Verified ID 和面部检查补充入职。

3. 手机更换恢复： 提供多种恢复方法：自助恢复终端 (使用笔记本电脑作为引导设备)、通过 My Staff 实现经理辅助的 TAP，以及针对边缘案例，使用带有验证 ID 的 SSAR (自助帐户恢复)。

4. 配置错误： 最频繁的失误包括全局强制执行证明、未开启同步通行密钥的预览功能、过于严格的 AAGUID 白名单，以及创建循环依赖的条件访问 (CA) 策略。

5. B2B 来宾： 避免在您的租户中为 B2B 访客直接注册通行密钥。相反，开启跨租户访问信任以验证访客主租户的凭据。

6. 硬件密钥与移动端通行密钥： 针对某些高安全性角色（管理员、共享工作站），硬件安全密钥是必须的，但在扩展时会带来后勤障碍。针对普遍的劳动力，移动端通行密钥往往更实用。

7. macOS与Windows共存： 通过 JAMF/MDM 使用 Platform SSO，在 macOS 上开启通行密钥支持，从而与 Windows 的部署并行。为特定平台工作流程进行规划。

8. 主动措施： 借助 Intune 识别非活跃设备，在发生锁定前敦促用户采取补救措施。考虑将通行密钥注册设为 Intune 注册的先决条件，以推动早期采用。以笔记本为启动设备，构建自助恢复工作流。

技术已经就位。最大的挑战在于运营执行。从第一天起就应把规划恢复方案作为一个重要部分，而不是事后的补救想法。一旦基础设施变得坚固，工作重点就应转向优化通行密钥登录的采用，确保通行密钥能够成为您的员工首选的主要验证手段。

关于 Corbado

Corbado 是面向大规模运行 consumer 身份验证的 CIAM 团队的Passkey Intelligence Platform。我们让你看到 IDP 日志和通用 analytics 工具看不到的内容：哪些设备、操作系统版本、浏览器和 credential manager 支持 passkey，为什么注册没有转化为登录，WebAuthn 流程在哪里失败，以及什么时候操作系统或浏览器更新会悄悄破坏登录，而且无需替换 Okta、Auth0、Ping、Cognito 或你自有的 IDP。两款产品：Corbado Observe 提供 针对 passkey 及任何其他登录方式的 observability。Corbado Connect 提供 内置 analytics 的 managed passkey（与你的 IDP 并存）。VicRoads 通过 Corbado 为 500 万以上用户运行 passkey（passkey 激活率 +80%）。 与 Passkey 专家交谈 →

常见问题解答#

为什么在条件访问中启用防网络钓鱼的 MFA 会锁定所有我的用户？#

创建要求所有云应用进行防网络钓鱼 MFA 的条件访问策略，会立即阻止尚未注册通行密钥的所有用户，包括阻止访问安全信息注册页面本身。这种称为“注册安全信息”悖论的循环依赖关系，意味着您必须在启用强制执行之前向受影响的用户发放临时访问通行证 (TAP)，以便他们完成初始注册。

当我的租户需要防网络钓鱼的 MFA 时，应如何处理 B2B 来宾用户？#

Entra ID 不支持来宾用户在资源租户中注册 FIDO2 密钥，因此尝试强制来宾注册通行密钥将会失败。正确的修复方法是在“外部身份”下配置“跨租户访问设置”，以信任来宾主租户的 MFA 声明，这意味着在他们自己的组织中使用的 YubiKey 满足了您的防网络钓鱼 MFA 要求，而无需在您的租户中进行任何注册。

使用通行密钥登录时，是什么导致跨设备 QR 码身份验证无提示失败？#

跨设备身份验证需要 PC 和手机同时开启蓝牙，以完成 BLE 近场握手，因此任何禁用蓝牙的公司策略都会彻底破坏该流程。该流程还使用连接到 cable.auth.com 的 WebSocket 连接，防火墙或 Zscaler 配置经常会阻止此连接，导致 QR 码扫描挂起或失败，并且没有明确的错误消息。

在启用之前，如何监控哪些员工已准备好强制执行防网络钓鱼的 MFA？#

微软的“防网络钓鱼无密码工作簿”可通过 Entra 管理中心的“监控 > 工作簿”访问，提供“注册准备度”视图，按平台和凭据类型显示哪些用户/设备对可以注册。要了解强制执行准备度，可创建一个仅报告的条件访问策略，要求进行防网络钓鱼的 MFA，以便登录日志在您激活实时强制执行之前揭示哪些用户将被阻止。

如果员工换了新手机并失去了对通行密钥的访问权限，最好的恢复策略是什么？#

建议采用分层方法：使用受 WHfB 保护的笔记本电脑的“自助恢复终端”通过 Graph API 生成临时访问通行证，并在无需服务台干预的情况下处理大多数情况。对于没有笔记本电脑的用户，“我的员工”门户中由经理协助的 TAP 可将恢复工作委派给直接经理，而带有 Entra 验证 ID 生物识别面部检查的自助帐户恢复则处理需要全面身份重新验证的边缘情况。

延伸阅读#

对于深入了解企业级 FIDO2/通行密钥部署的信息，您可以关注像 Merill Fernando 和 Jan Bakker 这样的专家，他们定期发表有关 Microsoft Entra 身份验证的实用指南。