Group Policy Objects (GPO) method of Secure Boot for Windows devices with IT-managed updates

In this article:

• Introduction

• Group Policy Object (GPO) configuration method

Introduction

This document describes the support for deploying, managing, and monitoring the Secure Boot certificate updates using the Secure Boot Group Policy object. The settings consist of: 

• The ability to trigger deployment on a device

• A setting to opt in/opt out of high-confidence buckets

• A setting to opt in/opt out of Microsoft managing updates

Group Policy Object (GPO) configuration method

This method offers a straightforward Secure Boot Group Policy setting that domain administrators can set to deploy Secure Boot updates to all domain-joined Windows clients and servers. In addition, two Secure Boot assists can be managed with opt-in/opt-out settings. 

To get the updates that include the policy for deploying Secure Boot certificate updates, download the latest version of the Administrative Templates published on or after October 23, 2025. ​​​​​​​

This policy can be found under the following path in the Group Policy UI: 

           Computer Configuration->Administrative Templates->Windows Components->Secure Boot 

GPO configuration overview

• Policy name (tentative): “Enable Secure Boot Key Rollout” (under Computer Configuration).

• Policy path: A new node under Computer Configuration > Administrative Templates > Windows Components > Secure Boot. For clarity, a subcategory like “Secure Boot Updates” should be created to store this policy.

• Scope: Computer (machine-wide setting): It targets the HKEY_LOCAL_MACHINE hive and affects the device’s UEFI state.

• Policy action: When enabled, the policy will set the following registry subkey.

  Registry location	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecureBoot\Servicing
  DWORD name	AvailableUpdatesPolicy
  DWORD value	0x5944
  Comments	This flags the device to install all available Secure Boot key updates on next opportunity.

  Note: Due to the nature of Group Policy, the policy will be reapplied over time, and the bits of the AvailableUpdates are cleared as they are processed. Therefore, it is necessary to have a separate registry key named AvailableUpdatesPolicy so that the underlying logic can track if the keys have been deployed. When AvailableUpdatesPolicy is set to 0x5944, TPMTasks will set AvailableUpdates to 0x5944 and make note that this has been done to prevent reapplying to AvailableUpdates multiple times. Setting AvailableUpdatesPolicy to Diabled will cause TPMTasks to clear, or set to 0 AvailableUpdates and make note that this has been completed.

• Disabled/Not Configured: When set to Not Configured, the policy makes no changes (Secure Boot updates remain as opt-in and won’t run unless triggered by other means). If set to Disabled, the policy should set AvailableUpdates to 0, to explicitly ensure the device does not attempt the Secure Boot key roll or to stop the rollout if something goes wrong.

• HighConfidenceOptOut can be enabled or disabled. Enabling will set this key to 1 and disabling will set it to 0.

ADMX implementation: This policy will be implemented using a standard administrative template (ADMX). It uses the registry policy mechanism to write the value. For example, the ADMX definition would specify:

• Registry key: Software\Policies\... Note: Group Policy normally writes to the Policies branch, but in this case, we need to affect the HKEY_LOCAL_MACHINE\SYSTEM hive. We will use Group Policy’s ability to write directly to the HKEY_LOCAL_MACHINE hive for machine policies. The ADMX can use the element with the real target path.

• Name: AvailableUpdatesPolicy

• DWORD value: 0x5944

When the GPO is applied, the Group Policy client service on each targeted machine will create or update this registry value. The next time the Secure Boot servicing task (TPMTasks) runs on that machine, it will detect 0x5944 and carry out the update.

Note: By design, on Windows the “TPMTask” scheduled task runs every 12 hours to process such Secure Boot update flags. Admins can also expedite by manually running the task or restarting, if desired.

Example policy UI

• Setting
  Enable Secure Boot Key Rollout: When enabled, the device will install the updated Secure Boot certificates (2023 CAs) and associated boot manager update. The device’s firmware Secure Boot keys and configurations will be updated in the next maintenance window. Status can be tracked via the registry (UEFICA2023Status and UEFICA2023Error) or Windows Event Log.

• Options
  Enabled / Disabled / Not Configured

This single setting approach keeps it simple for all customers (always using the recommended 0x5944 value).

Important: If in the future more granular control is needed, additional policies or options could be introduced. However, current guidance is that all new Secure Boot keys and the new boot manager should be deployed together in nearly all scenarios, so a one-toggle deployment is appropriate.

Security & permissions: Writing to the ​​​​​​​HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet hive requires administrative privileges. Group Policy runs as Local System on clients, which has the necessary rights. The GPO itself can be edited by administrators with Group Policy management rights. Standard GPO security can prevent non-admins from altering the policy.