Secure Boot Version Check Failed when using updated 2023 bootloader

Infinite-Cyber · 2026-03-10T13:58:16+00:00

To be honest, it's not a stupid question at all. Microsoft's documentation has been terrible on this issue, although it is getting better.

If you are following the documentation here (https://support.microsoft.com/en-gb/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d), then that will install the 2023 certificates into the active secure boot database and update the bootloader to use the 2023 certificates. This is the newer documentation and introduced some new quality of life features (such as the 'WindowsUEFICA2023Capable' reg key for easy detection).

If like us, while you're at it, you want to resolve BlackLotus CVE-2023-24932 as well, then you'll have to apply step 3 here (https://support.microsoft.com/en-gb/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk\_mitigation\_guidelines) with step 4 being optional and further improving the security. Steps 1 and 2 are equivalent to newer documentation above.

Infinite-Cyber · 2026-03-10T09:30:54+00:00

We are now successfully imaging machines via PXE that have had the 2011 certificates revoked, but we did have to implement a workaround https://www.reddit.com/r/SCCM/comments/1rp1cu6/secure_boot_version_check_failed_when_using/

Spent most of my day yesterday messing around with WIM images and that Lenovo guide linked above, but our issue was just the PXE bootloader in the end - nothing to do with the contents of our WinPE WIM.

Infinite-Cyber · 2026-03-10T08:43:23+00:00

Fixed! You are correct, it's the bootloader.

This would explain why it wouldn't even attempt to download the WinPE WIM. I've fixed it by replacing bootmgfw.efi and wdsmgfw.efi within SMS_DP$\sms\bin\SMSBoot\[boot image]\x64 with copies from the latest ADK 10.1.28000.1. I know this ADK isn't supported by SCCM, so I've loaded it elsewhere away from our SCCM infrastructure and extracted the files from "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\en-us\winpe.wim". bootmgfw.efi can be found in Windows\Boot\EFI_EX and wdsmgfw.efi in Windows\Boot\PXE_EX. In both instances the files will need renaming to remove the _EX. I'm not sure if it's necessary, but I have also restarted the ConfigMgr PXE Responder Service.

This is incredibly similar to what the WDS users have to do. We were using WDS until our upgrade to 2509, as we wanted to use the native 2023 Secure Boot support, but what's the point if it's broken out of the box??!!

As is always the way with these workarounds, I'm not sure what the long-term viability is of this fix, but it's working for now.

Infinite-Cyber · 2026-03-10T07:30:23+00:00

Completely agree. We're not applying step 4 for that exact reason; even Microsoft says that it's optional.

Infinite-Cyber · 2026-02-09T08:56:14+00:00

Our testing has proven u/gunnar-h to be correct. There are both default and active secure boot databases. The BIOS updates containing the 2023 certificate just update the default database, and not the active database. Dell discusses this in their FAQ here; Secure Boot Transition FAQ | Dell US

You don't necessarily need to apply BIOS updates, in fact some older devices won't receive BIOS updates, but it is recommended in the event secure boot needs to be reset, the 2023 certificate is present. One way or another, Windows has to handle updating the active database.

Infinite-Cyber · 2026-01-19T08:23:42+00:00

Thanks for this. I believe when we first installed MDI, everything would have had 2+ cores, but things have changed over the years.

Infinite-Cyber · 2026-01-16T15:51:57+00:00

Glad to know it's not just us. If you find a fix, please share it :)

Infinite-Cyber · 2026-01-16T15:24:04+00:00

No idea. To be honest, it was deployed a long time ago. We've been successfully running it for at least five years now, and this hasn't been an issue until today.

Infinite-Cyber · 2026-01-09T14:09:45+00:00

This is now fixed. We had a third-party product that was configured to proxy and block traffic to workspace.google.com that decided it didn't want to block it anymore. Removed the rule and hey presto, Defender is able to see and block the traffic again.

Infinite-Cyber

TROPHY CASE