Original publish date: February 13, 2025
KB ID: 5053946
Introduction
This document describes the deployment of the protections against the publicly disclosed Secure Boot security feature bypass that uses the BlackLotus UEFI bootkit tracked by CVE-2023-24932 for enterprise environments.
To avoid disruptions, Microsoft does not plan to deploy these mitigations in enterprises but is providing this guidance to help enterprises apply the mitigations themselves. This gives enterprises control over the deployment plan and timing of deployments.
Getting started
We have divided the deployment into multiple steps that can be achieved on a timeline that works for your organization. You should familiarize yourself with these steps. Once you have a good understanding of the steps, you should consider how they will work in your environment and prepare deployment plans that work for your enterprise on your timeline.
Adding the new Windows UEFI CA 2023 certificate and untrusting the Microsoft Windows Production PCA 2011 certificate requires cooperation from the device’s firmware. Since there is a large combination of device hardware and firmware, and Microsoft is unable to test all combinations, we encourage you to test representative devices in your environment before deploying broadly. We recommend that you test at least one device of each type that is used in your organization. Some known device issues that will block these mitigations are documented as part of KB5025885: How to manage the Windows boot manager revocations for Secure Boot changes associated with CVE-2023-24932. If you detect a device firmware issue not listed in the Known Issues section, work with your OEM vendor to address the issue.
Because this document references several different certificates, they are presented in the following table for easy reference and clarity:
Old 2011 CAs |
New 2023 CAs (expire in 2038) |
Function |
Microsoft Corporation KEK CA 2011 (expires in July 2026) |
Microsoft Corporation KEK CA 2023 |
Signs DB and DBX updates |
Microsoft Windows Production PCA 2011 (PCA2011) (expires in October 2026) |
Windows UEFI CA 2023 (PCA2023) |
Signs Windows bootloader |
Microsoft Corporation UEFI CA 2011 (expires in July 2026) |
Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 |
Signs third-party bootloaders and option ROMs |
Important Be sure to apply the latest security updates to the test machines before testing devices with the mitigations.
Note During your device firmware testing, you may discover issues that prevent the Secure Boot updates from working correctly. This might require obtaining updated firmware from the manufacturer (OEM) and updating the firmware on the affected devices to mitigate issues you discover.
There are four mitigations that must be applied to protect against the attacks described in CVE-2023-24932:
-
Mitigation 1: Install the updated certificate (PCA2023) definition to the DB
-
Mitigation 2: Update the boot manager on your device
-
Mitigation 3: Enable the revocation (PCA2011)
-
Mitigation 4: Apply the SVN update to the firmware
These four mitigations can be manually applied to each of the test devices following the guidance described in the Mitigation deployment guidelines of KB5025885: How to manage the Windows boot manager revocations for Secure Boot changes associated with CVE-2023-24932, or by following the guidance in this document. All four mitigations rely on the firmware to operate properly.
Understanding the following risks will help you during your planning process.
Firmware Issues: Each device has firmware provided by the manufacturer of the device. For the deployment operations described in this document, the firmware must be able to accept and process updates to the Secure Boot DB (Signature Database) and DBX (Forbidden Signature Database). In addition, the firmware is responsible for validating the signature or boot applications, including the Windows boot manager. The device firmware is software and, like any software, may have defects, which is why it is important to test these operations before deploying widely.
Microsoft has ongoing testing of many device/firmware combinations, starting with the devices within Microsoft labs and offices, and Microsoft is working with OEMs to test their devices. Nearly all the devices tested have passed without issue. In a few cases, we have seen issues with the firmware not correctly handling the updates and we are working with the OEMs to address the issues of which we are aware.Note During your device testing, if you detect a firmware issue, we recommend working with your device manufacturer/OEM to resolve the issue. Look for Event ID 1795 in the event log. See KB5016061: Secure Boot DB and DBX variable update events for more details on Secure Boot events.
Install Media: By applying Mitigation 3 and Mitigation 4 described later in this document, any existing Windows install media will no longer be bootable until the media has an updated boot manager. The mitigations described in this document prevent old, vulnerable boot managers from running by untrusting them in the firmware. This prevents an attacker from rolling back the system boot manager to a previous version and exploiting vulnerabilities present in older versions. Blocking these vulnerable boot managers should have no impact on the running system. It will, however, prevent any bootable media from starting until the boot managers on the media are updated. This includes ISO images, bootable USB drives, and Network boot (PxE and HTTP boot).
Update to PCA2023 and the new boot manager
-
Mitigation 1: Install the updated certificate definitions to the DB
Adds the new Windows UEFI CA 2023 certificate to the UEFI Secure Boot Signature Database (DB). By adding this certificate to the DB, the device firmware will trust Microsoft Windows boot applications signed by this certificate. -
Mitigation 2: Update the boot manager on your device
Applies the new Windows boot manager signed with the new Windows UEFI CA 2023 certificate.
These mitigations are important for the long-term serviceability of Windows on these devices. Because the Microsoft Windows Production PCA 2011 certificate in the firmware will expire in October 2026, devices must have the new Windows UEFI CA 2023 certificate in the firmware before expiration or the device will no longer be able to receive Windows updates, putting it in a vulnerable security state.
For information about how to apply Mitigation 1 and Mitigation 2 in two separate steps (if you want to be more cautious, at least at first) see KB5025885: How to manage the Windows boot manager revocations for Secure Boot changes associated with CVE-2023-24932. Or you can apply both mitigations by running the following single registry key operation as an administrator:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x140 /f |
As the mitigations apply, the bits in the AvailableUpdates key will be cleared. After setting it to 0x140 and restarting, the value will change to 0x100 and then, after another restart, it will change to 0x000.
The boot manager mitigation will not be applied until the firmware indicates that the 2023 certificate mitigation is successfully applied. These operations cannot be performed out of order.
When both mitigations are applied, a registry key will be set to indicate that the system is “2023 capable”, meaning that the media can be updated and Mitigation 3 and Mitigation 4 can be applied.
In most cases, completing Mitigation 1 and Mitigation 2 requires at least two restarts before the mitigations are fully applied. Adding additional restarts in your environment will help ensure that the mitigations are applied sooner. However, it may not be practical to artificially inject additional restarts and may make sense to rely on the monthly restarts that occur as part of applying the security updates. Doing so means less disruption in your environment but at risk of taking longer to get secure.
After deploying Mitigation 1 and Mitigation 2 to your devices, you should monitor your devices to ensure that they have the mitigations applied and are now “2023 capable”. Monitoring can be done by looking for the following registry key on the system. If the key exists and is set to 1, then the system has added the 2023 certificate to the Secure Boot DB variable. If the key exists and is set to 2, then the system has the 2023 certificate in the DB and starts with the 2023 signed boot manager.
Registry Subkey |
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing |
|
Key Value name |
WindowsUEFICA2023Capable |
|
Data Type |
REG_DWORD |
|
Data |
0 – or key does not exist - “Windows UEFI CA 2023” certificate is not in the DB 1 - “Windows UEFI CA 2023” certificate is in the DB 2 - “Windows UEFI CA 2023” certificate is in the DB and the system is starting from the 2023 signed boot manager. |
Update Bootable Media
After Mitigation 1 and Mitigation 2 are applied to your devices, you can update any bootable media that you use in your environment. Updating the bootable media means applying the PCA2023 signed boot manager to the media. This includes updating the network boot images (such as PxE and HTTP), ISO images, and USB drives. Otherwise, devices with the mitigations applied will not start from boot media that uses the older Windows boot manager and 2011 CA.
Tools and guidance on how to update each type of bootable media are available here:
Media Type |
Resource |
ISO, USB drives, and so forth |
KB5053484: Updating Windows bootable media to use the PCA2023 signed boot manager |
PXE Boot Server |
Documentation to be provided later |
During your media update process, you should be sure to test the media with a device that has all four mitigations in place. The final two mitigations will block older, vulnerable boot managers. Having media with current boot managers in place is an important part of completing this process.
Note Because boot manager roll-back attacks are a reality and we expect ongoing updates to the Windows boot manager to address security issues, we recommend that enterprises plan for semi-regular media updates and have processes in place to make media updates easy and less time consuming. Our goal is to limit the number of media boot manager refreshes to at most two times per year, if possible.
Bootable media does not include the device system drive where Windows typically resides and starts from automatically. Bootable media is commonly used to boot a device that doesn’t have a bootable version of Windows and bootable media is often used to install Windows on the device.
The UEFI Secure Boot settings determine which boot managers to trust by using the Secure Boot DB (Signature Database) and DBX (Forbidden Signature Database). The DB contains the hashes and keys for trusted software, and the DBX stores revoked, compromised, and non-trusted hashes and keys to prevent unauthorized or malicious software from running during the boot process.
It is useful to think about the different states that a device can be in and what bootable media can be used with the device in each of these states. In all cases, the firmware determines if it should trust the boot manager it is presented with and, once it runs the boot manager, the DB and DBX are no longer consulted by the firmware. Bootable media can either use a 2011 CA signed boot manager or a 2023 CA signed boot manager but not both. The next section describes what states that the device can be in, and, in some cases, what media can be booted from the device.
These device scenarios may help when making plans for deploying the mitigations across your devices.
New Devices
Some new devices began shipping with both the 2011 and 2023 CAs preinstalled in the device firmware. Not all manufacturers have switched over to have both and may still be shipping devices with only the 2011 CA preinstalled.
-
Devices with both the 2011 and 2023 CAs can start media that includes either the 2011 CA signed boot manager or the 2023 CA signed boot manager.
-
Devices with only the 2011 CA installed can only boot media with the 2011 CA signed boot manager. Most older media include the 2011 CA signed boot manger.
Devices with Mitigations 1 and 2
These devices were preinstalled with the 2011 CA and, by applying Mitigation 1, now have the 2023 CA installed. Since these devices trust both CAs, these devices can start both the media with the 2011 CA and the 2023 signed boot manager.
Devices with Mitigations 3 and 4
These devices have the 2011 CA included in the DBX and will no longer trust media with a 2011 CA signed boot manager. A device with this configuration will only start media with a 2023 CA signed boot manager.
Secure Boot Reset
If the Secure Boot settings have been reset to the default values, any mitigations that have been applied to the DB (adding the 2023 CA) and the DBX (untrusting the 2011 CA) may no longer be in place. The behavior will depend on what the firmware defaults are.
DBX
If Mitigations 3 and/or 4 have been applied and the DBX is cleared, then the 2011 CA will not be on the DBX list and will still be trusted. If this occurs, reapplying mitigations 3 and/or 4 will be necessary.
DB
If the DB contained the 2023 CA and it is removed by resetting the Secure Boot settings to the defaults, the system may not boot if the device relies on the 2023 CA signed boot manager. If the device does not boot, use the securebootrecovery.efi tool described in KB5025885: How to manage the Windows boot manager revocations for Secure Boot changes associated with CVE-2023-24932 to recover the system.
Untrust PCA2011 and apply Secure Version Number to DBX
-
Mitigation 3: Enable the revocation
Untrusts the Microsoft Windows Production PCA 2011 certificate by adding it to the firmwares Secure Boot DBX. This will cause the firmware to not trust all 2011 CA signed boot managers and any media that relies on the 2011 CA signed boot manager. -
Mitigation 4: Apply the Secure Version Number update to the firmware
Applies the Secure Version Number (SVN) update to the firmwares Secure Boot DBX. When a 2023-signed boot manager starts to run, it performs a self-check by comparing the SVN stored in the firmware with the SVN built into the boot manager. If the boot manager SVN is lower than the firmware SVN, the boot manager will not run. This feature prevents an attacker from rolling back the boot manager to an older, non-updated version. For future security updates to the boot manager, the SVN will be incremented, and Mitigation 4 will need to be reapplied.
Important Mitigation 1 and Mitigation 2 must be completed before applying Mitigation 3 and Mitigation 4.
For information about how to apply Mitigation 3 and Mitigation 4 in two separate steps (if you want to be more cautious, at least at first) see KB5025885: How to manage the Windows boot manager revocations for Secure Boot changes associated with CVE-2023-24932 Or you can apply both mitigations by running the following single registry key operation as an Administrator:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x280 /f |
Applying both mitigations together will only require one restart to complete the operation.
-
Mitigation 3: You can verify the revocation list was successfully applied by looking for Event ID: 1037 in the event log, per KB5016061: Secure Boot DB and DBX variable update events. Alternatively, you can run the following PowerShell command as an Administrator and make sure it returns True:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
-
Mitigation 4: A method to confirm that the SVN setting has been applied does not yet exist. This section will be updated when a solution is available.
References
KB5016061: Secure Boot DB and DBX variable update events
KB5053484: Updating Windows bootable media to use the PCA2023 signed boot manager