Windows Secure Boot stores Microsoft certificates in the UEFI KEK and DB. These original certificates are approaching expiration, and devices containing affected certificate versions must update them to maintain Secure Boot functionality and avoid compromising security by losing security fixes related to Windows boot manager or Secure Boot. The operating system’s certificate update protection mechanism relies on firmware components that might contain defects, which can cause certificate trust updates to fail or behave unpredictably. This leads to potential disruption of the Secure Boot trust chain and requires careful validation and deployment to restore intended security guarantees.
Certificate Authority (CA) Location Purpose Expiration Date
Microsoft Corporation KEK CA 2011 KEK Signs updates to the DB and DBX 06/24/2026
Microsoft Corporation UEFI CA 2011 DB Signs 3rd party boot loaders, Option ROMs, etc. 06/27/2026
Microsoft Windows Production PCA 2011 DB Signs the Windows Boot Manager 10/19/2026
For more information see this CVE and Windows Secure Boot certificate expiration and CA updates.
Weakness
The product contains a component that cannot be updated or patched in order to remove vulnerabilities or significant bugs.
Affected Software
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Windows_10_1607 | Microsoft | * | 10.0.14393.8783 (excluding) |
| Windows_10_1809 | Microsoft | * | 10.0.17763.8276 (excluding) |
| Windows_10_21h2 | Microsoft | * | 10.0.19044.6809 (excluding) |
| Windows_10_22h2 | Microsoft | * | 10.0.19045.6809 (excluding) |
| Windows_11_23h2 | Microsoft | * | 10.0.22631.6491 (excluding) |
| Windows_11_24h2 | Microsoft | * | 10.0.26100.7623 (excluding) |
| Windows_11_25h2 | Microsoft | * | 10.0.26200.7623 (excluding) |
| Windows_server_2012 | Microsoft | - (including) | - (including) |
| Windows_server_2012 | Microsoft | r2 (including) | r2 (including) |
| Windows_server_2016 | Microsoft | * | 10.0.14393.8783 (excluding) |
| Windows_server_2019 | Microsoft | * | 10.0.17763.8276 (excluding) |
| Windows_server_2022 | Microsoft | * | 10.0.20348.4648 (excluding) |
| Windows_server_2022_23h2 | Microsoft | * | 10.0.25398.2092 (excluding) |
| Windows_server_2025 | Microsoft | * | 10.0.26100.32230 (excluding) |
| Secureboot-db | Ubuntu | esm-infra-legacy/trusty | * |
| Secureboot-db | Ubuntu | esm-infra/xenial | * |
| Shim | Ubuntu | esm-infra-legacy/trusty | * |
| Shim | Ubuntu | esm-infra/xenial | * |
| Shim-signed | Ubuntu | esm-infra-legacy/trusty | * |
| Shim-signed | Ubuntu | esm-infra/xenial | * |
Extended Description
If the component is discovered to contain a vulnerability or critical bug, but the issue cannot be fixed using an update or patch, then the product's owner will not be able to protect against the issue. The only option might be replacement of the product, which could be too financially or operationally expensive for the product owner. As a result, the inability to patch or update can leave the product open to attacker exploitation or critical operation failures. This weakness can be especially difficult to manage when using ROM, firmware, or similar components that traditionally have had limited or no update capabilities.
In industries such as healthcare, "legacy"
devices can be operated for decades. As a
US task force report [REF-1197] notes, "the inability
to update or replace equipment has both
large and small health care delivery
organizations struggle with numerous
unsupported legacy systems that cannot
easily be replaced (hardware, software, and
operating systems) with large numbers of
vulnerabilities and few modern
countermeasures."
While hardware can be prone to this weakness, software systems can also be affected, such as when a third-party driver or library is no longer actively maintained or supported but is still critical for the required functionality.