BlackLotus Isn't Fixed When the Certificate Updates: Tracking All Four Secure Boot Mitigations

Your Secure Boot report shows the 2023 certificate installed. Ticket closed, right? Not quite. CVE-2023-24932 - the BlackLotus bootkit vulnerability - isn't fixed by one certificate update. It needs four separate mitigations to land, in order, and a device that's only completed the first one is still exploitable by the exact attack this CVE describes. This post covers what all four mitigations actually are, why tracking "certificate installed" alone gives you a false sense of security, and how to track real fleet-wide progress through all four - including a ConfigMgr hardware inventory technique for hybrid environments that Intune's own Secure Boot report doesn't give you.

The problem: "certificate installed" is one of four steps, not the fix

Two Secure Boot certificate authorities are retiring: Microsoft Corporation UEFI CA 2011 and Microsoft Corporation KEK CA 2011 expire starting June 2026, and Microsoft Windows Production PCA 2011 expires from October 2026. Their replacements - Windows UEFI CA 2023 and Microsoft Corporation KEK 2K CA 2023 - are what most "Secure Boot Status" reports in Intune and ConfigMgr actually check for.

But installing the 2023 certificate only completes mitigation one of four. A device can show a shiny new certificate in its trust database and still boot on a boot manager that CVE-2023-24932 can exploit, because the vulnerable 2011 boot manager hasn't actually been revoked yet. That revocation is mitigation three, and it doesn't happen automatically just because mitigation one did.

Why it happens: four mitigations, applied in strict order, tracked by one bitmask

Microsoft's remediation for CVE-2023-24932 is staged deliberately, because doing it out of order can break boot on some hardware. The four mitigations are:

1. Install the 2023 CA certificate into the firmware's trusted signature database (DB) - lets the device trust boot components signed by the new authority, without yet removing trust in the old one.
2. Update the boot manager to a 2023-signed version - the device now actually boots using the new, non-vulnerable boot manager.
3. Revoke the 2011 boot manager via the forbidden signature database (DBX) - this is the step that actually closes CVE-2023-24932, by making the old vulnerable boot manager un-bootable even if an attacker tries to restore it.
4. Enforce the Secure Version Number (SVN) - a firmware-level anti-rollback counter that stops an even-older signed boot manager from being reintroduced later.

All four are tracked through a single registry value: AvailableUpdates under HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot. Each mitigation has its own bit - 0x40 for the CA certificate, 0x100 for the boot manager update, 0x80 for the DBX revocation, and 0x200 for SVN enforcement. A scheduled task, \Microsoft\Windows\PI\Secure-Boot-Update, checks this value roughly every 12 hours and clears each bit as its mitigation completes - reboots are required between stages, which is why this can take several maintenance windows to finish on a single device, let alone a fleet.

How to verify: check the registry bit AND the real firmware, not just one

The registry value tells you what Windows thinks is still pending - but it doesn't always match what's actually in the firmware. The safer approach checks both, using the certificate-authority PowerShell cmdlets directly against the UEFI trust databases:

Run this on a real device and you can genuinely see mitigations disagree with each other - which is exactly the trap a certificate-only check falls into:

Read that the way it's meant to be read: this device's certificate and boot manager are both already updated - a certificate-only Secure Boot report would show it as fully protected. But the 2011 boot manager still hasn't been revoked, and SVN enforcement hasn't landed either. That gap is exactly where CVE-2023-24932 still applies, and no cert-only dashboard would catch it.

The fix: control the rollout, then track all four stages centrally

Context: most environments should let this apply automatically - Microsoft manages the rollout by default. The two registry values below exist for the minority of cases where you need manual control (staged pilot groups, hardware compatibility testing before broad rollout).

Controlling rollout via registry (Intune custom profile or GPO Registry preference)

There is no dedicated Settings Catalog toggle or ADMX template for this specific opt-out - both values are plain registry settings under the same key, deployed as a custom OMA-URI profile in Intune or a Registry preference item in Group Policy:

To deploy via Intune as a custom Settings Catalog profile:

1. Sign in to intune.microsoft.com.
2. Go to Devices › Configuration › Create › New policy, choose Windows 10 and later › Settings catalog.
3. Add settings and search for Registry under the CSP list, or use a custom OMA-URI profile targeting ./Vendor/MSFT/Registry/HKLM/SYSTEM/CurrentControlSet/Control/Secureboot/MicrosoftUpdateManagedOptIn with an Integer value of 0.
4. Assign to your pilot ring only - leave broad devices on Microsoft's default managed rollout.

Tracking all four stages in ConfigMgr (the gap Intune's report doesn't cover)

Intune's Secure Boot Status report is genuinely useful for Intune-managed devices, but it doesn't exist for a co-managed or ConfigMgr-primary fleet, and it only reports certificate state, not all four mitigations. SystemCenterDudes documented a genuinely useful pattern for this: extend ConfigMgr's own hardware inventory to collect the AvailableUpdates registry value directly, so you get all four mitigations tracked centrally alongside every other device attribute you already collect.

The mechanism, using ConfigMgr current branch's real hardware inventory extension process (not the legacy sms_def.mof editing from older versions):

1. On the top-level site server, edit Configuration.mof (found under Inboxes\clifiles.src\hinv\ in the ConfigMgr install directory) to add a custom class definition that reads the AvailableUpdates REG_DWORD from the Secure Boot registry key. Add your custom class under the "Added extensions" section at the bottom of the file - never edit anything above it, since a site update can overwrite the reserved sections.
2. Review dataldr.log on the site server to confirm the site accepted the new class.
3. In the ConfigMgr console, go to Administration › Client Settings › Default Client Settings › Hardware Inventory › Set Classes, and either Add the new class directly from a client's WMI namespace, or Import a MOF file containing it.
4. Enable the class for collection, then refresh policy on a test client and confirm the new class compiles (check InventoryAgent.log on the client).
5. Once inventory runs, query the new class in Resource Explorer, or build a collection query against it to find every device still missing a specific mitigation bit.

Why patching alone doesn't stop BitLocker bypasses

The urgency here isn't theoretical. As long as a device's firmware still trusts the 2011 boot manager, it's vulnerable to more than just BlackLotus - the same underlying trust gap has been exploited by two separate, real, documented attacks against BitLocker itself:

• Bitpixie (CVE-2023-21563) - a flaw where the BitLocker Volume Master Key isn't cleared from memory during a PXE soft reboot. An attacker with physical access manipulates Boot Configuration Data to redirect the boot process to an attacker-controlled TFTP server, extracts the key from memory, and bypasses BitLocker in under five minutes - on a fully patched, fully up-to-date device. This bug existed in the Windows bootloader since 2005 and was only fixed via the same KB5025885 revocation process this post covers.
• BitUnlocker (CVE-2025-48804) - a logic error in the boot manager's certificate validation that lets an attacker craft a specially formatted EFI executable, forcing the boot manager to load it instead of the real Windows Recovery Environment. This chains a boot manager downgrade with a manipulated WinRE to silently decrypt BitLocker-protected drives - again in under five minutes, again requiring only physical access. Microsoft fixed this in the July 2025 Patch Tuesday release.

Recovery when a device won't boot

Despite testing on representative hardware first, a DBX revocation can still leave a device unable to boot - most commonly when a piece of pre-2023-signed software (a driver, an OEM recovery partition, custom boot media) gets caught by the revocation. If that happens, the standard recovery path is:

1. Enter the UEFI firmware setup menu and temporarily disable Secure Boot.
2. Boot into the OS, then mount the EFI system partition to a drive letter: mountvol s: /s
3. Reconstruct the boot files fresh: bcdboot %systemroot% /s S:
4. Re-enable Secure Boot in firmware and confirm the device boots normally.

Recovery success is highly dependent on OEM firmware capability - which is exactly the supply-chain risk covered next.

PKfail and OEM supply-chain risk

Separately from BlackLotus, PKfail (CVE-2024-8105), discovered by Binarly's research team in mid-2024, revealed that hundreds of device models from major vendors - Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo, Phoenix, and Supermicro among them - shipped with an insecure, publicly-known test Platform Key. This key, generated by AMI and explicitly marked "DO NOT TRUST" in its own metadata, was meant to be replaced by each vendor with their own securely generated key before shipping. Roughly 9% of tested firmware images never made that swap.

Because the Platform Key is the absolute root of trust for Secure Boot, a device using this known, public key has no real Secure Boot protection at all - anyone can sign a malicious bootloader that the firmware will trust, making BlackLotus-style attacks trivial rather than merely possible.

The VMware NULL Platform Key problem

Virtualized fleets hit a distinct, well-documented obstacle. On VMs created on ESXi versions earlier than 9.0 (or VM Hardware Version 13 on any ESXi version, or Hardware Version 14+ on ESXi earlier than 8.0 U2), the Platform Key in the virtual NVRAM is a NULL signature by default - a design choice from earlier ESXi versions, not a bug introduced by this rollout. A NULL PK means no authority exists to authorize KEK changes, so when the Windows Secure-Boot-Update task tries to inject the 2023 KEK, the virtual firmware rejects it and mitigation 1 never completes.

Broadcom's own knowledge base (KB 423893) documents the real symptoms - Windows Event Viewer shows Event 1801 ("updated certificates are available but have not yet been applied to the firmware") and Event 1769 ("failed to update KEK 2023 with error invalid access to memory location"), often alongside "Missing Microsoft Corporation KEK 2K CA 2023" in the VM's Secure Boot KEK database.

Broadcom documents three remediation paths, current as of their published guidance:

1. Silent PK update (ESXi 8.0 U3j P09 or later) - schedule a VM reboot; for vTPM-disabled machines the system applies the Windows OEM Devices PK certificate automatically on restart.
2. VMX configuration method (ESXi 8.0 U3j P09+ and 9.x) - power off the VM, add the advanced setting uefi.secureBoot.PK.resetOnce = "TRUE", then power back on.
3. Manual vUEFI interface update (ESXi 7.x, 8.x, 9.x) - direct firmware-level certificate installation, documented separately in Broadcom KB 423919.

The Linux dual-boot collision

Windows and Linux revoke vulnerable boot components differently. Linux uses Secure Boot Advanced Targeting (SBAT) - a generational counter that revokes specific vulnerable GRUB/shim versions without consuming the DBX's limited storage. Windows has no equivalent mechanism; every BlackLotus mitigation expands the DBX directly with specific hashes.

Most mainstream Linux distributions boot via a shim signed by the same Microsoft Corporation UEFI CA 2011 certificate this whole rollout eventually revokes. In a dual-boot environment, if a Windows-driven DBX update untrusts the 2011 CA before the Linux side has a 2023-signed shim in place, the Linux partition stops booting.

This isn't hypothetical - it already happened. In August 2024, a Windows update pushed an SBAT revocation intended to block a GRUB2 vulnerability (CVE-2022-2601). Microsoft's own dual-boot detection failed to recognise several customised dual-boot configurations, and the SBAT value was applied anyway - breaking boot on Ubuntu, Linux Mint, Zorin OS, Puppy Linux, and other distributions, with the error "Verifying shim SBAT data failed: Security Policy Violation." Microsoft didn't ship a corrected detection fix until KB5058405 in May 2025.

Registry keys behind the mitigation state

Everything in this post reads from or writes to one registry key:

Proof it worked: all four independently verified, not just the certificate

A device is genuinely protected against CVE-2023-24932 only when all four checks confirm true - the certificate, the boot manager, the DBX revocation, and SVN compliance - not when the Secure Boot report shows a green checkmark for the certificate alone. Re-running the verification script after the scheduled task completes another cycle should show each False above flip to True in turn, in the same order the mitigations apply - if mitigation 3 flips before mitigation 2, something has gone wrong with the sequencing and is worth investigating before trusting the device.

References

• Microsoft Support - KB5025885: Managing Secure Boot revocations for CVE-2023-24932
• MSRC - CVE-2023-24932 vulnerability details
• Microsoft Learn - Extend hardware inventory in Configuration Manager
• SystemCenterDudes - BlackLotus Remediation: Beyond the CA Certificate Expiration (the ConfigMgr custom hardware inventory technique referenced above is their documented approach)

Microsoft MVP community deep-dives

Beyond Microsoft's own documentation, these three MVPs have each independently dug into a specific piece of this rollout worth reading directly - verified and genuinely on-topic, not just name-dropped: