Deployment Solution 8.x and GSS 3.3.x – Microsoft Secure Boot Changes and BlackLotus Vulnerability (CVE-2023-24932)
search cancel

Deployment Solution 8.x and GSS 3.3.x – Microsoft Secure Boot Changes and BlackLotus Vulnerability (CVE-2023-24932)

book

Article ID: 267298

calendar_today

Updated On:

Products

IT Management Suite Ghost Solution Suite Deployment Solution

Issue/Introduction

After applying and enabling the CVE-2023-24932 (BlackLotus) fix via Microsoft KB5025885, machines may fail to boot into WinPE preboot environments or fail to load after Ghost imaging when Secure Boot is enabled.

A related symptom has also been observed when capturing a Windows 11 25H2 image on one platform (e.g., Hyper-V) and deploying it to physical hardware or a different hypervisor with Secure Boot enabled. The machine displays a message such as "All bootable devices failed secure boot verification". Disabling Secure Boot allows the system to boot normally. This issue is typically caused by a Secure Boot certificate mismatch between the image source and target platforms, and is not a defect in Ghost Solution Suite or Deployment Solution.

Note

The Secure Boot changes introduced by CVE-2023-24932 are part of a broader Microsoft initiative to retire the Microsoft Windows Production PCA 2011 signing certificate and transition to the Windows UEFI CA 2023 certificate. Updating PCA 2023 certificates and the new boot manager are prerequisites for full BlackLotus mitigation.

Environment

Deployment Solution 8.7.x, 8.8.x

Ghost Solution Suite 3.3.x

Devices with UEFI firmware and Secure Boot enabled

Cause

Enabling the Secure Boot changes in KB5025885 revokes the trust in the old Microsoft Windows Production PCA 2011 certificate and requires the new Windows UEFI CA 2023 certificate. This causes previously created WinPE preboots and Ghost images — signed with the old certificate — to fail Secure Boot verification.

The Secure Boot signature database (DB) on the target machine must contain the Windows UEFI CA 2023 certificate. If the image was captured from a machine with the 2023 certificate and is deployed to hardware or a VM that still uses the 2011 certificate (or vice versa), a mismatch occurs and the machine will refuse to boot with Secure Boot enabled.

The full three-phase update sequence described in Microsoft's enterprise deployment guidance for CVE-2023-24932 must be completed for BlackLotus mitigation. Each phase must be applied in order: updating the Secure Boot DB, revoking the old certificate via DBX, and updating the boot manager.

Diagnosis – Checking Certificate Status

Before remediating, verify the Secure Boot certificate status on both the image source and target machines by running the following PowerShell commands as Administrator. Compare the results between the two machines.

# Check for Windows UEFI CA 2023 in the DB (Allowed List)

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'


# Check for Microsoft Windows Production PCA 2011 in the DB

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Windows Production PCA 2011'


# Check if PCA 2011 has been revoked in the DBX (Denied List)

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'


# Check for Microsoft Corporation KEK 2K CA 2023 in the KEK

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'


# Check for Microsoft UEFI CA 2011 (3rd-party certificate - required for current PXE / iPXE boot)

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft UEFI CA 2011'


# Check for Microsoft UEFI CA 2023 (3rd-party certificate - required for future PXE / iPXE boot)

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft UEFI CA 2023'

Interpret results as follows:

  • Windows UEFI CA 2023 returns True on source but False on target: The image source has the 2023 certificate but the target does not. Update the target machine’s UEFI firmware or manually update the Secure Boot DB.
  • PCA 2011 is in the DBX on source but not on target: The revocation has been applied on the source but not the target. The target machine needs to complete the Microsoft Secure Boot update sequence.
  • KEK 2K CA 2023 is missing: Windows Update cannot apply Secure Boot DB/DBX updates. The KEK must be updated first — this is often hardware/firmware-dependent (see resolution steps below).
  • Both Microsoft UEFI CA 2011 and Microsoft UEFI CA 2023 return False for PXE environments: If neither the 'Microsoft UEFI CA 2011' nor the 'Microsoft UEFI CA 2023' certificate is present in the DB (Allowed List) and PXE boot is required, check the BIOS/UEFI firmware settings for an option named similarly to "Enable Microsoft UEFI CA" under the Secure Boot configuration and ensure it is enabled. Note: Microsoft UEFI CA 2011 is required for currently available PXE and iPXE implementations. Microsoft UEFI CA 2023 will be required by future versions of PXE and iPXE.

Closed Network Warning

Installing the latest Windows Cumulative Update is not sufficient to update the Secure Boot certificate database when updates are managed through a disconnected/closed network.

Verify the actual DB state using the PowerShell commands above rather than assuming patch compliance equals certificate compliance.

For a comprehensive verification of the overall Secure Boot state of a device, Microsoft provides an official Secure Boot Inventory Data Collection Script that can be used to assess readiness and confirm successful remediation.

Resolution

Table of Contents

Important:
The information provided below is intended as general guidance only and does not cover all possible scenarios related to CVE-2023-24932 (BlackLotus) mitigation. It should not be interpreted as step-by-step instructions, and Broadcom Support does not provide detailed implementation guidance for Windows Secure Boot certificate expiration or related updates.

This behavior is expected and results from Microsoft Secure Boot enforcement changes. It is not a defect in Deployment Solution, Ghost Solution Suite, or IT Management Suite.

Regarding questions about the following Microsoft article:
https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e

This is a general Windows Update article addressing the broader 2026 certificate expiration timeline. It is outside the scope of this KB, which focuses specifically on DS/GSS/ITMS deployment workflows, and does not provide additional actionable guidance beyond what is already covered in the CVE-2023-24932 references.

Suggestions

Remediation involves multiple components. Complete all applicable steps for your environment.

Step 1 – Update UEFI Firmware (BIOS) on Target Hardware

BIOS updates released by major OEMs in 2023 and later typically include the Windows UEFI CA 2023 certificate in the Secure Boot DB and KEK. Updating to the minimum required BIOS version is the recommended first step, as it resolves Secure Boot certificate issues without manual intervention.

  • Dell: Refer to the Dell minimum BIOS version list for Secure Boot 2023 compatibility.
  • HP: Refer to the HP affected platforms and minimum BIOS version list. For HP devices, you can check readiness using: (Get-CimInstance -ClassName Win32_ComputerSystemProduct).Version — if the output contains SBKPFV3, the device already has the required BIOS update.
  • Lenovo: Refer to the Lenovo Commercial PCs Secure Boot Certificate guidance.

If ITMS/Altiris is used, custom inventory and reports can be created to assess BIOS compliance across HP and Dell device fleets. See the epm-blog.com ITMS BlackLotus remediation guide (Part 1 – Reporting) for SQL query examples and report templates.

Step 2 – Manually Update Secure Boot Certificates (If BIOS Update is Insufficient)

If a BIOS update does not include the new Secure Boot certificates, follow Microsoft’s manual update process described in Microsoft KB5025885 – How to manage Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932. The update sequence must be applied in the correct order:

  1. Apply the Secure Boot DB update (adds Windows UEFI CA 2023 to the allowed list).
  2. Apply the DBX update (revokes trust in the old PCA 2011 boot manager).
  3. Update the boot manager to one signed with the Windows UEFI CA 2023 certificate.

For monitoring and reporting the Secure Boot servicing status via ITMS, a PowerShell script and Custom Inventory approach are described in the epm-blog.com ITMS BlackLotus remediation guide (Part 2). The script reads registry keys under HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing to determine whether the 2023 certificate is present, whether the system is booting with the 2023-signed boot manager, and maps error event IDs to human-readable messages for centralized compliance reporting.

Step 3 – Update WinPE Preboot Images

After completing the Secure Boot certificate updates, all WinPE-based preboot environments (PXE, Automation Folders, ISOs, USB boot sticks) must be rebuilt using updated bootloaders. Existing preboots signed with the old PCA 2011 certificate will fail to load on machines where the revocation has been applied.

DS 8.8.1 / GSS 3.3.13 and Later

  • The latest DS 8.8.1 / GSS 3.3.13 releases extract updated bootloaders by default during ADK import.
  • If ADK was not re-imported after upgrading to DS 8.8.1 / GSS 3.3.13, re-import the ADK to pick up the updated bootloaders. Simply upgrading DS/GSS without re-importing ADK is not sufficient.
  • pxefixup.bat in DS 8.8.0 / DS 8.8.1 / GSS 3.3.13 has an optional setting to force the use of 'UEFI CA 2023' or 'UEFI CA 2011' certificate-signed binaries (if the WIM file contains both). This setting applies to PXE images only.


WinPE 11 24H2 and Later – Manual Bootloader Replacement

WinPE 11 24H2 contains the updated bootloaders and does not require the LCU to be applied manually. Only the EFI bootloader binaries need to be replaced — the winpe.wim file does not need to be updated for 24H2 and later.

The bootloader and efisys files must be copied from their source locations to the DS/GSS deployment directories. Note that the EFI bootloader sources come from the mounted boot.wim, while the efisys files come directly from the ADK installation.

x64 File Mapping (Deployment Solution)

Source

Destination (DS)

<mounted_boot_wim_x64>\Windows\Boot\EFI_EX\bootmgfw_EX.efi

\Deployment\BDC\waik_winpe11\Tools\PETools\amd64\efi\boot\bootx64.efi

<mounted_boot_wim_x64>\Windows\Boot\EFI_EX\bootmgr_EX.efi

\Deployment\BDC\waik_winpe11\Tools\PETools\amd64\bootmgr.efi

C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\Oscdimg\efisys_EX.bin

\Deployment\BDC\waik_winpe11\Tools\PETools\amd64\boot\efisys.bin

C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\Oscdimg\efisys_noprompt_EX.bin

\Deployment\BDC\waik_winpe11\Tools\PETools\amd64\boot\efisys_noprompt_EX.bin

ARM64 File Mapping (Deployment Solution)

Source

Destination (DS)

<mounted_boot_wim_arm64>\Windows\Boot\EFI_EX\bootmgfw_EX.efi

\Deployment\BDC\waik_winpe11\Tools\PETools\arm64\efi\boot\bootaa64.efi

<mounted_boot_wim_arm64>\Windows\Boot\EFI_EX\bootmgr_EX.efi

\Deployment\BDC\waik_winpe11\Tools\PETools\arm64\bootmgr.efi

C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\arm64\Oscdimg\efisys_EX.bin

\Deployment\BDC\waik_winpe11\Tools\PETools\arm64\boot\efisys.bin

C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\arm64\Oscdimg\efisys_noprompt_EX.bin

\Deployment\BDC\waik_winpe11\Tools\PETools\arm64\boot\efisys_noprompt_EX.bin

 

GSS Path Note

The above paths apply to Deployment Solution. For Ghost Solution Suite, replace \Deployment\BDC\ with \eXpress\Deployment Server\ in all destination paths.

 

Source Note

<mounted_boot_wim_x64> and <mounted_boot_wim_arm64> refer to the mount point of the respective WinPE boot.wim file. The efisys_EX.bin and efisys_noprompt_EX.bin files are sourced directly from the ADK installation directory, not from the WIM.

 

WinPE Versions Prior to 24H2

WinPE versions prior to 24H2 do not contain the updated bootloaders. The Latest Cumulative Update (LCU) must be applied manually using DISM to offline-service the boot.wim. After applying the LCU, the winpe.wim file must also be replaced in addition to the EFI bootloader files.

After applying the LCU, replace the winpe.wim in the DS or GSS deployment directory with the updated version:

  • Deployment Solution (x64):  \Deployment\BDC\waik_winpe11\Tools\PETools\amd64\winpe.wim
  • Ghost Solution Suite (x64):  \eXpress\Deployment Server\waik_winpe11\Tools\PETools\amd64\winpe.wim

Step 4 – Recapture Ghost Images

Existing Ghost images (both Sysprepped and Backup images) captured before the Secure Boot certificate update are no longer usable on machines where the updated Secure Boot DB and revoked PCA 2011 certificate are in effect. New images must be captured after the update has been applied to the source machine.

  • Delete all existing Ghost images, OS packages, and Preboot environments that were created before the bootloader update was applied.
  • Capture new images from source machines that have the updated bootloaders and completed Secure Boot certificate update sequence.

Important

If a customer had previously followed this KB when Microsoft first released the fix (updating bootloaders without also changing the certificate), all Ghost images, OS packages, and Preboots must be deleted and recreated again.

 

Recovery Option: Post-Imaging Script for Existing Images

If a Ghost image contains the required LCU but the bootloaders were not updated before image capture, a custom post-imaging script can be used to copy the updated EFI files from the deployed Windows volume to the EFI System Partition (ESP). This avoids a full image recapture:

REM Copy updated bootloaders from the Windows volume to the EFI System Partition (ESP)


copy "<Windows_Disk>:\Windows\Boot\EFI_EX\bootmgfw_EX.efi" "<ESP>:\EFI\Boot\bootx64.efi"

copy "<Windows_Disk>:\Windows\Boot\EFI_EX\bootmgfw_EX.efi" "<ESP>:\EFI\Microsoft\Boot\bootmgfw.efi"

copy "<Windows_Disk>:\Windows\Boot\EFI_EX\bootmgr_EX.efi"    "<ESP>:\EFI\Microsoft\Boot\bootmgr.efi"


Step 5 – Update OS Packages (Scripted OS Install)

SOI packages must be updated or replaced to use an ISO in which the Secure Boot update from KB5025885 has been applied.

  • Ghost Solution Suite: Copy the new updated ISO file content into the SOI package location on the GSS eXpress share.
  • Deployment Solution: Find the path in SMP Server under Scripted Install Files > Package Location, then copy over files from the new updated ISO. This preserves the existing SOI package GUID and avoids breaking existing jobs.
  • After copying new content, select Update Distribution Points and run the NS.Package Refresh task to distribute the updated package to all Package Servers.

 

DS 8.7.2 – Edit / Delete SOI Packages

Deployment Solution 8.7.2 introduced Edit and Delete options for existing SOI packages in Settings > Deployment > OS Files:

  • Edit – Replaces the OS package source files while preserving all existing 'Install Windows OS' task associations. This is the recommended approach when refreshing SOI packages with updated ISO content for the CA 2023 change, as it avoids the need to update any existing tasks.
  • Delete – Allows removing an existing SOI package so it can be cleanly re-imported with the correct OS edition and updated source files.

Additional Guidance for VMware / Virtual Machine Environments

For VMware ESXi environments, Secure Boot certificate update failures present additional complexity due to how virtual machines manage Secure Boot variables (PK, KEK, DB, DBX). Refer to the following Broadcom KBs for VMware-specific remediation:

Key points for VM environments:

  • VMs continue to boot even after certificate expiry; boot will only be impacted when Microsoft revokes the expired certificates.
  • For ESXi versions earlier than 8.2, only the Windows KEK CA 2011 is present by default, preventing Windows Update from updating the DB or DBX variables.
  • For ESXi 8.2 and later, the 2023 certificate is present, allowing DB and DBX updates through Windows Update.
  • For ESXi versions earlier than 9.0, a valid Platform Key (PK) is not present by default, preventing KEK updates. Manual intervention using SetupMode or allowAuthBypass is required.

Also see After image deployment, the computer won't boot to Windows with Secure Boot enabled (KB419052) for guidance specific to the image capture/deploy certificate mismatch scenario.

Workaround (Temporary)

Warning

Temporarily disabling Secure Boot allows existing Ghost images to be used but exposes the risks posed by the BlackLotus vulnerability. Only consider this option if a specific backup image of the machine exists and creating a new backup image is not feasible. Re-enable Secure Boot as soon as updated images are available.

 

Additional Information

Microsoft – Primary Guidance:

ITMS / GSS / DS Specific:

VMware / vSphere:

Hardware Vendor Guidance:

Powered by Wolken Software