Secure Boot 2023 and ConfigMgr Boot Images - Reference and Troubleshooting

This is the reference post for the Secure Boot 2023 and ConfigMgr Boot Images series. It is not part of the walkthrough. If you are working through the boot infrastructure, follow the deep dives in order. Come here when you need to look up which device can boot which image, decode a version screen, check a file, or work out why a PXE boot went nowhere.

I measured every value here in September and October 2026, against the September 2026 and October 2026 cumulative updates. Those are KB5129195, which has the same boot files as Patch Tuesday’s KB5124008, and KB5127648. The ADK values apply to both the December 2024 (10.1.26100.2454) and September 2026 (10.1.26100.9457) ADKs, which ship the same winpe.wim. The numbers move monthly, but the method does not.

Who can boot what

Firmware verifies the boot files a client runs against its DB and DBX. Those are the PXE network boot program and boot manager, or EFI\Boot\bootx64.efi from USB. Each file also checks its own version against the floor. The serving side knows nothing about the client, so the image or media determines the outcome for every client that uses it.

How to read the table:

• “Old version” is the unpatched ADK’s _EX files, an older ISO root bootmgr.efi, Windows Server 2025’s boot_EX copies, or a previous month’s image. “Current” is patched with the month’s cumulative update.
• Only the 2011 CAs means the device has not had Step 1, or its firmware rejected it. The 2023 CA arrives with Step 1, Steps 1 and 2, or the OEM’s firmware defaults.
• Step 3 puts PCA 2011 in the DBX and sets a boot manager floor of 5.0 (3.0 for the PXE loader and the DVD boot stub). Older months’ files, such as a 9.0 boot_EX copy or an August OS image, still boot.
• Step 4’s floor is the SVN of the boot manager installed when it last ran, 11.0 on September 2026 builds and 12.0 after a re-run on October’s. Updates don’t move it, but the next re-run does, and then the image must be at least that SVN.

A signature refusal is silent. From PXE and from a DVD, the firmware moves on to the next boot entry, and from USB the Dell fell into SupportAssist. Configuration Manager CD/DVD sets are refused this way on Step 3 devices, even when every boot file on them is 2023-signed, because the ISO’s El Torito loader is PCA 2011. The decoder below says which file printed each pair of version numbers.

A task sequence reaches revoked devices too. Apply Operating System runs bcdboot, which put the OS image’s 2023-signed boot manager on the disk of every device that trusted the 2023 CA. The first restart then only needs the image’s SVN to clear the floor. An August 2026 image (9.0) started on a Step 3 device and stopped with “9.0 vs 12.0” on a Step 4 device at 12.0. The Steps 3 and 4 post has the details.

I verified the table on one Dell client and on three Hyper-V VMs, at Steps 1 and 2, Step 3 only, and Steps 3 and 4. The first row is the exception, because I could not observe it.

I observed the last row on the Steps 3 and 4 VM at floor 12.0. With Secure Boot off, it booted the 2011 loaders and the unpatched ADK’s 2023 loaders with no version screen, and it kept its floor. The SVN check is part of Secure Boot.

The DB lives in firmware NVRAM. Reimaging does not remove the 2023 CA, but a firmware “restore factory keys” can.

On HP the sources differ. HP’s support page (July 10th, 2026) says the defaults on models from 2021 and earlier hold only PCA 2011. HP’s answers at Microsoft’s OEM Secure Boot office hours five days later say the latest BIOS adds the 2023 CA to the defaults on commercial models from 2019 on. The exception is the EliteBook 840 G5 and older. Check dbDefault on the device before a reset (the command is under Verification commands below).

The version screen decoder

Every “Secure boot version check failed” screen is printed by the file that failed, and the PXE loader and the boot manager are checked separately with their own numbers. The full screen reads:

Security Error: Secure boot version check failed.
Your system security may be compromised!

Current version: 2.0 - Minimum allowed version: 11.0
Visit https://aka.ms/secure-boot-version-violation for more information.

The system will shutdown in 10 seconds.

The first number is the failing file’s own version. 1.0 is always the ADK’s PXE loader. Any other number is the SVN of the update era the file came from, and the moment says which file it is:

• Before the “Press ENTER” prompt, it is the PXE loader.
• After the prompt, over PXE or from USB, it is the boot manager.
• From a DVD, it is the bootmgr.efi at the ISO root.
• At the first restart after Apply Operating System, it is the boot manager bcdboot took from the OS image.

The second number, the minimum, is the device’s floor for that file. It is 5.0 after Step 3 alone on a device with an April 2026 or later update (KB5025885). After Step 4, it is the SVN of the boot manager installed when Step 4 last ran, 11.0 on September 2026 builds and 12.0 after a re-run on October’s. It doesn’t rise with the device’s updates.

The PXE loader’s 3.0 reads the same on Step 3 and Step 4 devices because it is a separate entry. The SVN payload Step 4 writes carries three floors, the boot manager’s SVN plus 3.0 each for the PXE loader and the DVD boot stub. The two 3.0 entries have not changed since the first payload in July 2024.

The payload has lagged the boot manager once, on the 6.0 builds of May and June 2025, which shipped with a 5.0 payload. A device that ran Step 4 on them has a 5.0 floor.

File sizes, versions, and signers

Sizes are the fastest tell in a folder listing. The 2023-signed file is smaller than its 2011 twin at the same patch level. The difference is 48 to 280 bytes for the boot manager and 144 to 672 for the PXE loader, across the ADK and every update since July 2024.

October 2026 (KB5127648) moved the 2023 boot manager to 3,086,680 bytes, 10.0.28000.376, SVN 12.0, and the root bootmgr.efi to 3,072,024 bytes, SVN 12.0. The PXE loader didn’t change. Later months are in the tracker.

Read the version from FileVersionRaw, never from the FileVersion string, which a neighboring .mui file can supply (the same boot manager reads 10.0.28000.342 inside the WIM and .367 once staged). Read the signer from the file’s embedded signature, never from Get-AuthenticodeSignature, which returns the catalog signer on a host with the same cumulative update installed.

Where the two verified files live

Package flags

SMS_BootImagePackage.PkgFlags on a boot image, as seen in my lab:

The 0x100 bit survives a site upgrade. The rebuilt default images kept it on both of my lab sites going from 2603 to 2609.

Get-CimInstance -Namespace "root\sms\site_<SiteCode>" -ClassName SMS_BootImagePackage |
    Select-Object PackageID, Name, @{n='Flags';e={'0x{0:X}' -f $_.PkgFlags}},
        @{n='Loader2023';e={($_.PkgFlags -band 0x100) -ne 0}}, @{n='PXE';e={($_.PkgFlags -band 0x400) -ne 0}}

Verification commands

Staged loaders on the responder.

$svc = (Get-CimInstance Win32_Service -Filter "Name='SccmPxe'").PathName -replace '^"([^"]+)".*$','$1'
$SmsBoot = Join-Path (Split-Path $svc) 'SMSBoot' # beside sccmpxe.exe on a site server DP and on a remote DP alike; never from the Identification key
Get-ChildItem $SmsBoot -Recurse -Filter *.efi | ForEach-Object {
    [pscustomobject]@{
        Path    = $_.FullName.Substring($SmsBoot.Length)
        Size    = $_.Length
        Version = [string]$_.VersionInfo.FileVersionRaw
        Signer  = ([System.Security.Cryptography.X509Certificates.X509Certificate2]::CreateFromSignedFile($_.FullName)).Issuer -replace ', O=.*$', ''
        SHA256  = (Get-FileHash $_.FullName -Algorithm SHA256).Hash.Substring(0, 8)
    }
} | Format-Table -AutoSize

Shared loaders on a WDS DP.

$RemInst = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSTFTP').RootFolder
Get-ChildItem "$RemInst\SMSBoot\x64\*.efi" | Select-Object Name, Length, @{n='Version';e={[string]$_.VersionInfo.FileVersionRaw}},
    @{n='Signer';e={([System.Security.Cryptography.X509Certificates.X509Certificate2]::CreateFromSignedFile($_.FullName)).Issuer -replace ', O=.*$',''}}

What the responder served (the script takes the newest SMSPXE.log of the two possible locations).

$Install = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\SMS\Identification' -ErrorAction SilentlyContinue).'Installation Directory'
$dirs = @(if ($Install) { Join-Path $Install 'Logs' }) + @(Get-PSDrive -PSProvider FileSystem | ForEach-Object { Join-Path $_.Root 'SMS_DP$\sms\logs' })
$log = Get-ChildItem -Path $dirs -Filter smspxe.log -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 1 -ExpandProperty FullName
Select-String -Path $log -Pattern 'BootFile: [^,]|end of file|cannot open|redirected to' | Select-Object -Last 8

A cannot open smsboot\<PackageID>\x64\boot.stl line is normal. Every 26100-era boot manager asks for EFI\Microsoft\Boot\boot.stl, Configuration Manager never stages it, and the boot continues.

What WDS served.

Get-WinEvent -LogName 'Microsoft-Windows-Deployment-Services-Diagnostics/Operational' -MaxEvents 400 |
    Where-Object { $_.Id -in 4099, 4100 } |
    Select-Object TimeCreated, Id, @{n='Transfer';e={ ($_.Message -replace '\s+',' ') -replace '^.*Client IP:','Client IP:' }} |
    Select-Object -First 12

Media.

$iso = 'C:\Temp\media.iso'
$drv = (Mount-DiskImage -ImagePath $iso -PassThru | Get-Volume).DriveLetter
Get-ChildItem "${drv}:\EFI" -Recurse -Filter *.efi | Select-Object FullName, Length,
    @{n='Signer';e={([System.Security.Cryptography.X509Certificates.X509Certificate2]::CreateFromSignedFile($_.FullName)).Issuer -replace ', O=.*$',''}}
Get-Item "${drv}:\bootmgr.efi", "${drv}:\EFI\Microsoft\Boot\boot.stl" | Select-Object FullName, Length, @{n='Version';e={[string]$_.VersionInfo.FileVersionRaw}}   # the ISO root loader (read its SVN with the cjee21 tool) and boot.stl
Dismount-DiskImage -ImagePath $iso | Out-Null

For an ISO, also pull the El Torito loader, the only file the firmware checks on a DVD boot. 7z l -tIso <iso> lists [BOOT]\2-Boot-NoEmul.img. Its first 1,474,560 bytes are the efisys*.bin floppy image, and 7z x -tFat on that slice yields EFI\BOOT\BOOTX64.EFI, the cdboot loader. Read its signer the same way. If it is PCA 2011, the ISO is refused as a DVD on Step 3 devices, whatever the other files say.

Security Version Number. The SVN lives in a BOOTMGRSECURITYVERSIONNUMBER resource inside the boot manager. cjee21’s Check-UEFISecureBootVariables includes a Get-BootMgrSecurityVersion module and a “Check EFI file info” script that read it along with the embedded signature. The reader finds nothing in wdsmgfw.efi, which has no such resource, because its number is compiled in.

The floors themselves are readable. The update’s SVN payload, C:\Windows\System32\SecureBootUpdates\DBXUpdateSVN.bin, is a signed dbx write holding three entries. They are the boot manager’s SVN, 3.0 for the PXE loader, and 3.0 for the DVD boot stub, and Get-SecureBootSVN reports the first as StagedSVN.

The device.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Windows UEFI CA 2023' # Step 1 done
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Windows Production PCA 2011' # Step 3 done
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbDefault).bytes) -match 'Windows UEFI CA 2023' # a factory-key reset keeps the 2023 CA
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' | Select-Object UEFICA2023Status, WindowsUEFICA2023Capable
Get-SecureBootSVN # FirmwareSVN 5.0 after Step 3 alone; after Step 4, the SVN it last wrote

Do not use Get-AuthenticodeSignature X:\Windows\Boot\EFI\bootmgfw.efi inside WinPE as evidence. That file is the WIM’s copy and says nothing about the boot manager the firmware executed.

Registry bits and events for the revocation steps

Relevant errors:

• 1795 - the firmware rejected the write.
• 1797 - the revocation was blocked because the 2023 CA is not in DB.
• 1798 - the revocation was blocked because the boot manager is not 2023-signed.
• 1801 - the certificates are available but not applied, and admin action is needed.

Symptom table

On the client or the device

On the distribution point

Media builds, tooling, and upgrades

Recurring tasks

Where to go next

• The boot manager SVN history and the values that change every month: the release tracker
• Microsoft’s hub for the certificate transition: aka.ms/GetSecureBoot, and the revocation guidance in KB5025885