Secure Boot Certificate updates: Guidance for IT professionals and organizations

Secure Boot certificate expiration

The configuration of certificate authorities (CAs), also referred to as certificates, provided by Microsoft as part of the Secure Boot infrastructure, has remained the same since Windows 8 and Windows Server 2012. These certificates are stored in the Signature Database (DB) and Key Exchange Key (KEK) variables in the firmware. Microsoft has provided the same three certificates across the original equipment manufacturer (OEM) ecosystem to include in the device's firmware. These certificates support Secure Boot in Windows and are also used by third-party operating systems (OS). The following certificates are provided by Microsoft:

• Microsoft Corporation KEK CA 2011

• Microsoft Windows Production PCA 2011

• Microsoft Corporation UEFI CA 2011

What's changing?

Current Microsoft Secure Boot certificates (Microsoft Corporation KEK CA 2011, Microsoft Windows Production PCA 2011, Microsoft Corporation UEFI CA 2011) will begin expiring starting in June 2026 and would expire by October 2026. 

New 2023 certificates are being rolled out to maintain Secure Boot security and continuity. Devices must update to the 2023 certificates before the 2011 certificates expire or they will be out of security compliance and at risk.  

Windows devices manufactured since 2012 may have expiring versions of certificates, which must be updated. 

Terminology

Certificates

Verifying Secure Boot status across your fleet: Is Secure Boot enabled? 

Most devices manufactured since 2012 have support for Secure Boot and are shipped with Secure Boot enabled. To verify that a device has Secure Boot enabled, do one of the following: 

• GUI Method: Go to Start > Settings > Privacy & Security > Windows Security > Device Security. Under Device security, the Secure boot section should indicate that Secure Boot is on.

• Command Line method: At an elevated command prompt in PowerShell, type Confirm-SecureBootUEFI and then press Enter. The command should return True indicating that Secure Boot is on.

In large scale deployments for a fleet of devices, the management software being used by IT pros will need to provide a check for Secure Boot enablement. 

For example, the method to check the Secure Boot state on Microsoft Intune-managed devices is to create and deploy an Intune custom compliance script. Intune compliance settings are covered in Use custom compliance settings for Linux and Windows devices with Microsoft Intune.  

How updates are deployed

There are multiple ways to target devices for the Secure Boot certificate updates. Deployment details, including settings and events, will be discussed later in this document. When you target a device for updates, a setting is made on the device to indicate that the device should begin the process of applying the new certificates. A scheduled task runs on the device every 12 hours and detects that the device has been targeted for the updates. An outline of what the task does is as follows:

1. The Windows UEFI CA 2023 is applied to the DB.

2. If the device has the Microsoft Corporation UEFI CA 2011 in the DB, then the task applies the Microsoft Option ROM UEFI CA 2023 and the Microsoft UEFI CA 2023 to the DB.

3. The task then adds the Microsoft Corporation KEK 2K CA 2023.

4. Finally, the scheduled task updates the Windows boot manager to the one signed by the Windows UEFI CA 2023. Windows will detect that a restart is needed before the boot manager can be applied. The boot manager update will be delayed until the restart occurs naturally (such as when monthly updates are applied), and then Windows will again attempt to apply the boot manager update.

Each of the steps above must be completed successfully before the scheduled task moves to the next step. During this process, event logs and other status will be available to aid in monitoring of the deployment. More details on monitoring and event logs are provided below.  

Updating the Secure Boot Certificates enables a future update to the 2023 Boot Manager, which is more Secure. Specific updates on Boot Manager will be in future releases.

Deployment steps 

• Preparation: Inventory and test devices.

• Firmware considerations

• Monitoring: Verify monitoring works and baseline your fleet.

• Deployment: Target devices for updates, starting with small subsets and expanding based on successful tests.

• Remediation: Investigate and resolve any issues using logs and vendor support.

Preparation 

Inventory hardware and firmware. Build a representative sample of devices based on System Manufacturer, System Model, BIOS Version/Date, BaseBoard Product version, etc., and test updates on those samples before broad deployment.  These parameters are commonly available in system information (MSINFO32). 

Example PowerShell commands to collect the information are:

Firmware considerations

Deploying the new Secure Boot certificates to your fleet of devices requires that the device firmware play a role in completing the update. While Microsoft expects that most device firmware will perform as expected, careful testing is needed before deploying the new certificates.

Examine your hardware inventory and build a small, representative sample of devices based on the following unique criteria such as: 

• Manufacturer

• Model Number

• Firmware Version

• OEM Baseboard version, etc.

Before deploying broadly to devices in your fleet we recommend that you test the certificate updates on representative sample devices (as defined by factors such as manufacturer, model, firmware version) to ensure that the updates are processed successfully. Recommended guidance on the number of sample devices to test for each unique category is 4 or more.

This will aid in building confidence in your deployment process and help to avoid unanticipated impacts on your broader fleet. 

In some cases, a firmware update might be required to successfully update the Secure Boot certificates. In these cases, we recommend checking with your device OEM to see if updated firmware is available.

Windows in virtualized environments

For Windows running in a virtual environment, there are two methods for adding the new certificates to the Secure Boot firmware variables:  

• The creator of the virtual environment (AWS, Azure, Hyper-V, VMware, etc.) can provide an update for the environment and include the new certificates in the virtualized firmware. This would work for new virtualized devices.

• For Windows running long term in a VM, the updates can be applied through Windows like any other devices, if the virtualized firmware supports Secure Boot updates.

Monitoring and deployment 

We recommend that you begin the device monitoring prior to deployment to ensure that monitoring is working correctly and you have a good sense for the state of the fleet in advance. Monitoring options are discussed below. 

Microsoft provides multiple methods for deploying and monitoring the Secure Boot certificate updates.

Automated deployment assists 

Microsoft is providing two deployment assists. These assists may prove useful in aiding in the deployment of the new certificates to your fleet. Both assists require diagnostic data.

• Option for cumulative updates with confidence buckets: Microsoft may automatically include high-confidence device groups in monthly updates based on diagnostic data shared to date, to benefit systems and organizations that cannot share diagnostic data. This step does not require diagnostic data to be enabled.

  • For organizations and systems that can share diagnostic data, it gives Microsoft the visibility and confidence that devices can successfully deploy the certificates. More information on enabling diagnostic data is available in: Configure Windows diagnostic data in your organization. We are creating “buckets” for each unique device (as defined by attributes that include manufacturer, motherboard version, firmware manufacturer, firmware version, and additional data points). For each bucket, we are monitoring success evidence over multiple devices. Once we have seen enough successful updates and no failures, we will consider the bucket “high-confidence” and include that data in the monthly cumulative updates. When monthly updates are applied to a device in a high-confidence bucket, Windows will automatically apply the certificates to the UEFI Secure Boot variables in firmware.

  • High-confidence buckets include devices that are processing the updates correctly. Naturally, not all devices will provide diagnostic data, and this may limit Microsoft confidence in a device’s ability to process the updates correctly.

  • This assist is enabled by default for high-confidence devices and can be disabled with a device-specific setting. More information will be shared in future Windows releases.

• Controlled Feature Rollout (CFR):  Opt in devices for Microsoft-managed deployment if diagnostic data is enabled.

  • Controlled Feature Rollout (CFR) can be used with client devices in organization fleets. This requires that devices are sending required diagnostic data to Microsoft and have signaled that the device is opting in to allow CFR on the device. Details on how to opt in are described below.

  • Microsoft will manage the update process for these new certificates on Windows devices where diagnostic data is available and the devices are participating in Controlled Feature Rollout (CFR). While CFR may assist in deployment of the new certificates, organizations won’t be able to rely on CFR to remediate their fleets – it will require following the steps outlined in this document in the section on Deployment methods not covered by automated assists.

  • Limitations: There are a few reasons that CFR may not work in your environment. For example:

    • No diagnostic data is available or the diagnostic data is not usable as part of the CFR deployment.

    • Devices are not on supported client versions of Windows 11 and Windows 10 with extended security updates (ESU).

Deployment methods not covered by automated assists

Choose the method that fits your environment. Avoid mixing methods on the same device: 

• Registry keys: Control deployment and monitor results.
  There are multiple registry keys available for controlling the behavior of the deployment of the certificates and for monitoring the results. In addition, there are two keys to opting in and out of the deployment aids described above. For more information on the registry keys, see Registry Key Updates for Secure Boot - Windows devices with IT-managed updates.

• Group Policy Objects (GPO): Manage settings; monitor via registry and event logs.
  Microsoft will be providing support for managing the Secure Boot updates using Group Policy in a future update. Note that since Group Policy is for settings, monitoring the device status will need to be done using alternate methods including monitoring registry keys and event log entries.

• WinCS (Windows Configuration System) CLI: Use command-line tools for domain-joined clients.
  Domain administrators can alternatively use the Windows Configuration System (WinCS) included in Windows OS updates to deploy the Secure Boot updates across domain-joined Windows clients and servers. It consists of a series of command-line utilities (both a traditional executable and a PowerShell module) to query and apply Secure Boot configurations locally to a machine. For more information, see Windows Configuration System (WinCS) APIs for Secure Boot.

• Microsoft Intune/Configuration Manager: Deploy PowerShell scripts. A Configuration Service Provider (CSP) will be provided in a future update to allow for deployment using Intune.

Monitoring Event Logs

Two new events are being provided to assist in deploying the Secure Boot certificate updates. These events are described in detail in Secure Boot DB and DBX variable update events: 

• Event ID: 1801
  This event is an error event that indicates that the updated certificates have not been applied to the device. This event gives some details specific to the device, including device attributes, that will help in correlating which devices still need updating.

• Event ID: 1808
  This event is an informational event that indicates that the device has the required new Secure Boot certificates applied to the device’s firmware.

Deployment strategies 

To minimize risk, deploy Secure Boot updates in stages rather than all at once. Begin with a small subset of devices, validate results, and then expand to additional groups. We suggest that you start with subsets of devices and, as you gain confidence in those deployments, add additional subsets of devices. Multiple factors can be used to determine what goes into a subset, including test results on sample devices and organization structure, etc. 

The decision about which devices you deploy is up to you. Some possible strategies are listed here. 

• Large device fleet: begin by relying on the assists described above for the most common devices that you manage. In parallel, focus on the less common devices managed by your organization. Test small sample devices and, if the testing is successful, deploy to the rest of the devices of the same type. If the testing produces issues, investigate the cause of the issue and determine remediation steps. You may also want to consider classes of devices that have higher value in your fleet and begin testing and deploying to ensure those devices have updated protection in place early.

• Small fleet, large variety: If the fleet you are managing contains a large variety of machines where testing individual devices would be prohibitive, consider relying heavily on the two assists described above, especially for devices that are likely to be common devices in the market. Initially focus on devices that are critical to day-to-day operation, test and then deploy. Continue moving down the list of high-priority devices, testing and deploying while monitoring the fleet to confirm that the assists are helping with the remainder of the devices.

Notes 

• Pay attention to older devices, especially devices that are no longer supported by the manufacturer. While the firmware should perform the update operations correctly, some may not. In cases where the firmware does not work correctly and the device is no longer in support, consider replacing the device to ensure Secure Boot protection across your fleet.

• New devices manufactured in the past 1-2 years may already have the updated certificates in place but might not have the Windows UEFI CA 2023 signed boot manager applied to the system. Applying this boot manager is a critical last step in the deployment for each device.

• Once a device has been selected for updates, it may take some time before the updates are complete. Estimate 48 hours and one or more restarts for the certificates to apply.

Common issues and recommendations

​​​​​​​This guide goes in detail about how the Secure Boot certificate update process works and presents some steps to troubleshoot if issues are encountered during the deployment to devices. Updates to this section will be added as needed.

Secure Boot certificate deployment support 

In support of the Secure Boot certificate updates, Windows maintains a scheduled task that runs once every 12 hours. The task looks for bits in the AvailableUpdates registry key that needs processing. The bits of interest used in deploying the certificates are in the following table. The Order column indicates the order that the bits are processed.

Each of the bits is processed by the scheduled event in the order given in the table above.

The progression through the bits should look like this: 

1. Start: 0x5944

2. 0x0040 → 0x5904 (Applied the Windows UEFI CA 2023 successfully)

3. 0x0800 → 0x5104 (Applied the Microsoft UEFI CA 2023 if needed)

4. 0x1000 → 0x4104 (Applied the Microsoft Option ROM UEFI CA 2023 if needed)

5. 0x0004 → 0x4100 (Applied the Microsoft Corporation KEK 2K CA 2023)

6. 0x0100 → 0x4000 (Applied the Windows UEFI CA 2023 signed boot manager)

Notes

• Once the operation associated with a bit completes successfully, that bit is cleared from the AvailableUpdates key.

• If one of these operations fail, an event is logged, and the operation is retried the next time the scheduled task runs.

• If bit 0x4000 is set, it will not be cleared. After all other bits have been processed, the AvailableUpdates registry key will be set to 0x4000.

Issue 1: KEK update Failure: The device updates certificates to the Secure Boot DB but does not progress past deploying the new Key Exchange Key certificate to the Secure Boot KEK. 

Note Currently when this issue occurs, an Event ID: 1796 will be logged (see Secure Boot DB and DBX variable update events). A new event will be provided in later release to indicate this specific issue. 

The AvailableUpdates registry key on a device is set to 0x4104 and does not clear the 0x0004 bit, even after multiple reboots and considerable time has passed. 

The issue could be that there is not a KEK signed by the OEM’s PK for the device. The OEM controls the PK for the device and is responsible for signing the new Microsoft KEK certificate and returning it to Microsoft so that it can be included in the monthly cumulative updates. 

If you encounter this error, check with your OEM to confirm they have followed the steps outlined in Windows Secure Boot Key Creation and Management Guidance.  

Issue 2: Firmware errors: When applying the certificate updates, the certificates are handed off to the firmware to apply to the Secure Boot DB or KEK variables. In some cases, the firmware will return an error. 

When this issue occurs, Secure Boot will log an Event ID: 1795. For information about this event, see Secure Boot DB and DBX variable update events. 

We recommend checking with the OEM to see if there is a firmware update available for the device to resolve this issue.