Secure Boot, UEFI and the BlackLotus mitigations

Everything Windows does to protect itself, from BitLocker to Credential Guard, assumes the code that ran before Windows was trustworthy. Secure Boot enforces that assumption: UEFI firmware only runs boot components signed by keys in its signature database. Bootkits such as BlackLotus showed that "Secure Boot is on" is not the same as "the boot chain is safe", and the Microsoft certificates that anchor the whole system are now being replaced.

The BitLocker hardening pillar checks that Secure Boot is on. This guide goes deeper: the key databases, the CVE-2023-24932 mitigations, the 2023 certificate transition and firmware hardening. It is part of the BitLocker & Boot Security series.

How Secure Boot decides what runs

The firmware runs a boot component only if its signature chains to DB and it is not in DBX. Windows boot managers have been signed by Microsoft Windows Production PCA 2011; Linux shims and many option ROMs chain to Microsoft Corporation UEFI CA 2011; Microsoft's DB and DBX updates are signed with Microsoft Corporation KEK CA 2011.

Why BlackLotus changed the rules

BlackLotus (CVE-2022-21894, followed by CVE-2023-24932) abuses a boot manager that is old but validly signed by the PCA 2011 certificate. Secure Boot happily runs it, and the attacker uses its vulnerability to disable protections and load an unsigned bootkit that persists below the operating system, even with BitLocker in use.

Patching Windows replaces the boot manager on the EFI system partition, but an attacker with admin rights can copy the old vulnerable one back. The only durable fix is to distrust the PCA 2011 certificate in DBX, which in turn requires every device to first boot a boot manager signed by the new Windows UEFI CA 2023. That ordering, plus the risk of bricking boot media, is why Microsoft made the mitigations opt-in and staged.

Step 1: inventory the current state

On each device:

Confirm-SecureBootUEFI                         # True = enabled; error = legacy BIOS/CSM boot
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).Bytes) -match 'Windows UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name KEK).Bytes) -match 'KEK 2K CA 2023'

Collect these with a compliance script, together with the model and firmware version (Get-CimInstance Win32_ComputerSystem, Get-CimInstance Win32_BIOS). Devices still booting in legacy BIOS or CSM mode need conversion first: mbr2gpt.exe /validate /allowFullOS then /convert, followed by switching the firmware to UEFI-only and enabling Secure Boot.

Intune compliance policies can require Secure Boot through Device Health > Require Secure Boot to be enabled on the device, which relies on attestation of the measured boot log rather than a script result.

Step 2: apply the CVE-2023-24932 mitigations

Microsoft documents the full procedure in KB5025885 ("How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932"). Read the current version before starting; the enforcement timeline has moved several times. The mechanism is a registry value that tells Windows which Secure Boot servicing steps to perform at the next restarts:

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Secureboot
Value: AvailableUpdates  (REG_DWORD)

At the time of writing, the documented steps are:

Windows clears each bit once it has been processed; the servicing task runs every 12 hours and some steps need one or two restarts. Do steps 1 and 2 first, broadly. Only move to steps 3 and 4 when all boot media that might boot the device has been updated (Step 4 below), because after revocation anything signed only with PCA 2011 stops booting. Failures appear as events from the same source: 1795 (the firmware returned an error, typically fixed by an OEM firmware update), 1796 (unexpected error, with the error code) and 1801 (the new certificates have not yet been applied to firmware). Event 1808 confirms that a device has all the required new certificates.

Step 3: move to the 2023 certificates

The 2011 certificates expire in 2026: the KEK and third-party UEFI CA in June, the Windows Production PCA in October. Expiry does not stop devices from booting, but it ends their ability to receive new Secure Boot DB/DBX updates and new boot managers signed under the old chain.

The target state for every device:

• KEK: Microsoft Corporation KEK 2K CA 2023
• DB: Windows UEFI CA 2023, plus Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 where third-party code is trusted
• Boot manager: signed by Windows UEFI CA 2023

Microsoft rolls these updates out through Windows servicing and documents several ways to deploy them deliberately:

• Registry: AvailableUpdates = 0x5944 under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot deploys all needed certificates and the 2023-signed boot manager. Progress is reported under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\Servicing: UEFICA2023Status moves from NotStarted to InProgress to Updated, and UEFICA2023Error is non-zero on failure. MicrosoftUpdateManagedOptIn = 1 under the Secureboot key opts the device into Microsoft's controlled feature rollout instead.
• Group Policy: Computer Configuration > Administrative Templates > Windows Components > Secure Boot, including Enable Secure Boot Certificate Deployment.
• Intune settings catalog: Enable Secureboot Certificate Updates, Configure Microsoft Update Managed Opt In and Configure High Confidence Opt-Out.

The policy options require recent cumulative updates, so check Microsoft's current Secure Boot certificate update guidance for the minimum build on each Windows version.

KEK updates must be signed by the OEM's Platform Key, so some models need a firmware update before Windows can apply them. Track progress per model, not just per device.

Step 4: update boot media and recovery paths

Before any revocation:

• WinPE and PXE: rebuild Configuration Manager and WDS boot images from current Windows ADK media so they carry the 2023-signed boot manager.
• Installation and recovery USB drives: recreate them from current media. Microsoft publishes guidance and tooling for updating bootable media.
• Windows Recovery Environment on each device: confirm that WinRE has been serviced along with the OS.
• Virtual machines: Hyper-V Generation 2 VMs, VMware and cloud VMs have their own virtual firmware and template keys. Check your hypervisor vendor's guidance for KEK and DB updates, and use the Microsoft Windows Secure Boot template for Windows guests on Hyper-V.

Step 5: harden the firmware itself

Secure Boot can be switched off in firmware setup by anyone with physical access unless the firmware is locked:

Apply these with OEM tooling (the major vendors all provide command-line BIOS configuration utilities) or, on supported hardware registered with Windows Autopilot, with Intune Device Firmware Configuration Interface (DFCI) profiles, which can also lock firmware settings against local change. Keep firmware updated through Windows Update or the OEM channel: many Secure Boot fixes arrive as firmware updates.

What breaks

• Old boot media stops working after the DBX revocation: USB sticks in the helpdesk drawer, PXE images, third-party backup recovery media.
• Firmware bugs: some models reject DB, KEK or DBX updates, or fail to boot after them. Pilot every model.
• Dual-boot and Linux systems depend on the third-party UEFI CA; disabling it or revoking shims affects them.
• BitLocker recovery prompts on devices without PCR 7 binding. Confirm escrow first with the recovery key guide, and suspend BitLocker for one reboot (Suspend-BitLocker -MountPoint C: -RebootCount 1) around firmware updates.
• Option ROMs of add-in GPUs and storage controllers may need the third-party CA.

Verify it

• Confirm-SecureBootUEFI returns True on every device.
• DB contains Windows UEFI CA 2023, KEK contains Microsoft Corporation KEK 2K CA 2023 (commands in Step 1).
• System log shows the confirmation events for each step you applied (1808 once all certificates are in place), UEFICA2023Status reads Updated, and AvailableUpdates no longer contains the bits you set (a remaining 0x4000 is expected after 0x5944).
• On revoked devices, an old PCA 2011-signed boot medium fails to boot with a Secure Boot violation. Test this once per model in the lab, not in production.
• Intune compliance reports Secure Boot as healthy; measured boot logs under C:\Windows\Logs\MeasuredBoot are present for attestation.

Checklist

• All devices boot in UEFI mode with Secure Boot enabled in standard mode
• Inventory of DB, KEK and boot manager state per device and per model
• Windows UEFI CA 2023 in DB and 2023-signed boot manager installed everywhere
• 2023 KEK deployed; models needing firmware updates identified and patched
• Boot media, PXE images, WinRE and VM templates updated
• PCA 2011 revocation and SVN update applied, ring by ring, after media updates
• Firmware password set, legacy boot and external boot disabled, settings locked

A trustworthy boot chain is the foundation for Credential Guard and memory integrity. Check the Secure Boot glossary entry for a shorter definition to share with non-specialists.