Update WinPE Boot Images with Windows UEFI CA Certificates [Part 2]

Secure Boot embeds into the Unified Extensible Firmware Interface (UEFI) and ensures that the system boots using only software trusted by the hardware vendor. As stated in this blogpost “Enable Secure Boot: Fix Secure Boot certificates expiration [Part 1]“. For 15 years, the Secure Boot certificates that are part of Windows systems will start expiring. Windows devices will need new certificates to maintain continuity and protection. These certificates are the basics of trust for the operating Systems (OS). In this guide, we shall be discussing the steps to “Update WinPE Boot Images with Windows UEFI CA Certificates”.

WinPE boot media relies on the same Secure Boot trust chain as full Windows. That trust is validated against the UEFI db (allowed certificates) and dbx (revoked certificates) stored in firmware. Please see how to protect Microsoft 365 beyond native limits with VDC [Part 1].

Microsoft recommends enabling automatic management of Windows Updates to ensure timely delivery of these updates. In addition, Microsoft is working closely with original equipment manufacturers (OEMs) to provide Secure Boot firmware updates. These updates are already available and can be managed through vendor-specific utilities or Windows Updates.

Also, see AGMP extended support ends April 2026: Find alternative solution, and “MBAM extended support ends April 2026: Find alternative solution“.

Why is this Secure Boot Update necessary?

Note: To ensure uninterrupted system bootability and the continued delivery of security updates. As recommended, we must transition to the 2023 Secure Boot certificates before the current ones expire. Failure to update the UEFI firmware will result in the Windows Boot Manager and WinPE losing trust in future security patches. Thereby, potentially blocking critical updates. We will therefore perform these updates to maintain a secure and reliable boot environment

The UEFI specification prevents unauthorized firmware, drivers, and operating systems from loading during the system boot process. Microsoft adopted Secure Boot with Windows 8 and now mandates it as a core security requirement for Windows operating systems.

When the system starts, the firmware verifies the digital signatures of pre-boot software (including the Windows Boot Manager) against a set of trusted Certificate Authorities (CAs) stored within the firmware. If the signatures are valid, the system boots, and the firmware hands control to the Windows boot loader. The loader then verifies requirements, loads into memory, and starts the operating system. This process ensures that bootkits, rootkits, or other low-level malware cannot load.

Consequently, we can safely say that Secure Boot provides the first line of defense for both system and Windows security.

Please see “What are the differences between Lite-Touch and Zero-Touch installation, Creating a WinPE USB Drive: Fixing System Boot Issues, and how to Fix EFI network timeout on VMware Workstation.

Establishing a Root of Trust: The Four Pillars of Secure Boot

Just in case you have not read the part 1 as referremced above. We will discuss how UEFI Secure Boot Uses PK, KEK, DB, and DBX to enforce Trust. During the boot process, the firmware verifies each component’s digital signature against these databases, blocking any untrusted software or tampered code before the operating system loads.

UEFI firmware enforces a hierarchy of keys to ensure the system starts in a trusted and verified state every time it powers on. Below are the keys used for Secure Boot:

• Platform Key (PK): Establishes system ownership, often times owned by the hardware manufacturer (OEM).
• Key Exchange Key (KEK): Authorizes updates to trust databases, and may include a Microsoft KEK and other OEM KEKs.
• Allowed Signature database (DB): Stores signatures of approved bootloaders and drivers.
• Forbidden Signature Database (DBX): Lists revoked or malicious signatures.

Please see how to configure screen saver timeout in Windows, What are the Differences between UEFI and BIOS, and how to set an account expiration date in Active Directory.

Secure Boot Certificate Transition

Accoording to this guide by Microsoft, administrators must manually initiate Secure Boot certificate updates on Windows Server systems because these systems do not receive the 2023 certificates through Controlled Feature Rollout. Admins are recommended to first install the latest cumulative updates and then update any servers that have Secure Boot enabled but do not yet include the 2023 certificates.

Since Microsoft introduced Secure Boot in Windows 8 and Windows Server 2012. All Windows-based devices have utilized the same CA 2011 certificates within the UEFI KEK and DB, which are now approaching their 2026 expiration as detailed in the transition table below.

Note: When these certificates expire, systems may initially continue to boot. But will stop receiving Secure Boot–related updates, fail to verify future Windows Boot Manager updates, reject older recovery and WinPE media, and fall out of compliance with enterprise security requirements.

Please see How to Enable or Disable Touch Screen in Windows 10, and how to “Migrate Microsoft Enterprise Root Certification Authority and Forest Domain to Azure“.

Dell and Lenovo BIOS Certificate Preparation Comparison

Before diving into the core of this topic, it is important to examine the two major hardware manufacturers (OEMs) and how they approach the Secure Boot transition.

If you manage a fleet of enterprise workstations or servers. There is a ticking clock you need to be aware of: “June 2026 as already mentioned above”. This is the date when the original Microsoft Secure Boot CA 2011 certificates expires. The very foundation of trust for UEFI systems since Windows 8.

Some top-tier vendors like Dell and Lenovo are already moving to prevent a “No-Boot” crisis. Here is everything you need to know about how these two giants on how they are handling the transition to the 2023 Secure Boot Certificates.

Note that this this transition is the final stage in mitigating CVE-2023-24932 (the BlackLotus bootkit vulnerability). By moving to the 2023 certificates, vendors are shrinking the attack surface and ensuring that revoked, vulnerable bootloaders can no longer be used to compromise the system.

Please see How to Enable and Disable WMI Traffic through Windows CMD, how to remove a user from a Slack Channel, and how to enable or disable a Remote WMI Connection in Windows.

Lenovo’s Approach: Proactive and Seamless

Lenovo has taken a highly proactive stance to ensure that IT administrators do not have to scramble with manual key enrollment.

• Integrated Firmware Updates: Lenovo has already begun releasing updated UEFI firmware across their entire product line. These updates silently “injecting” the 2023 certificates into the KEK and DB databases.
• Zero-Touch Transition: Their goal is to allow customers to transition without ever having to disable Secure Boot or manually touch the BIOS settings.
• Risk Mitigation: By updating the firmware now, Lenovo ensures that when Microsoft eventually pushes the “Revocation” updates via Windows Update. The hardware is already prepared to trust the new signatures.

Dell’s Approach: Precision and Life-Cycle Management

Dell’s strategy is equally robust but comes with specific caveats regarding the age of your hardware.

• The 2024 Rollout: Dell with the collaboration with Microsoft began rolling out BIOS updates that include the Microsoft 2023 Secure Boot certificates since 2024 and continues to release them across supported platforms in a phased manner.
  
  Dell recommends keeping systems updated. This way, the latest BIOS versions will include the updated Secure Boot certificates before the Microsoft 2011 certificates expire in 2026.
• The “Dual-Trust” Strategy: To prevent boot failures during the transition. Dell systems will support both the 2011 and 2023 certificates simultaneously for a period. This allows for a smoother “handover.”
• The EoSL Limitation: Unlike Lenovo’s broader approach, Dell has stated they generally will not provide BIOS updates for systems that reach End of Service Life (EoSL) before January 1, 2026. For these legacy systems, administrators may need to rely on OS-level certificate injection via PowerShell scripts or Windows Update. Please take note of this!

The appearance of the ‘Secure Boot Allowed Key Exchange Key (KEK) Update’ in Windows Update as shown in the image below demonstrates the active collaboration between Microsoft and Dell to programmatically enroll 2023 certificates. This ensures systems maintain boot integrity and security compliance ahead of the 2026 legacy expiration.

Comparing Dell and Lenovo Secure Boot Deployment Models

This transition table illustrates the critical migration from legacy CA 2011 certificates to the new 2023 trust hierarchy. Thereby, mapping each replacement to its specific role and storage location within the UEFI firmware databases.

Please see How to deactivate and reactivate a Slack user, how to change or cancel your Trello plan, and Remote WMI Connection: How to enable or disable WMI Traffic Using Firewall UI.

Updating WinPE for Secure Boot 2023 Compliance

This section explains how to update the Windows Boot Manager, update boot certificates, and rebuild WinPE boot media to align with the Windows UEFI CA 2023 Secure Boot trust chain.

Administrators can use several methods to validate whether systems trust the Microsoft Windows UEFI CA 2023 certificate. For large-scale deployments, they involves performing the validation during the boot media creation and deployment process to demonstrate the impact of missing or outdated Secure Boot trust chains.

Administrators do not validate Secure Boot certificates by mounting a boot.wim file from a Windows ISO. Instead, they validate Secure Boot trust by inspecting the deployed EFI system partition. Where the UEFI firmware evaluates signed binaries during startup.

Please see Active Directory Vulnerability Assessment with Purple Knight: Domain Controller Owner Is Not an Administrator, and how to perform Tape Drive Cleaning in Practice.

Check Certificate

To perform a proper check, administrators must examine the EFI bootloader files such as bootx64.efi or bootmgfw.efi deployed. Then verify the digital signature of these files using PowerShell, MMC, or signature validation tools to confirm whether the binaries are signed with the Microsoft Windows UEFI CA 2023 certificate.

This approach ensures accurate validation of Secure Boot trust because firmware enforcement occurs at the EFI bootloader level. To mounts the EFI System Partition to drive Z. Please use the command below.

mountvol Z: /s

If you do not have access to the partition via the File Explorer. Please see also the FAQ section below for more explanation. Even if the drive is not visible in File Explorer, you can confirm it exists and access it via command line as shown in the image below.

To list the EFI contents as shown below. Please use any of the commands listed below.

Get-ChildItem Z:\

Get-ChildItem "Z:\EFI\Microsoft\Boot"

Windows is now exposing the EFI System Partition as a normal filesystem volume so you can browse its contents. These are critical system boot partition that normally remains hidden. It contains files used by the firmware during system startup, including bootloader and boot configuration data.

Verify the Bootloader Signature

To correctly determine whether a boot component is signed with PCA 2011 or UEFI CA 2023, you must inspect the digital signature of the EFI bootloader itself. Verify the bootloader signature, please run the command below.

Extract and view the specific certificate issuer payload, please run the commands below.

$cert = Get-PfxCertificate -FilePath “Z:\EFI\Microsoft\Boot\bootmgfw.efi”
$cert.GetExpirationDateString()
$cert.Issuer

You can also verify this over the iDRAC interface as shown below.

Please see Remove a member from Trello Workspace: How to add or remove a Board Guest to a Trello Board, how to remove a member from Trello Board, and how to change your Windows Computer login Password.

Updating the Boot Manager with the Windows UEFI CA 2023 Certificate

If you are running Windows Server 2022 and Windows Server 2025), install all required Windows cummulative updates before proceeding. As you can see, we are running Windows Server 2025 and this method works also for Windows Server 2022 as tested.

Firmware Verification (KEK) etc

Secure Boot validation and certificate transition checks only operate when Secure Boot is enabled in UEFI firmware. When Secure Boot is disabled, UEFI variables such as DB and KEK remain inactive for trust enforcement, and certificate validation commands may return incomplete or false results.

Note: You will have to perform these checks before proceeding. They ensure you have installed firmware release that supports the 2023 CA.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).Bytes) -match ‘Windows UEFI CA 2023’
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).Bytes) -match ‘Microsoft UEFI CA 2023’
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match ‘Microsoft Corporation KEK 2K CA 2023’

Note that it returned false, we need to ensure that secure boot is enabled. And we have to manually trigger the new certificate enrollment.

Trigger the Certificate Enrollment

Note: Yo have to configure the AvailableUpdates registry value to enable Secure Boot update readiness in Windows. The 0x5944 value places the system into a coordinated update mode that allows Windows to participate in future Secure Boot certificate and Boot Manager update operations when supported firmware and servicing conditions are met

Once Secure Boot is enabled in UEFI/BIOS, administrators can configure the Windows Secure Boot servicing behavior using the AvailableUpdates registry value. Here is the key difference between the two keys despite achieving the same result “Registry values 0x100 and 0x5944”:

• 0x100 for Boot Manager Deployment is focused on updating the boot manager to the 2023-signed version, making it a critical step in ensuring Secure Boot compliance with the latest standards. For more information, see How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932.
• While, 0x5944 is for coexistence and compatibility designed for environments where you want to introduce the new certificates while maintaining backward compatibility with older ones. For more information, see Registry key updates for Secure Boot: Windows devices with IT-managed updates.

Run the following command in an Administrator Command Prompt to instruct Windows to stage the 2023 certificates for the next boot. We will use the 0x5944 value as it is the most comprehensive for initial enrollment.

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot" /v AvailableUpdates /t REG_DWORD /d 0x5944 /f

Restart the system.

During the boot process, the Windows Boot Manager will detect the registry flag and request the UEFI firmware to update the DB and KEK variables with the new Microsoft 2023 certificates.

Note: If you have secure boot disabled, the command below will also return false.

Confirm-SecureBootUEFI

Please see how to replace Veeam Recovery Orchestrator License, how to Fix failed to connect to the backup server: Make sure it is online, and how to fix Domain Join Error during Windows Deployment.

Enable Secure Boot

To enable secure boot without access the server console. You can use the iDRAC interface. Secure Boot can be enabled on Dell servers by configuring BIOS settings, enabling TPM, and applying the changes with a reboot.

To do this, log in to the iDRAC web interface using your administrator credentials. Then navigate to the Configuration section and select BIOS Settings.

Navigate to  to Configuration > BIOS Settings > System Security. Set Secure Boot to Enabled, set Secure Boot Policy to Custom. Also, set Secure Boot Mode to UserMode.

Secure boot has been enabled as shown below

Update the Boot Manager on your Server

Once Secure Boot is enabled in UEFI/BIOS, administrators can configure the Windows Secure Boot servicing behavior using the AvailableUpdates registry value with the command below.

This settings instructs the Windows Secure Boot update servicing stack to enable a coordinated update mode, which allows the system to prepare for Secure Boot certificate and Boot Manager updates as part of the Microsoft rollout process.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Secureboot" /v AvailableUpdates /t REG_DWORD /d 0x5944 /f

Note that you can also use this command below as discussed above

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x100 /f

Perform a set of checks prior to the registry update

After the reboot, log back in and run your PowerShell verification commands again. They should now return True.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).Bytes) -match ‘Windows UEFI CA 2023’
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match ‘Microsoft Corporation KEK 2K CA 2023’

Next, run the scheduled task. The hardware is ready, but the boot file is still the old version. This command will ensure that the Windows UEFI CA 2023 certificate is added to the UEFI Secure Boot Signature Database (DB)

Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”

Note: You have to manually run the Secure-Boot-Update scheduled task which is part of the Windows Secure Boot servicing infrastructure and is automatically triggered by the operating system when update conditions are met.

Verify the trigger for the task “Secure-Boot-Update” 

Note: Also open Task Scheduler to check the task. Verify that the trigger and next run time are set on the task “Secure-Boot-Update” by PowerShell cmdlet “Start-ScheduledTask” as shown below.

Please see Remove a Remote Desktop Service collection, how to Install Windows Subsystem for Android (WSA), and Installing Windows Subsystem for Android (WSA).

Alternatively, if the Scheduled Task is not available at a glance after creation. Instead of searching UI, use PowerShell:

Get-ScheduledTask | Where-Object {$_.TaskPath -like "*PI*"}

Get-ScheduledTask | Where-Object {$_.TaskName -like "*Secure*"}

To verify that the AvailableUpdates registry key is set to 0x5944 and perform a full system restart. Windows stages these binary replacements during the shutdown/boot sequence to bypass file-system locks on the EFI partition.

Note: Do not use the physical power button. Use the command line to ensure a clean hand-off to the UEFI firmware.

Note: Reboot the machine twice after running these commands to confirm that the machine is booting with the updated DB.

Verify the CA 2023 certificate is installed

After completing the update process, you must verify whether the Boot Manager is signed with the Windows UEFI CA 2023 certificate by following the steps below. Mount the EFI System Partition using the mountvol command used earlier.

mountvol Z: /s

 Check the digital signature of the boot manager

Note: Get-AuthenticodeSignature only verifies the embedded signature of the bootloader file and does not reflect the active Secure Boot trust configuration stored in UEFI firmware. Secure Boot certificate validation must be performed against firmware variables such as DB, KEK, and DBX.

Get-AuthenticodeSignature -FilePath "Z:\EFI\Microsoft\Boot\bootmgfw.efi" | Select-Object -ExpandProperty SignerCertificate | Format-List Subject, Issuer, NotBefore, NotAfter

Get-AuthenticodeSignature "Z:\EFI\Microsoft\Boot\bootmgfw.efi"

Extract and view the specific certificate issuer payload

$cert = Get-PfxCertificate -FilePath "Z:\EFI\Microsoft\Boot\bootmgfw.efi"
$cert.GetExpirationDateString()
$cert.Issuer

The two certificates appear because Windows uses the 2011 Microsoft PCA for signing the bootloader itself (Authenticode), while Secure Boot separately uses the UEFI CA 2023 in firmware to control whether that bootloader is allowed to run (trust validation).

Get-AuthenticodeSignature reads the signature block attached to the .efi file. Microsoft is still using the PCA 2011 infrastructure to sign the actual binary because that signature is what the OS-level integrity checks expect to see.

Note: The UEFI CA 2023 (The Firmware Key) is the “key” stored in your motherboard’s (or VM’s) Secure Boot DB. It doesn’t care what the “label” on the file is. It cares whether the Certificate embedded within that file’s header is part of its allowed database. You can further verify the certificate status by using the comamnd below.

Note: When you run the command below, you will get a list of gabages. This is because, UEFI variables are binary encoded “DB, KEK, DBX are binary certificate stores”. They are not stored as readable ASCII strings

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI DB).Bytes)

Please see SCVMM setup Error 10421: Fix VMM Service Account conflict, SCVMM setup Fails: Fix Missing Windows ADK Deployment Files, and Integrate Hyper-V [SCVMM] with Veeam Recovery Orchestrator.

Updating WinPE Boot Files for Secure Boot Compatibility

The Windows 11 24H2 ADK provides the necessary 2023-signed binaries, but it maintains the 2011 PCA signatures in the default template folders for backward compatibility. To ensure WinPE media is compliant with the 2023 CA, administrators must manually refresh the ADK Media boot files (bootx64.efi, bootmgfw.efi) using updated files from a patched Windows installation or via the bcdboot command.”

WinPE is a minimal preinstallation environment that includes only the essential boot components required to start the system. As a result, its EFI bootloader files must be explicitly updated or replaced to align with the Windows UEFI CA 2023 trust chain.

WinPE boot media must be updated separately, as older boot images may fail to boot on systems that have transitioned to the Windows UEFI CA 2023 trust chain. To proceed, first create a backup of the WinPE backup as shown below.

Verify the Bootx64.efi Signing Certificate

(Get-PfxCertificate -FilePath "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Boot\bootx64.efi").Issuer

Replacing WinPE EFI Boot Files with CA 2023–Signed Binaries

We are now rebuilidng the boot media from the latest ADK WinPE. The Windows bootloader binaries (bootmgfw.efi, bootmgr.efi, bootx64.efi). The UEFI CA in firmware and updates. And ships these updated EFI binaries in new Windows ISOs and new ADK/WinPE releases

# Update primary UEFI boot entry (CRITICAL)
copy “Z:\EFI\Microsoft\Boot\bootmgfw.efi” “C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Boot\bootx64.efi” /Y

# Update actual Boot Manager (CRITICAL)
copy “Z:\EFI\Microsoft\Boot\bootmgfw.efi” “C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Microsoft\Boot\bootmgfw.efi” /Y

# Optional: update secondary loader
copy “Z:\EFI\Microsoft\Boot\bootmgr.efi” “C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\bootmgr.efi” /Y

The ADK Media folder uses a specific hierarchy to support different boot scenarios:

• \bootmgr.efi: Used for legacy/compatibility handshakes.
• \EFI\Boot\bootx64.efi: This is the file the motherboard looks for first on a USB/ISO. It must be the 2023-signed version, or the “Secure Boot Violation” will happen immediately.
• \EFI\Microsoft\Boot\bootmgfw.efi: This is used for chained booting.

# Verify Boot Manager (EFI partition)
$BootMgrCert = Get-PfxCertificate -FilePath “Z:\EFI\Microsoft\Boot\bootmgfw.efi”
$BootMgrCert.Issuer

# Verify WinPE boot file (Media)
$WinPECert = Get-PfxCertificate -FilePath “C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Boot\bootx64.efi”
$WinPECert.Issuer

After the copy operation as you can see below, we can now verify the presence of the Boot File Signing Certificate.

The command below checks the digital signature of the primary UEFI bootloader file in your ADK Media folder to verify which Microsoft Production PCA signed the binary.. It confirm that the file is authentic and hasn’t been tampered with

Get-AuthenticodeSignature -FilePath "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Boot\bootx64.efi"

Please see Integrate Hyper-V: Install System Center Virtual Machine Manager, how to reset Microsoft 365 User Password, and Inbound connection Error: Failed to Perform Scheduled Replication [Part 2].

Customize WinPE Boot Image

Note: Optional Step! If you wish to add or customize the WinPE boot image please see how to Steps to customize Windows PE boot images. This rocess involves mounting the WinPE and customizing and thereafter unmount the image.

When you are done customizing the boot image, do not forget to commit as shown below.

Note that I copied the WinPE boot Image to a working directory where it can be mounted. This will allow you to access and inspect its contents.

Regenerate LiteTouchPE.wim Image

Updating the WinPE base alone is not sufficient for MDT environments. The LiteTouch boot image must be regenerated to incorporate the updated EFI boot components, and the refreshed image must be redistributed to WDS

MDT boot images are regenerated from the ADK WinPE base image, and any changes applied to LiteTouchPE.wim only persist until the next update cycle or regeneration. Secure Boot certificate validation is not controlled by MDT but by the UEFI firmware and the signing of EFI boot binaries in the underlying WinPE media.

Follow through to generate the LiteTouchImage.

The LiteTouchPE.wim is a customized WinPE image containing MDT scripts, drivers, and other customizations; since firmware/UEFI validates the EFI boot loaders inside this WIM during PXE or USB boot, updating the EFI binaries here ensures your deployment media is Secure Boot–compliant.

This process ensures that the Lite Touch boot image generated by MDT is validated for Secure Boot compliance. It ensures the boot loader files are signed with the updated Microsoft Windows UEFI CA 2023 certificate. Instead of the older Microsoft Windows UEFI CA 2011 certificate. But as we will see very shortly. They are are still signed by the UEFI CA 2011 certificate at the time of writing this article.

For those using Microsoft Deployment Toolkit (MDT), Microsoft recommends modifying the winpe.wim boot image which is included with the Windows PE add-on for the Windows ADK. The boot image is located at the path below. If you are using Microsoft Configuration Manager.

C:\Program Files(x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\en-us\winpe.wim

Please see how to license Veeam Enterprise Manager and Add VBR Servers, how to upgrade Windows Admin Center from v2411 to v2511, and Deploy Veeam Recovery Orchestrator and Agents to VBR and VEM.

Regenerating and Deploying the Lite Touch Boot Image to WDS

Rather than simply updating the existing LiteTouch boot image, you must completely regenerate it from the updated WinPE source as shown in the image below.

Note: Also ensure that the Deployment Properties are configured as desired such as the Rules, platform support x64 and monitoring etc.

This update ensures that all changes such as updated EFI boot files, drivers, and Secure Boot components are fully embedded into the new image.

Note: When you regenerate the deployment share in MDT using the “Completely regenerate the boot images” option, MDT rebuilds the LiteTouchPE image from the underlying WinPE base. This guarantees that the boot image includes the latest bootloader binaries and configuration changes instead of relying on previously cached or outdated components.

When complete as shown below

Next, navigate to the deployment share and click on the boot Folder as shown below.

Locate the newly generated LiteTouchImage. This is the boot image that will be re-uploaded to WDS. This ensures that all future deployments use the updated boot image signed with the Microsoft Windows UEFI CA 2023 certificate.

Please see ADK|WinPE|MDT: Deploy Windows with WDS, how to download and install the Windows ADK Patches, and Unable to edit MDT XML unattended file: Could not load file.

Upload Image to WDS

Launch Windows Deployment Services (WDS) as shown below

You can modify an existing boot image in WDS or add a new image as shown below.

Adding image

Image added or modified as the case maybe for you.

Note: The EFI folder inside the Lite Touch boot image contains several files, including bootmgfw.efi, bootmgr.efi, and winsipolicy.p7b. While there are other supporting files present, they are not critical for this verification. For Secure Boot compliance, the focus should be on bootmgfw.efi, as it is the primary UEFI boot manager whose signing certificate determines whether the image will boot on Secure Boot–enabled systems.

Please see How to link an iPhone with Windows PC with Phone Link App, How to synchronize Apple Calendar on Windows with Outlook [Part 2], and Fix Users must have at least permission on these subscriptions.

FAQs

I hope you found this guide on how to Update WinPE Boot Images with Windows UEFI CA Certificates very useful. Please feel free to leave a comment below.