Feature Overview
The current Microsoft Secure Boot DBX servicing model uses a single global baseline (dbxupdate.bin) containing hundreds of revocation hashes across multiple signing authorities, for AMD64 / X64 the following:
Count SigningAuthority
----- ----
241 CN = Microsoft Corporation UEFI CA 2011
173 CN = Microsoft Windows Production PCA 2011
29 {Not specified}
This global baseline model does not account for the signing authorities actually present in each device’s DB, creating two major issues:
Major security gaps: The latest %SystemRoot%\System32\SecureBootUpdates\dbxupdate.bin file drops 154 hashes attributed to BlackLotus, marked as isOptional in the global baseline json dbx_info_msft_latest.json. These revocations are the most critical and need to be enforced when PCA 2011 is still present in DB, as well as all other hashes for all other signing authorities present. The isOptional is not officially documented and remains issue of ongoing debates about dropped Canonical entries (#446).
NVRAM inefficiency: Modern platforms may no longer rely on the 2011 legacy certificate authorities. However, these systems receive and store redundant revocation entries from the global DBX baseline. This consumes limited UEFI NVRAM storage, and contributes to Secure Boot variable update failures, even on officially Windows 11-compatible ThinkPads.
Summary: A global dbxupdate.bin cannot optimize for per-device trust state. DB-aware DBX servicing is required to make revocation enforcement secure and NVRAM-efficient.
Solution Overview
Implement modular DBX payloads (for each CPU architecture) with DB-aware servicing.
DBXUpdate-Core.bin — universal revocations for all Windows machines
DBXUpdate-PCA2011.bin — revocations only required if Microsoft Windows Production PCA 2011 in DB
DBXUpdate-UEFICA2011.bin — revocations only required if Microsoft Corporation UEFI CA 2011 in DB
Before applying latest DBX updates, Windows should check DB (Get-SecureBootUEFI DB -Decoded) and download and apply only the bin-files applicable for the specific device DB.
Modern systems that have migrated away from Microsoft Windows Production PCA 2011 no longer need its associated revocation hashes (173 entries for AMD64). Meanwhile, Microsoft Corporation UEFI CA 2011 remains relevant for many platforms, including dGPU systems such as NVIDIA RTX 50-series, despite being expired (241 entries for AMD64). Windows UEFI CA 2023-only notebooks do not need any of these 414 revocations associated with 2011 certs.
Summary: Modular DBX payloads ensure strong security enforcement while reducing NVRAM usage, simplifying servicing, and minimizing unnecessary update distribution and application.
Microsoft will need to maintain a matrix of 12 BIN files, and the dbx_info_msft_latest.json should reflect that.
Individual devices will only require one, up to three BIN files.
| amd64 |
x86 |
arm64 |
arm |
| amd64-Core |
x86-Core |
arm64-Core |
arm-Core |
| amd64-PCA2011 |
x86-PCA2011 |
arm64-PCA2011 |
arm-PCA2011 |
| amd64-UEFICA2011 |
x86-UEFICA2011 |
arm64-UEFICA2011 |
arm-UEFICA2011 |
Alternatives Considered
The existing monolithic dbxupdate.bin approach cannot optimize for individual device trust states: security enforcement remains ambiguous, while unnecessary DBX entries continue to consume limited NVRAM storage. The still-undocumented isOptional flag has resulted in ongoing interpretation debates and does not provide a mechanism for per-device targeting, as discussed in #429 (comment) and #444 (comment).
Urgency
High
Are you going to implement the feature request?
Someone else needs to implement the feature
Do you need maintainer feedback?
Maintainer feedback requested
Anything else?
The current servicing architecture is becoming increasingly difficult to maintain, apply and observe. DB-aware DBX servicing could provide a scalable path while preserving strong protection.
Feature Overview
The current Microsoft Secure Boot DBX servicing model uses a single global baseline (
dbxupdate.bin) containing hundreds of revocation hashes across multiple signing authorities, for AMD64 / X64 the following:This global baseline model does not account for the signing authorities actually present in each device’s DB, creating two major issues:
Major security gaps: The latest
%SystemRoot%\System32\SecureBootUpdates\dbxupdate.binfile drops 154 hashes attributed to BlackLotus, marked asisOptionalin the global baseline json dbx_info_msft_latest.json. These revocations are the most critical and need to be enforced when PCA 2011 is still present in DB, as well as all other hashes for all other signing authorities present. TheisOptionalis not officially documented and remains issue of ongoing debates about dropped Canonical entries (#446).NVRAM inefficiency: Modern platforms may no longer rely on the 2011 legacy certificate authorities. However, these systems receive and store redundant revocation entries from the global DBX baseline. This consumes limited UEFI NVRAM storage, and contributes to Secure Boot variable update failures, even on officially Windows 11-compatible ThinkPads.
Summary: A global
dbxupdate.bincannot optimize for per-device trust state. DB-aware DBX servicing is required to make revocation enforcement secure and NVRAM-efficient.Solution Overview
Implement modular DBX payloads (for each CPU architecture) with DB-aware servicing.
DBXUpdate-Core.bin— universal revocations for all Windows machinesDBXUpdate-PCA2011.bin— revocations only required if Microsoft Windows Production PCA 2011 in DBDBXUpdate-UEFICA2011.bin— revocations only required if Microsoft Corporation UEFI CA 2011 in DBBefore applying latest DBX updates, Windows should check DB (
Get-SecureBootUEFI DB -Decoded) and download and apply only the bin-files applicable for the specific device DB.Modern systems that have migrated away from Microsoft Windows Production PCA 2011 no longer need its associated revocation hashes (173 entries for AMD64). Meanwhile, Microsoft Corporation UEFI CA 2011 remains relevant for many platforms, including dGPU systems such as NVIDIA RTX 50-series, despite being expired (241 entries for AMD64). Windows UEFI CA 2023-only notebooks do not need any of these 414 revocations associated with 2011 certs.
Summary: Modular DBX payloads ensure strong security enforcement while reducing NVRAM usage, simplifying servicing, and minimizing unnecessary update distribution and application.
Microsoft will need to maintain a matrix of 12 BIN files, and the dbx_info_msft_latest.json should reflect that.
Individual devices will only require one, up to three BIN files.
Alternatives Considered
The existing monolithic
dbxupdate.binapproach cannot optimize for individual device trust states: security enforcement remains ambiguous, while unnecessary DBX entries continue to consume limited NVRAM storage. The still-undocumentedisOptionalflag has resulted in ongoing interpretation debates and does not provide a mechanism for per-device targeting, as discussed in #429 (comment) and #444 (comment).Urgency
High
Are you going to implement the feature request?
Someone else needs to implement the feature
Do you need maintainer feedback?
Maintainer feedback requested
Anything else?
The current servicing architecture is becoming increasingly difficult to maintain, apply and observe. DB-aware DBX servicing could provide a scalable path while preserving strong protection.