Secure Boot 2023 Compliance Across WinPE, MDT, WDS, and ADK: Boot Chain Alignment and PXE Validation [Final Part]

Since my devices had secure boot update applied (SafeOS), the firmware and Secure Boot policy enforced stricter validation from the PC. While the deployment environment still served older ( mismatched boot files). This mismatch led to PXE failures, as the firmware refuses to execute the boot loaders that did not meet the minimum required version or trust policy. In this article, we shall discuss “Secure Boot 2023 Compliance Across WinPE, MDT, WDS, and ADK: Boot Chain Alignment and PXE Validation [Final Part]”. This guide resolves the various issues present in these guide “how to Fix Operating System Loader failed signature verification” on Dell Safe BIOS Systems via PXE [Part 3], and PXE Boot Failure: “Access Denied or Aborted” with Secure Boot on [Part 4]“.

Note: Based on the original documentation from Microsoft, applying the revocation (still not performed in this guide), and applying the SVN update to the firmware were optional. However, to prevent errors such as “Operating System Loader Failed Signature Verification” on Dell SafeBIOS systems during PXE boot and “PXE Boot Failure: Access Denied or Aborted” when Secure Boot is enabled, this final guide was developed.

As you can see from the referrenced articles, there is a need to prevent the roll back of these binaries by applying the SVN update on the WDS server. As mentioned previously, you could optionally enable the revocation for the 2011 signing path so it cannot be reused later. But be careful, as Microsoft recommends having a recovery drive in place in case of failure. More on this later!

Also, see Hardening Your Infrastructure: A Guide to VMware VBS and MS GPO Credential Guard in VBR v13, how to run Windows 11 on HyperV, and ow to Bypass unsupported CPU and Processor by upgrading to Windows 11 via Windows Update.

What to know before performing the DBX Revocation?

Note: Once DBX is updated, older media signed with the 2011 certificate may stop booting immediately. This means, we are further hardening our devices and intentionally removing trust from the older path so it cannot be reapplied later.

If you must enable the revocation, do not skip the recovery flash drive creation. Microsoft emphasizes that once the revocation is in place, you may need a recovery path if the old boot media no longer works. Do not forget to replace the MDT/WDS boot images. Otherwise, PXE can still hand out stale boot files that fail after revocation. I will show you how to perform these steps as well.

Here is the guide on how to enable 2023 Secure Boot update: Fix Secure Boot certificates expiration [Part 1], how to Fix an error occurred while attempting to start selected VM on Hyper-V, and Failed to Upgrade VIHR Component: Failed to open deployer Service Management Port.

Why we need to apply the SVN update to the firmware

The Boot Manager includes a built-in self-revocation feature. When it runs, the Boot Manager checks its own Secure Version Number (SVN) against the SVN stored in the system firmware. If its SVN is lower than the one in firmware, the Boot Manager refuses to execute. This mechanism prevents attackers from rolling back to older, unpatched versions of the Boot Manager.

The Part 4 of the guide above struggled with rollback issues because it approached the problem primarily from a WinPE and file-update perspective by injecting cumulative updates or manually replacing EFI binaries. I can attest that the rollback behavior was not caused by outdated WinPE alone, but by a misalignment between the OS servicing baseline (WinSxS).

As a result, certain boot files (wdsmgfw.efi etc) as shown below continued to be regenerated or restored from sources that remained aligned with the older Secure Boot trust chain, leading to recurring certificate mismatches across the deployment environment.

As a result, even after updates, the environment remained inconsistent, allowing fallback behavior and Secure Boot validation failures to persist. The fix now was to correctly synchronize the entire boot chain across WinPE, WDS, and the OS-controlled servicing layer. This ensured that what was being served (WDS) and what was allowed to execute (boot baseline and Secure Boot policy) were fully aligned.

In a nutshell, SVN helped in resolving the rollback issue by addressing the execution layer of the boot chain. This ensured that only updated binaries could actually run, eliminating residual rollback paths and stabilizing Secure Boot 2023–compliant PXE behavior, while rebuilding WDS fixed what PXE was serving (by regenerating wdsmgfw.efi from updated WinPE sources).

Therefore, enabling SVN introduced a minimum version enforcement mechanism, ensuring that any older or inconsistent boot manager versions whether from cached paths, fallback flows, or partial mismatches were rejected at execution time.

While updating the SVN in the firmware in the original microsoft guide was technically listed as optional. In the real world, many modern enterprise devices (especially Dell systems with SafeBIOS or systems with aggressive firmware updates enabled) will automatically bump their internal NVRAM SVN counter the moment they successfully boot a patched OS or receive a BIOS update.

Once firmware begins enforcing newer Secure Boot protections such as higher Security Version Numbers (SVNs), updated trust policies, or boot manager revocations rollback protection effectively prevents the execution of older or vulnerable boot loaders. As a result, if WDS or MDT attempts to serve an outdated or inconsistent boot component, PXE boot fails with errors such as “Access Denied.”

Please see How to enable Secure Boot on PC to install Windows 11, how to Prevent Standard Users from Changing BitLocker Password, and Azure Managing Subscriptions with PowerShell: From Login-AzAccount to Resource Control and Private Endpoint Verification for Azure File Share”.

Verify the Bootloader Signature

First, we have to mount the EFI Partition. 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.

To verify the bootloader signature and view the certificate details, run the commands below. These commands extract the signing certificate from bootmgfw.efi and display the certificate expiration date and issuer information.

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

As you can see above, there is no need to trigger or update the Boot Manager with the Windows UEFI CA 2023 Certificate as discussed in Part 1 referenced above and how to Update WinPE Boot Images with Windows UEFI CA Certificates [Part 2].

Verifiy WinPE Boot Files for Secure Boot Compatibility

The current Windows ADK does not provides the necessary 2023-signed binaries at the time of writing this article. It maintains the 2011 PCA signatures in the default template folders for backward compatibility. But this was fixed in part 2 article referenced above and we currently have the UEFI 2023 Secure Boot Certificate installed.

Note: If your WinPE is not updated, please follow the steps as discussed here ‘how to Fix Operating System Loader failed signature verification” on Dell Safe BIOS Systems via PXE [Part 3] referenced above”.

I verified the WDS installation path (X:\RemoteInstall\Boot\x64\) and confirmed that bootmgfw.efi is compliant. However, wdsmgfw.efi was still signed with the Windows Production CA 2011, which indicates a rollback or incomplete update. I need to correct this properly without manually copying EFI binaries. This is the ‘wdsmgfw.efi = WDS Network Boot Program (NBP)” and it is different and this rolls back. bootmgfw.efi.

Please see The Backup Was Safe: The Data Center Was not: A Real-World Lesson About Hidden Data Center Risks and Governance Failures, and Enterprise Tape Library Administration: Control Path, Firmware, Media Management and Tape Operations.

Integrating Cumulative and Safe OS Updates into WinPE Using DISM

This step involves performing a targeted search in the Microsoft Update Catalog for “2026-05 Windows 11 26H1”. The purpose is to manually identify and obtain the latest cumulative and servicing updates directly from Microsoft’s release pipeline. Here is a similar article discussing these steps “Steps to customize Windows PE boot images“.

This is a critical staging step, as it ensures the deployment environment is built using the most recent foundational security, stability, and operational fixes for the 26H1 branch, rather than relying solely on automated Windows Update delivery mechanisms. Please see how to download and install the Windows ADK Patches, and how to uninstall and upgrade ADK, WinPE, and MDT.

The commands below are used to service an offline WinPE (Windows Preinstallation Environment) image by injecting required updates directly into the mounted WIM. This ensures the boot environment includes the latest servicing stack and Safe OS improvements needed for modern deployment scenarios, including Secure Boot compatibility and deployment stability.

Each command uses DISM (Deployment Image Servicing and Management) to apply update packages (.msu and .cab) into the mounted WinPE image located at Mount-1. I assume the below is run as a script as such we have the pause to stop the execution of the script.

%DISM-26H1%\dism /Image:F:\WIM-Preparation\WinPE11-26H1\DISMtheWIM\Mount-1 /Add-Package /PackagePath:"F:\WIM-Preparation\WinPE11-26H1\DISMtheWIM\IntegrateToWIM\SafeOS\windows11.0-kb5089548-x64_313f1b62787096e442a8aac96dbf3d042fa04313.msu"

%DISM-26H1%\dism /Image:F:\WIM-Preparation\WinPE11-26H1\DISMtheWIM\Mount-1 /Add-Package /PackagePath:"F:\WIM-Preparation\WinPE11-26H1\DISMtheWIM\IntegrateToWIM\SafeOS\windows11.0-kb5089592-x64_1689793c1fe933fb99bff41e1f3ae4a925d29df2.cab"

Pause

Applying Safe OS / Cumulative Update Package (MSU) command injects a Safe OS cumulative update (MSU format) into the WinPE image.

While, the additional Safe OS Component Update (CAB) injects a cab-based Safe OS update package into the same WinPE image.

Do not forget to commit

%DISM-26H1%\dism /Unmount-Wim /MountDir:F:\WIM-Preparation\WinPE11-26H1\DISMtheWIM\Mount-1 /commit

Take the patched Winpe.wim file to the following location as shown below. “C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\en-us”. We will save the original winpe.wim file before copying into this location.

Let’s run the command below to list all boot images currently stored on a WDS server. We already know the location of these images but would like to show you how to detrmine this while troubleshooting WDS and Secure Boot Update Issues.

wdsutil /Get-AllImages /Show:Boot

Remove Lite Touch Image

But based on the show boot image result. I will proced and remove the litetouch images. This will prevent accidental rollback.

wdsutil /Remove-Image /ImageType:Boot /ImageName:"LiteTouchForSecureBootCA2023Test"

Later on in this guide, we shall reinitialize WDS. This step will fixe wdsmgfw.efi we mentioned above that still had 2011 certificate with the commands below.

wdsutil /Uninitialize-Server
wdsutil /Initialize-Server /RemInst:"F:\RemoteInstall"

Since we will reinitialize WDS later, you could chose to ren the folder x64 in this location depending on how it applies to you “C:\RemoteInstall\Boot\x64” as shown below so WDS regenerates it once again. To do this, stop the WDS first as shown below.

At this time, you can start WDS again.

Please see how to Enabling and Configuring WinRM via GPO, SCVMM setup Fails: Fix Missing Windows ADK Deployment Files, and ADK|WinPE|MDT: Deploy Windows with WDS.

Applying the Secure Boot 2023 Update

Just in case oyu have not updated your WDS Server with Secure Boot Update as discussed in the articles referenced in step 1 and 2 above. The commands below are used to trigger the Windows Secure Boot update workflow on the host system, ensuring the device applies the required 2023 Secure Boot certificate updates and firmware validation changes.

As mentioned already, this process is separate from WinPE/MDT/WDS updates and targets the host operating system Secure Boot configuration.

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

schtasks /Run /TN "\Microsoft\Windows\PI\Secure-Boot-Update"

Reboot at least once (sometimes twice)

Please see How to Install Winget on Windows Server, how to create Bitbucket Repository, and how to Fix unable to start the Application Identity Service.

Enable SVN

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates /t REG_DWORD /d 0x200 /f

schtasks /Run /TN "\Microsoft\Windows\PI\Secure-Boot-Update"

Do not forget to reboot afterwards

WDS Server Reset

At this stage, despite the WDS reset sequence was correctly executed by stopping the service, uninitializing the server, deleting and recreating the RemoteInstall\Boot folder, reinitializing WDS, and re-adding the updated WinPE image, the PXE environment still failed because the underlying issue was not just cached WDS binaries.

But a deeper boot chain inconsistency between what WDS was regenerating and what the firmware was willing to execute. In other words, WDS did exactly what it was supposed to do and rebuilt its boot. Follopw along while we proceed with the resolution.

Please see Creating a WinPE USB Drive: Fixing System Boot Issues, how to Configure Multiple IP Addresses on a Single or Multiple NICs, and Achieve 3-2-1 rule with SOBR on Synology or OOTBI and Wasabi.

Resolving the Remaining 2011 Certificate Paths

Note: The 2023 Secure Boot certificate update does NOT uniformly replace every EFI/boot binary everywhere. Some locations are source templates, others are deployment outputs, and others are OS-controlled system paths that only update via Windows servicing.

Because of the above, I went ahead to pinpoint the exact locations containing the older 2011 files that will cause the firmware to halt with signature verification failures or trigger an unexpected rollback during deployment. Below are paths to check for 2023 secure boot update certificate (all updated)

- F:\Deployment\Boot\x64 for the deployment share
- F:\RemoteInstall\Boot\x64
- F:\Deploymen\Boot\x64\EFI\Boot
- F:\Deployment\Boot\x64\EFI\Microsoft\Boot
- C:\Windows\System32\RemInst\boot\x64
- C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media
- C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Boot (bootx64.efi had the 2023 certificate update)
- C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Microsoft\Boot

While the below still had 2011 certificate

- F:\Deployment\Operating Systems\Windows 11\efi\boot\bootx64.efi 
- C:\Windows\Boot\EFI still has 2011 certifcate for bootmgfw.efi
- C:\Windows\System32\RemInst\boot\x64 still has the 2011 certificate for bootmgfw.efi

Interestingly, the following path C:\Windows\System32\RemInst\boot\x64 had the 2023 certificate for wdsmgfw.efi. Therefore, I copied from “C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Boot\bootx64.efi which has the 2023 certificate update to replace the file in this location “F:\Deployment-03\Operating Systems\Windows 11 Enterprise in W11-26H1-17-03\efi\boot\bootx64.efi”.

Please see how to update Veeam Backup and Replication [VBR], how to update Object First OOTBI Cluster, and How to create a Tailscale VPN connection to Synology NAS.

The Fix “Windows Source Path (F:\Deployment)”

When MDT applies an operating system image to a target hard drive, it formats the drive, lays down the .wim file, and then copies the bootloader files directly out of this source folder to create the local EFI System Partition (ESP). If these files are still 2011-signed, the machine will successfully PXE boot (using your new WinPE), complete the task sequence, reboot, and instantly crash or roll back on its first local hard drive boot.

Therefore, we must fix this as well despite not a pressing issue at this time. We will have to replace the “bootx64.efi” with the “updated 2023 certion”. I have copied this from the ADK Media path as shown below.

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

The WDS Staging Source (C:\Windows\System32\RemInst\boot\x64)

This is the local blueprint folder that WDS uses to populate or repair the F:\RemoteInstall directory structure. If wdsmgfw.efi is updated here but bootmgfw.efi and bootmgr.exe are still using the 2011 certificate, any server-side role optimization or image re-index will push those older 2011 binaries back into your live PXE environment, overwriting your hard work.

To fix this, we have to pull the fresh 2023 binaries from your patched ADK and overwrite the stale files in this master directory. To do this, run these commands in an elevated PowerShell window to fix the RemInst master folder:

$RemInstPath = "C:\Windows\System32\RemInst\boot\x64"
$ADKMediaEEFI = "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Microsoft\Boot"

# 1. Take ownership of the system files to allow modification
takeown /f "$RemInstPath\bootmgfw.efi" /a
icacls "$RemInstPath\bootmgfw.efi" /grant administrators:F

# 2. Copy the verified 2023-signed files from the patched ADK media path
Copy-Item "$ADKMediaEEFI\bootmgfw.efi" -Destination "$RemInstPath\bootmgfw.efi" -Force

# Note: bootmgr.exe is a legacy file for BIOS/MBR boot. Modern 2023 Secure Boot mitigations target UEFI (.efi). As long as bootmgfw.efi is updated here, the UEFI PXE path is secure.

Fix “Local Server Boot Paths (C:\Windows\Boot\EFI)”

The files in C:\Windows\Boot\EFI belong to the host operating system’s local boot chain and are managed by Windows servicing and component protection mechanisms. Although these files may still reflect older embedded signatures, they are not part of the MDT or WDS PXE deployment process.

Manual modification of this directory is not supported, as Windows File Protection will revert changes during servicing or reboot. The Secure Boot 2023 update applies primarily to firmware trust stores (DB/DBX) and deployment boot media (WinPE, WDS PXE, MDT boot images), not the host OS boot directory itself.

Note: The reason for the 2011 certificate even when the server is fully updated is due to a deliberate staging mechanism built into Windows.

When you install a Windows Cumulative Update as shown below. Microsoft does not automatically overwrite the active files in C:\Windows\Boot\EFI with the new 2023-signed versions right away. Instead, the updated high-SVN files are downloaded and held in a hidden system staging area (C:\Windows\WinSxS). They are kept on standby until you explicitly tell the operating system to apply the Secure Boot mitigations.

If we want to force C:\Windows\Boot\EFI to update to the 2023 certificate with a high SVN immediately, you have two options: The recommended Official Microsoft steps (via registry keys) or The Direct Injection Way (manual replacement).

Use Option 1 if this server is a production machine and you want Microsoft’s native servicing engine to handle the lifecycle correctly.

Use Option 2 if you are explicitly re-staging your WDS environment right now and need to guarantee that no system process accidentally grabs an old 2011 file from this folder during your Golden WinPE setup.

Option 1: The Official Microsoft Mitigation (Recommended)

This instruct Windows to safely drain the staged 2023 files from WinSxS, update C:\Windows\Boot\EFI, and lock in the SVN at the operating system level. To do this, open an elevated PowerShell window and run the following registry commands:

# 1. Apply the Phase 2 BitLocker/Secure Boot mitigation block
Reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Mitigation" /v "PlatformMitigations" /t REG_DWORD /d 1 /f

# 2. Tell the OS to update the local Boot Manager files to the latest staged version on next reboot
Reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot" /v "AvailableUpdates" /t REG_DWORD /d 0x30 /f

Option 2: The Direct Manual Injection

If you do not want to reboot the deployment server right now but want those files updated immediately, we can manually replace them using the verified 2023 files from your patched ADK.

Because these are protected operating system files, standard administrator permissions will block you. We must take ownership of the files first by runningthese commands in your Elevated PowerShell window:

$LocalEfiPath = "C:\Windows\Boot\EFI"
$ADKMediaEEFI = "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Microsoft\Boot"

# 1. Take ownership of bootmgfw.efi and grant permissions
takeown /f "$LocalEfiPath\bootmgfw.efi" /a
icacls "$LocalEfiPath\bootmgfw.efi" /grant administrators:F

# 2. Take ownership of bootmgr.efi and grant permissions
takeown /f "$LocalEfiPath\bootmgr.efi" /a
icacls "$LocalEfiPath\bootmgr.efi" /grant administrators:F

# 3. Overwrite the files with the 2023-signed versions from your ADK source
Copy-Item "$ADKMediaEEFI\bootmgfw.efi" -Destination "$LocalEfiPath\bootmgfw.efi" -Force
Copy-Item "$ADKMediaEEFI\bootmgr.efi" -Destination "$LocalEfiPath\bootmgr.efi" -Force

Note: Copy-Item “$ADKMediaEEFI\bootmgr.efi” -Destination “$LocalEfiPath\bootmgr.efi” -Force does not exisit and can be ignored. Also, this is a legacy boot manager!

Note: I had the properties of the file bootmgfw.efi opened and as such it failed. You can re-run the command as shown here “Copy-Item “$ADKMediaEEFI\bootmgfw.efi” -Destination “$LocalEfiPath\bootmgfw.efi” -Force”.

Please Manage User Permission on Synology with Active Directory [Part 1], how to Configure Synology DS923+ NAS for File Sharing [Part 2], and how to Fix MDT Workbench Crashes when opening WinPE tab Properties.

Unified Execution Script

If you wish to run both, then run option 2 before applying option 1. Running Option 2 (Direct Manual Injection) first ensures that the physical files on disk in C:\Windows\Boot\EFI are updated to the 2023 certificate immediately. Followed by it with Option 1 (The Registry Mitigations) ensures that the Windows servicing stack recognizes the configuration change, locks it in natively, and coordinates the secure handoff with the motherboard’s firmware upon the next reboot.

# ==============================================================================
# PHASE 1: DIRECT MANUAL INJECTION (Option 2)
# ==============================================================================
$LocalEfiPath = "C:\Windows\Boot\EFI"
$ADKMediaEEFI = "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Microsoft\Boot"

Write-Host "Taking ownership and replacing files in C:\Windows\Boot\EFI..." -ForegroundColor Cyan

# 1. Take ownership of bootmgfw.efi and grant full control permissions
takeown /f "$LocalEfiPath\bootmgfw.efi" /a
icacls "$LocalEfiPath\bootmgfw.efi" /grant administrators:F

# 2. Take ownership of bootmgr.efi and grant full control permissions
takeown /f "$LocalEfiPath\bootmgr.efi" /a
icacls "$LocalEfiPath\bootmgr.efi" /grant administrators:F

# 3. Overwrite the files with the verified 2023-signed versions
Copy-Item "$ADKMediaEEFI\bootmgfw.efi" -Destination "$LocalEfiPath\bootmgfw.efi" -Force

# ==============================================================================
# PHASE 2: OFFICIAL MICROSOFT MITIGATION REGISTRY KEYS (Option 1)
# ==============================================================================
Write-Host "Applying Secure Boot mitigation registry configurations..." -ForegroundColor Cyan

# 4. Apply the Phase 2 BitLocker/Secure Boot mitigation block
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Mitigation" /v "PlatformMitigations" /t REG_DWORD /d 1 /f

# 5. Direct the OS to evaluate and lock in the Boot Manager files on the next restart
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot" /v "AvailableUpdates" /t REG_DWORD /d 0x30 /f

Write-Host "Execution complete. Please reboot the server to finalize firmware alignment." -ForegroundColor Green

What to Expect Upon Reboot

Upon reboot, the server after running this combined sequence:

1. The UEFI firmware will read the newly injected 2023-signed bootmgfw.efi from C:\Windows\Boot\EFI.
2. The registry keys will trigger the operating system’s Secure Boot mitigation engine to validate the boot path.
3. The motherboard’s internal NVRAM SVN counter will safely align with the high-SVN file version that has just been copied over.

Once the server comes back online, the local environment, the staging directories, and the deployment pathways will be completely unified under the UEFI CA 2023 trust chain. If you have followed me to this stage, you should be ready to proceed with your deployments!

Please see How to fix a vulnerable Trusted Platform Module [TPM], how to install Windows Server unto ACEMAGICIAN Mini PC, and how to Create Folders and Enable File sharing on Windows.

Updating the WDS Master Template (RemInst) to Eliminate Persistent 2011 Boot Chain Artifacts

As I mentioned earlier, the wdsmgfw.efi file in this directory is already updated, but bootmgfw.efi was still clinging to the 2011 certificate. Therefore, we will updating the WDS Master PXE Boot Template in C:\Windows\System32\RemInst\boot\x64 for Secure Boot 2023 Compliance.

Just like with the previous folder, the bootmgfw.efi here must be updated to the 2023 version because WDS treats this folder as its absolute blueprint template. If WDS ever tries to rebuild or repair your PXE shares, it pulls from here as mentioned above. This means the 2011 signed files are a ticking time bomb that overwrite the live environment.

Note: Do not pay attention to the bootmgr.exe as mentioned earlier. This is a legacy 16-bit/32-bit executable used strictly for legacy BIOS (MBR) booting. The UEFI 2023 Secure Boot and SVN changes apply exclusively to UEFI environments (.efi files). Microsoft does not update bootmgr.exe with the UEFI 2023 certificate because legacy BIOS doesn’t use or understand certificates. Leaving bootmgr.exe as-is is completely normal, expected, and will not cause a Secure Boot rollback or failure.

Kindly run the below command to take ownership and inject the 2023 certificate into bootmgfw.efi in your master RemInst path.

$RemInstPath = "C:\Windows\System32\RemInst\boot\x64"
$ADKMediaEEFI = "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\Media\EFI\Microsoft\Boot"

Write-Host "Updating master WDS template folder: $RemInstPath" -ForegroundColor Cyan

# 1. Take ownership of the master bootmgfw.efi file to bypass system protections
takeown /f "$RemInstPath\bootmgfw.efi" /a
icacls "$RemInstPath\bootmgfw.efi" /grant administrators:F

# 2. Overwrite it with the verified 2023-signed file from your patched ADK media
Copy-Item "$ADKMediaEEFI\bootmgfw.efi" -Destination "$RemInstPath\bootmgfw.efi" -Force

Write-Host "Master bootmgfw.efi successfully updated to 2023 CA." -ForegroundColor Green

Note: You do not need to change bootmgr.exe, and Option 1 (the registry mitigation) will not alter its certificate either. Legacy BIOS doesn’t have a Secure Boot engine, doesn’t know what a UEFI certificate is, and completely ignores SVN counters.

Please see how to Install DBeaver on macOS: Connect to PostgreSQL Database, and how to determine Tombstone Lifetime in Active Directory.

Verify the SVN is correctly applied

To verify that your server and staging environment are outputting the correct SVN. You can check the file properties directly using PowerShell.

Microsoft increments the file version of bootmgfw.efi every time they increment the SVN. To do this, open an elevated PowerShell window and run the following verification script to check your two main local server paths:

# Paths to check
$Path1 = "C:\Windows\Boot\EFI\bootmgfw.efi"
$Path2 = "C:\Windows\System32\RemInst\boot\x64\bootmgfw.efi"

# Pull file version metadata
Write-Host "--- SERVER BOOT MGMT FILE VERSION AUDIT ---" -ForegroundColor Cyan
Get-ItemProperty -Path $Path1 | Select-Object -Property VersionInfo | Format-List
Get-ItemProperty -Path $Path2 | Select-Object -Property VersionInfo | Format-List

As you can see, the ProductVersion or FileVersion string in the output of 10.0.26100.30227.

• If both paths match and show the version matching your latest 2026 Cumulative Update, the server’s master template environment is completely verified.
• WDS will now structurally be incapable of serving a downgraded, low-SVN file to the PXE clients.

Please see How to change Active Directory Group Scope, how to add a new Domain Controller to an Existing Domain, and how to keep Apps up to date on Windows devices.

Cleanup and Purge Legacy Images from the WDS Console

Before resetting the WDS configuration via the command line, we want to cleanly remove the old image references. To do this, please follow the steps below:

• Open the Windows Deployment Services (WDS) Console.
• Click on Boot Images.
• Right-click your old LiteTouchPE_x64 image and select Delete.
• Close the console.

As part of the remediation and rebuild process, any previously generated boot images within the MDT Deployment Share should be removed before regenerating the environment. This ensures that no outdated or stale boot files are carried forward into the updated WDS configuration, which could otherwise result in inconsistent PXE boot behaviour or the accidental reuse of legacy boot components.

Since we have previously applied and verified the SVN update, we will not be re-applying this. Proceed with WDS reset as recommended earlier.

Please see Raise or Downgrade AD Domain and Forest Functional Level, how to Install Lets Encrypt Certificate on Windows with Certbot, and AD Recovery: Fix device ran into an issue with error 0xc00002e2.

WDS Reset and Secure Boot 2023–Aligned PXE Deployment Rebuild

Based on the validation completed across WinPE, WDS, and the Secure Boot 2023 update chain. The environment is now in a safe and consistent state to proceed with a full WDS reset and rebuild.

This step consolidates all prior fixes into a clean operational baseline, ensuring PXE boot reliability and eliminating legacy boot artifacts from previous deployments. We will have to run the commands below to perform WDS reset.

# 1. Stop the active deployment service
net stop wdsserver

# 2. Uninitialize the server to sever active PXE binds
wdsutil /Uninitialize-Server

# 3. Completely scrub the old PXE boot folders
Remove-Item -Recurse -Force "F:\RemoteInstall\Boot"

# 4. Recreate a clean boot folder structure
New-Item -ItemType Directory -Path "F:\RemoteInstall\Boot"

# 5. Re-initialize WDS to rebuild fresh, modern PXE binaries from the updated RemInst master blueprints
wdsutil /Initialize-Server /RemInst:"F:\RemoteInstall"

Upon reset, the bootmgfw.efi file now retains the updated 2023 Secure Boot certificate. This confirms that the WDS and WinPE rebuild process has successfully preserved the modern boot chain without rollback to legacy signatures.

Please see How to integrate ObjectFirst OOTBI Appliance with VBR, how to Configure Object First OOTBI Appliance, and How to Disable device encryption on Windows.

Update the Deployment Share and Regenerate Lite Touch Images

Now that the underlying ADK is permanently updated with high-SVN files, we will proceed to the Deployment Workbench and perform the below actions;

Select the deployment share in question and right-click it. Then, select Update Deployment Share. This will completely regenerate the boot images.

Because the base ADK image contains the correct cumulative update. The newly created LiteTouchPE.wim will natively hold the high-SVN binaries.

As you can see below, the deployment share update has completed.

Now, you can proceed to the WDS Server and Add the newly genrated Lite Touch image and start imaging your systems.

UEFI Boot Manager Phase (Hardware-Level Secure Boot Validation)

This stage represents the initial UEFI Boot Manager execution phase, which operates at the physical hardware layer through the system firmware (BIOS/UEFI). This is the critical point where Secure Boot enforcement is applied, including UEFI CA 2023 certificate validation and Secure Version Number (SVN) checks.

During this phase, all boot components are validated against the trusted firmware-provisioned certificate chain before any operating system or WinPE code is allowed to execute. Previously, endpoints using older 2011-signed boot components served via WDS would fail at this stage, resulting in Secure Boot violations, signature validation errors, or boot termination (e.g., access denied / boot failure scenarios).

The successful completion of the “Loading files…” progress indicates that the firmware has accepted the updated boot chain, confirming that the rebuilt WDS infrastructure is now serving 2023-compliant, high-SVN boot components trusted by the platform firmware.

Deployment Automation Handover (MDT WinPE Initialization Phase)

The second stage, represents “Processing Bootstrap Settings” window. This confirms successful transition into the Microsoft Deployment Toolkit (MDT) automation layer within Windows PE.

At this point, WinPE has fully loaded into system memory and initialized its runtime environment, including networking and scripting components required for deployment execution. This action establishes connectivity to the MDT deployment share and initiates task sequence processing. The appearance of the MDT bootstrap window confirms that:

• The custom WinPE environment has executed correctly
• Network and deployment share connectivity has been successfully established
• MDT automation has been triggered without reliance on default regeneration cycles

This validates that the custom WinPE build is fully operational within the updated Secure Boot compliant deployment architecture.

Please see How to Configure and Run Performance Tests in Postman, Deploying Next.Js App Using Heroku Cloud Application Platform, and how to Secure your API key in Postman.

Enable the Secure Boot Revocation (DBX) Update (Optional)

As mentioned above and as discussded in part 1, the below we actually do not need to perform the revocation and SVN update if we are not running into the issue of rollback during deployment. Based on Microsoft’s deployment timeline for the Secure Boot changes (CVE-2023-24932), the actual programmatic enforcement and revocation of the 2011 certificate via the DBX remains an optional.

Before proceeding with the Secure Boot DBX (Forbidden Signature Database) update. It is important to verify that the deployment environment has been fully updated and tested. The DBX update is designed to block vulnerable or deprecated bootloaders and should only be applied after confirming that all deployment components are operating correctly with the updated Secure Boot trust chain.

Based on the work completed so far, the following components have been updated and validated:

• WinPE has been updated and serviced with the required packages.
• WDS boot files and templates have been updated.
• The PXE boot path has been aligned with the updated Secure Boot requirements.
• bootmgfw.efi has been updated where applicable.
• Deployment testing has been successfully completed using both physical and virtual test devices.
• Devices with the Secure Boot 2023 update can successfully PXE boot and be re-imaged from the test WDS environment.

The Secure Boot DBX update can be considered once all of the following conditions have been met:

• PXE booting has been successfully tested end-to-end as shown (tested) above.
• Devices with the Secure Boot 2023 update can boot and deploy successfully.
• Legacy deployment media and outdated boot files are no longer required.
• MDT and WDS deployment workflows have been validated.
• WinPE images have been updated with the latest cumulative and Safe OS updates.
• No deployment issues remain following testing and validation.

When to Delay the DBX Update

The DBX update should be postponed if any of the following conditions exist:

• PXE boot behaviour is still inconsistent.
• Deployment testing has not been fully completed.
• Older deployment media may still be required for operational purposes.
• WDS or MDT infrastructure changes are still in progress.
• Boot files or deployment images have not yet been updated and verified.
• Additional troubleshooting is required before enforcing stricter Secure Boot policies.

Once the deployment environment has been fully validated and all boot paths have been confirmed to function correctly with the updated Secure Boot 2023 certificate chain. The Secure Boot DBX update can be applied with significantly reduced risk. Performing validation before enforcing the DBX update helps prevent deployment interruptions caused by blocked or deprecated bootloaders.

Since we have concluded that the UEFI Forbidden List (DBX) mitigation is used to block untrusted UEFI modules from loading. In this step, updating the DBX will add the “Windows Production CA 2011” certificate to the DBX. This will cause all boot managers signed by this certificate to no longer be trusted.

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates /t REG_DWORD /d 0x80 /f

schtasks /Run /TN "\Microsoft\Windows\PI\Secure-Boot-Update"

Once the Secure Boot DBX (Forbidden Signature Database) update has been applied. The firmware will begin enforcing Microsoft’s updated Secure Boot trust policies by blocking known vulnerable or deprecated bootloaders.

Please see how to Implement Split-Brain DNS Policies in Active Directory, how to convert distribution group to security group, and A Review of MiniTool Partition Wizard – Disk Utility Tool.

Summary

Following validation testing, devices with the Secure Boot SafeOS update applied are now successfully able to PXE boot and complete full operating system deployment from the updated WDS environment. This confirms that the deployment infrastructure is now fully compatible with the 2023 Secure Boot trust chain and updated boot policy enforcement.

Earlier PXE boot failures were caused by a mismatch between firmware-enforced Secure Boot requirements and legacy boot components served by the deployment environment. Specifically, endpoints were rejecting boot execution due to:

• Secure Boot signature validation failures
• Unsupported or legacy 2011-signed boot loaders
• Incompatibility between updated SafeOS firmware policy and outdated WDS/WinPE boot files

Once the WDS, WinPE, and PXE boot chain were updated to align with the Secure Boot 2023 certificate requirements, these issues were resolved and deployment operations completed successfully.

I hope you found this guide on “Secure Boot 2023 Compliance Across WinPE, MDT, WDS, and ADK: Boot Chain Alignment and PXE Validation [Final Part]” very useful. Please feel free to leave a comment below.