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.

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)