Introduction
In early 2026, diplomatic organizations operating in Central Asia saw their Windows workstations compromised by a sophisticated UEFI bootkit. The unsettling detail: every affected machine had received its Windows updates. Security bulletins had been applied, and compliance dashboards showed clean scores across the board.
The incident exposed a deeply ingrained confusion in many IT teams: patching a software vulnerability and activating the firmware protection tied to it are two distinct actions, and standard tooling only surfaces the first.
The Patch Applied, the Protection Missing
The story starts in 2022, when Microsoft released a fix for CVE-2022-21894, a vulnerability nicknamed "Baton Drop" that allowed attackers to bypass the Secure Boot mechanism. The update was pushed via Windows Update to millions of machines.
But Secure Boot depends on a complementary mechanism: the DBX (Forbidden Signature Database), stored in the UEFI firmware of each device. This blocklist holds the cryptographic fingerprints of boot components identified as vulnerable. To actually neutralize the flaw, the compromised component must be enrolled in that DBX, a separate firmware-level operation that does not happen automatically in a managed enterprise environment.
Microsoft did make this DBX update available, but never enforced it. It requires explicit deployment through fleet management tooling: Intune, MECM, or GPO scripts. Without clear guidance from Microsoft on this distinction, many teams concluded the CVE was closed once the Windows patch was applied. It wasn't, not at the firmware level.
What Standard IT Tools Don't See
This blind spot has a structural cause: fleet management solutions provide excellent visibility into Windows update status, but they don't cover, by default, the firmware state of individual machines, or the integrity of their DBX databases.
Two distinct protection layers coexist on every endpoint:
- The OS layer: Windows Update patches, auditable via WSUS, Intune, or MECM;
- The firmware/UEFI layer: boot certificates, DBX revocations, OEM keys, rarely included in compliance inventories.
This is not a theoretical concern. In June 2026, the KEK certificates Microsoft has used since 2011 reached their expiry date. In October of the same year, the certificate signing Windows boot components hit its own deadline. Critically, certificate expiry is not the same as revocation: the vulnerable components those certificates signed remain exploitable as long as they aren't explicitly listed in the DBX. Devices that have not migrated to the 2023 certificates will no longer be able to receive new DBX entries via Windows Update, permanently freezing their firmware protection level.
What IT Leaders Need to Rethink
Closing this gap requires a few targeted governance adjustments.
Broaden the definition of "up to date": a complete compliance inventory must include firmware state, UEFI version, KEK/DB/DBX certificate status, and the date of the last revocation list update. Specialized tools or native UEFI diagnostics make this audit achievable on most modern hardware.
Separate patching from revocation: fixing a CVE at the OS level does not automatically protect the boot process. Every Microsoft bulletin related to Secure Boot must be analyzed to determine whether a complementary firmware action is required, and that determination should be documented in validation workflows.
Bring firmware updates into patch management: OEM deployments must be treated with the same priority as Windows patches, with a precise sequencing, firmware first, then certificates, to avoid any risk of rendering machines unbootable.
The BlackX case illustrates a reality IT teams are only beginning to fully internalize: the governance surface of a Windows fleet now extends well below the operating system. Relying solely on patch management dashboards to certify that an endpoint is protected means managing only half the picture.