微软和 OEM 在 10 月截止日期前解答 Windows 11 安全启动相关问题
微软与各 OEM 在一场新的办公时间 AMA 中修复了面向 IT 管理员的关键 Secure Boot 证书问题 微软于 7 月 15 日结束了其 OEM Secure Boot Office Hours 活动，来自微软的工程师与 Acer、Asus、Cisco、Clevo、Dell、Fsas/Fujitsu、Honor、HP、Lenovo、LG、Surface 和 Xiaomi 的代表一起，在 Tech Community 论坛上回答了 IT 管理员的实时提问。
评论开放了 12 小时，到活动结束时，这个帖子已经发展成 Secure Boot 2023 部署最详尽的技术记录之一，距离首批证书过期已过去三周多。
微软和 OEM 工程师回答了一长串具体到硬件层面的技术问题，并提出了修复建议，但帖子也显示出管理员对 BitLocker 恢复循环、卡住的信心评级，以及没有有用错误代码的 Intune 策略失败，已经开始失去耐心。
自 3 月以来，Windows Latest 一直在持续报道 Secure Boot 证书的部署，这次办公时间活动为负责迁移的 IT 管理员提供了迄今最好的技术答复。
注：本文面向在受管设备上部署 Secure Boot 证书更新的 IT 管理员和企业设备管理者。如果你只是普通 Windows 11 用户，不必惊慌。打开 Windows 安全中心 > 设备安全性 > Secure Boot，查看状态。如果显示 Secure Boot 已开启且所有证书更新都已应用，你的电脑就没问题，Windows 更新会继续保持这种状态。
在 Windows 安全中心中验证 Secure Boot 状态要点摘要
微软和各 OEM 在 Secure Boot 办公时间 AMA 中修复了多个问题
本次活动中最有用的信息主要来自微软的 Prabhakar_MSFT 和 Jason_Sandys，他们处理了大部分企业问题，HP 和 Dell 的 OEM 工程师则补充了设备层面的细节。
留在旧固件上的设备仍会获取 2023 证书
有管理员询问，放在架子上闲置数月的设备，或者之前做过镜像但此后一直没更新 Windows Update 的新机器会怎样。微软确认，无论设备离线多久，Secure Boot 更新流程都完全相同。任何 Secure Boot 数据库里仍保存 2011 证书的机器，在首次重新连接并处理更新时，都会获取 2023 证书链。不存在闲置设备被落下的截止点。
但如果设备固件里已经带有 2023 证书，却仍然使用 2011 链启动呢？微软的 Prabhakar 解释说，一旦这些设备安装了最新 Windows 补丁，启动管理器会自动切换到 2023 签名版本，不需要额外触发。
如果设备在完全打完补丁后仍卡在显示 2011 启动管理器，这说明更新尚未完成，而不是某种隐藏的中间状态。为此，微软向管理员介绍了一个实用脚本。
Windows 自带的 SecureBoot 脚本文件夹
2026 年 5 月 12 日之后发布的 Windows 更新，会悄悄把一组 PowerShell 脚本放入 %systemroot%\SecureBoot\ExampleRolloutScripts。微软过去会把这些脚本作为可复制粘贴的代码块发布在单独的支持页面上，但现在它们已经直接随操作系统捆绑提供。
对于单台设备，相关脚本是 Detect-SecureBootCertUpdateStatus.ps1，它会读取本地注册表和事件日志，并输出完整状态报告，不会做任何更改。Prabhakar 向一位询问 Secure Boot Status = Unknown 的用户推荐了这个脚本，因为即使证书正确且 TPM 已启用，它也能显示可能被 Autopatch 报告或 Intune 修复遗漏的数据。
用于整个平台监控的配套脚本是 Get-SecureBootRolloutStatus.ps1。一位名叫 Cliff_Hughes 的管理员在测试机上运行这个脚本时遇到了报错，因为它假定企业层面的部署已经在进行中。
Prabhakar 确认，这是单台设备上的预期行为，Detect-SecureBootCertUpdateStatus.ps1 才是逐台检查电脑的正确工具；而部署状态脚本及其汇总报告，则适用于通过微软的 Sample Secure Boot E2E Automation Guide 协调的大规模部署，该指南会讲解如何设置检测 GPO、用于收集数据的网络共享，以及以逐步加倍波次推送证书的编排器。
固件更新重置 ConfidenceLevel 时意味着什么
一位名为 RAJUMATHEMATICSMSC 的管理员把一块 Gigabyte B760M 主板的 BIOS 从 4 月 28 日的版本升级到 6 月 11 日的版本后，发现设备在注册表中的信心评级从 High Confidence 变成了 No Data Observed – Action Required，尽管 Secure Boot 证书本身并没有变化。
Prabhakar 解释说，信心评级关联的是设备报告的固件版本，而不是硬件本身。
微软会根据固件指纹把设备分成不同桶，每个桶会通过累积来自同一固件的 Windows 客户端设备的成功更新遥测，分别获得信心评级。当 BIOS 变化时，设备会被分配到一个新的桶，而微软还没有收集到足够数据，所以它会暂时显示为未评级，而不是沿用之前的评级。这是 High Confidence Database 工作方式带来的副作用。
如果设备的证书已经是最新的，Prabhakar 说可以安全忽略这个信心标签。对于想要注册表之外第二意见的人，他又一次提到了 Detect-SecureBootCertUpdateStatus.ps1！
AvailableUpdates 注册表项详解
两个名称相近的注册表值曾造成明显混淆：
- AvailableUpdates 是管理员应通过手动或脚本设置的键，位置在 HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot。将其设为 0x5944 会告诉 Windows 一次性部署 2023 链中的所有部分：DB 证书、KEK 和新的启动管理器。微软在其注册表项更新支持文章中记录了这一行为。
- AvailableUpdatesPolicy 在微软文档中被明确标注为 “仅供参考，请勿通过注册表更新此项”。它的存在是为了让组策略和 Intune 能把各自的 Secure Boot 设置传回 Windows，并且在管理员通过这些工具之一配置策略后会自动设置。
当一位名为 Swartz99 的管理员请 Prabhakar 确认在基于 GPO 的部署中他应直接编辑哪个键时，微软的 Jason_Sandys 介入并把他指向两个专门的部署指南：组策略对象方法和 Microsoft Intune 方法，这两种方法都会自动设置 AvailableUpdatesPolicy。
Swartz99 的组织曾尝试通过 Intune 或 GPO 应用 AvailableUpdatesPolicy 设置，但在他的环境中失败了，因为这些设备最初是 Pro 许可，然后通过 Cloud Microsoft Admin Licensing 升级到 Enterprise，而不是从一开始就是 Enterprise。微软的 Jason_Sandys 确认这是一个已知且已解决的问题，微软方面已在今年早些时候大约 2 月或 3 月修复，无需客户做任何更改。
BitLocker 恢复并不绑定任何单一部署方式
JoshMcWilliams6070 管理着大约 3700 台混合的 Dell 和 Lenovo 设备，他问没有 Intune 的组织是如何在不触发 BitLocker 恢复的情况下推进证书部署的，因为他大约 500 台设备的 Intune 配置失败了。Jason_Sandys 表示，触发 BitLocker 恢复并不是证书更新的预期行为，无论是通过 Intune、GPO、注册表项还是第三方 RMM 脚本推送都是如此。真正发生时，原因都超出微软的可见范围，通常是该硬件特有的自定义 PCR 配置或固件问题。
这也是为什么微软在每一场这样的活动中都反复强调：在大规模部署前先用你设备群中的代表性硬件进行测试，并确保 BitLocker 恢复密钥已提前备份且可随时取回。JoshMcWilliams 后来确认，他的组织已经把密钥存储在 Entra、Intune 和他们的 RMM 中，这意味着在目前处理的约 2800 台设备中，约 30 台触发 BitLocker 恢复，只是给他们三人团队增加了耗时工作，而不是真正的危机。
在具体的 Intune 失败问题上，Jason_Sandys 要求提供更多细节，因为 JoshMcWilliams 看到的 Settings Catalog 策略只有一个通用的 State Error, Error Type 2, Error Code 0，这本身不足以诊断。等待维修或作为备用而闲置的设备也不需要特殊处理；Jason_Sandys 确认，它们会走相同的 Windows Update 流程，或者在重新投入使用后遵循已配置的策略。
Dell 和 HP 谈老旧固件与由 Intune 管理的部署
SimoneTac 管理着一批 Dell 设备，其中大多数已经通过 Intune 完成证书更新，他问即使证书已经最新，仍运行旧固件的机器还剩下什么风险。Dell 的 Marcus_Molner 确认，单独更新证书是受支持的，但继续使用旧固件意味着会错过其他固件级安全修复和恢复能力，而这些内容是与证书工作分开发布的。
根据 Dell 的 Secure Boot Transition FAQ，Dell 推荐的补丁方案会把两者一起包含在内，让证书与 Windows Update 本来就会应用的内容保持一致。对于部署管理，Dell 提到可以通过 Intune 部署 Dell Command Update，它支持让终端用户自行延后重启，而不是强制重启。
另一个问题询问，Dell 和 HP 的完整企业产品线何时会出厂就把 2023 证书写入默认数据库，具体包括 HP G8 及更新机型、EliteBook G11，以及 Dell Latitude 7000 和 Pro 系列。
- HP 的 Juergen_Bayer 确认，所有 G8 及更新机型在更新到最新 BIOS 后，默认数据库中都会包含 2023 证书，可通过 SoftPaq 下载，或通过 HP 的 Client Management Script Library 获取。
- Dell 的 Marcus_Molner 指向了微软 2011 Secure Boot Certificate Expiration 知识库文章，其中持续维护着受支持平台及其对应 BIOS 版本的列表。
老旧 HP 硬件仍有手动路径
Kenny77 询问旧款 EliteBook 840 G5 和 G6 是否还能获得带有 2023 证书的固件更新。HP 按机型代际给出了不同答案。G6 有正式的 BIOS 更新，版本为 01.35.02，可让 Windows 通过正常更新流程附加 2023 证书。
G5 及更早机型已到达服务生命周期终点，不会再获得新的 BIOS。取而代之的是，HP Support 可按需提供手动更新包，直接将 2023 证书写入 KEK 和 DB 数据库；但 HP 也特别说明，该包不会触及默认数据库，因此恢复出厂设置后，设备会再次回到 2011 链。
兼容电脑以后不会失去更新到 2023 Secure Boot 证书的能力
Swartz99 询问，是否存在某个日期，过了之后仍在使用 2011 证书的设备就会永久无法接收 2023 链。HP 和微软 Surface 团队都对此作出了回答：
- HP 确认，2019 年及之后的任何商用平台，只要安装了最新 BIOS，始终都能够应用 2023 证书，因为活动中的 Secure Boot 数据库可以随时从更新后的默认值重新初始化。
- 微软的 Dan_Pandre 对 Surface 给出了同样的答案。当前有资格获取更新的任何 Surface 机型都会无限期保持资格，而 Windows Update 仍是最简单的路径；对于直接管理 IT 更新设备的人，微软 Surface Secure Boot Certificates 页面也提供了更手动的流程说明。唯一永久排除在外的 Surface 设备，是那些出厂时搭载 Windows 8 的机型，也就是 Surface Pro 3、Surface 3 及更早产品。自 2024 年以来发布的所有 Surface 都已内置 2023 证书，根本不需要任何更新。
IT 管理员在 10 月 Secure Boot 截止日期前应做什么
这场办公时间活动回答了微软早先 AMA 活动后积压的大量较小、偏设备特定的问题，但背后的截止日期压力并没有消失。
Microsoft Corporation KEK CA 2011 和 Microsoft UEFI CA 2011 证书已经过期，而链中的第三个证书 Microsoft Windows Production PCA 2011 将于 2026 年 10 月 19 日 过期，这意味着设备管理者大约还有三个月时间，来确认其环境中的每台设备要么已经使用 2023 链，要么已经有明确计划迁移过去。
好消息是，管理员现在有了一个真正可用于检查单台机器状态的脚本，知道了该改哪个注册表键，也得到了来自 HP、Dell 和微软 Surface 团队的直接确认：即使是仍在等待 BIOS 发布的设备，符合条件的硬件以后也不会失去更新能力。
如果你管理的设备群还没开始这个流程，微软关于错过 Secure Boot 截止日期会发生什么的指导，是一个很好的起点，而 Windows Latest 也已经提供了如何验证 Secure Boot 状态的详细信息。
关于不同 OEM 的各机型 BIOS 版本，网上最详细的 OEM Secure Boot 指南会告诉你 Lenovo、Asus、Acer 等厂商发布了什么。如果你设备群中的某台机器仍有这次活动未解决的错误，包括完全更新 BIOS 后仍出现的 BitLocker 循环和卡住的 KEK 更新，我们还有一篇关于本次办公时间帖子中未解决问题的单独分析。