Windows devices with IT-managed updates

More details about the registry key-based Secure Boot updates

The policy logic is built around three registry values stored in the following secure boot servicing registry path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

Note All the following registry subkeys are used to trigger the update and to record the update status.

How these keys work together

The IT admin (via GPO or CSP) configures AvailableUpdates = 0x5944, which signals Windows to execute the Secure Boot key roll process on the device. As the process runs, the system updates UEFICA2023Status from "NotStarted" to "InProgress", and finally to "Updated" upon success. As each bit in 0x5944 is processed successfully, it is cleared. If any step fails, an error code is recorded in UEFICA2023Error (and the status may remain "InProgress" or a partially updated state). This mechanism gives administrators a clear way to trigger and track the rollout per device.

Note: These registry values are introduced specifically for this feature (they do not exist on older systems until the supporting update is installed). The names UEFICA2023Status and UEFICA2023Error were defined in the design to capture the status of adding the “Windows UEFI CA 2023” certificates. They appear in the above registry path once the system is updated to a build that supports Secure Boot key rolling. 

Affected platforms

Secure Boot is supported in Windows starting with the Windows Server 2012 code base and Group Policy support exists in all versions of Windows that support Secure Boot. Therefore, Group Policy support will be provided on all supported versions of Windows that supports Secure Boot. 

This table further breaks down the support based on registry key.

Our SBAI/TpmTasks implements a new routine to ingest the schema and make the determination of a Device’s bucket ID. It also needs to emit events to represent a Device’s bucket id on every boot session.  

These new events will require that the Device Bucket Confidence data is present on the system. The data will be included with the cumulative updates and will be available online for up-to-date downloads. 

Secure Boot error events

Error events have a critical reporting function to inform about Secure Boot Status and progress.  For information about the error events, see Secure Boot DB and DBX variable update events. The error events are being updated with additional event for Secure Boot.

Information events

Machine Up to Date Event

An information event will indicate that the machine is up to date, and no action is needed.

Event ID: 1803

Warning events

Secure Boot Defaults Need Updating Event

Warning event that will indicate that the device’s firmware Secure Boot default settings are not up to date. This occurs when the device is booting from a PCA2023 signed boot manager and the DBDefaults in the firmware do not include the PCA2023 certificate. 

Event ID: 1804

Additional Component Changes for Secure Boot

TPMTasks changes

Modify TPMTasks to determine if the state of the device either has the updated Secure Boot Certificates or does not. Currently it can make that determination but only if our CFR selects a machine for update. We want that determination and subsequent logging to happen in every boot session regardless of the CFR. If the Secure Boot Certificates are not fully up to date, then emit the two error events described above and if the Certificates are up to date, then emit the Information event. The Secure Boot Certificates that will be checked are: 

• Windows UEFI CA 2023

• Microsoft UEFI CA 2023 and Microsoft Option ROM CA 2023 – if the Microsoft UEFI CA 2011 is present, then these two CA must be present. If the Microsoft UEFI CA 2011 is not present, then no check is necessary.

• Microsoft Corporation KEK CA 2023

Machine Metadata Event

This event will gather the machine meta-data and issue an event.  

• BucketId + Confidence Rating Event  

This event will use the meta-data of the machine to find the corresponding entry in the database of machines (bucket entry) and will format and emit an event with this data along with any confidence information regarding the bucket. ​​​​​​​

High Confident Device Assist 

For devices in high confidence buckets, the Secure Boot certificates and 2023 signed boot manager will automatically be applied.  

The update will be triggered at the same time as the two error events are generated, and the BucketId + Confidence Rating event includes a high-confidence rating.  

For customers that want to opt-out, a new registry key will be available as follows:  

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 house this policy.

• Scope: Computer (machine-wide setting) – because it targets HKLM and affects the device’s UEFI state.

• Policy Action: When Enabled, the policy will set the registry key AvailableUpdatesPolicy to the value 0x5944 (REG_DWORD) on the client under the path  HKLM\System\CurrentControlSet\Control\SecureBoot\Servicing. This flags the device to install all available Secure Boot key updates on next opportunity. 

  Note: Due to the nature of Group Policy where the policy will be reapplied over time, and the nature of the AvailableUpdates where the bits are cleared as they are processed, it is necessary to have a separate registry key called 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 (set to 0) AvailableUpdates and make note that this has been completed.

• Disabled/Not Configured: When Not Configured, the policy makes no changes (Secure Boot updates remain opt-in and won’t run unless triggered by other means). If Disabled, the policy should set AvailableUpdates = 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 via 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\... (Group Policy normally writes to the Policies branch), but in this case we need to affect HKLM\SYSTEM. We will leverage Group Policy’s ability to write directly to HKLM for machine policies. The ADMX can use the element with the real target path.

• Value name: AvailableUpdatesPolicy, Value: 0x5944 (DWORD).

When the GPO is applied, the Group Policy client service on each targeted machine will create/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. (By design, on Windows the “TPMTask” scheduled task runs every 12 hours to process such Secure Boot update flags, so within at most 12 hours the update will start. Admins can also expedite by manually running the task or rebooting, 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). 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 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\... 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.

Text for Group Policy UI

The English text used when configuring the policy is as follows.