Event details
54 Comments
Now that the new certificates are landing in DB, the KEK is updating, and the boot manager is being re-signed — the "deployment phase" seems well underway for most of us.
My question is about the timing of the next steps : do the optional ones (old certificate revocation in DBX, SVN update, SBAT, new DBX, ...) have an announced schedule yet? Or are we still waiting for a signal from Microsoft?
On my side, I've been building a PowerShell + XAML utility — initially developed for Lenovo devices, but designed to work on other hardware as well — that lets you visualize all Secure Boot certificate stores, the registry keys and Event IDs that Microsoft asks us to monitor, all without Intune or MDM.
Can't wait to integrate these next steps as soon as they're clarified! 😊
Prabhakar_MSFTMicrosoft
Thank you for your question. Due to the impact to recovery boot media and other external boot sources such as Network boot, the revocation of old 2011 certificate and SVN is not automatically applied to UEFI firmware. Enterprises need to ensure all boot sources have been updated to latest 2023 signed Boot manager before applying the revocations to UEFI DBX.
Thank you for the reply to my previous comment, it really did help. So going back to the testing of the deployment, we have adjusted the key HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates to 0x5944. In doing so we see the key UEFICA2023Status go into InProgress where it has been for the last 2 days. This lead to us looking at Task Scheduler, and finding we are seeing the task failing with EventID's 103 and 202. The operational codes indicate "Run Failure". What should we be looking for when we are seeing these errors?
Don't know if this will make the QA portion of the presentation. We do not currently have inTune, so we are being forced to deploy via GPO. In looking at the latest ADMX files both for Windows Server 2022 and Windows 11 25H2, we are unable to see the Secure Boot options when we go try to pilot this. We are looking at the GPO setting under
Computer Configuration > Administrative Templates > Windows Components > Secure Boot
(Please note, we are taking these instructions from Secure Boot playbook for certificates expiring in 2026)
We were able to get to the Windows components by going to Computer Configuration > Policies > Administrative Templates > Windows Components.When we look in this area, there is no Secure Boot folder in the GPO template with the options we are looking for. What version of ADMX files best accomplishes this deployment?
Microsoft didn't put the link to the latest and required ADMX files. Please use https://www.microsoft.com/en-us/download/details.aspx?id=108428 as they contain the SecureBoot.admx/.adml required to set the GPO.
Curious of Microsoft will roll all the necessary changes into a Windows Update?
The changes have already been part of cumulative updates for a few months now. They are (as of now) just not getting applied to your firmware automatically in most cases. As of January and February CU, on select high-confidence devices they get automatically applied to firmware, and on machines where the updates have been applied on another way (e.g. by installing firmware updates or because the machine shipped with the new certificates) they have been made active in the February CU. Also, on client machines (Windows 10/11) that have telemetry enabled, you can also receive them via Controlled Feature Rollout if Microsoft deems them to be low risk for your machine.
Updating Secure Boot certificates consists of three mandatory and two optional steps:
- Add new certificates to the Secure boot Database (stored in your firmware's flash/NVRAM). This is currently done automatically on high-confidence machines as part of the cumulative update, and can manually be triggered by a registry switch.
- Add new Key Exchange Key (KEK) to the firmware's flash/NVRAM: This requires that the manufacturer of your firmware (the one holding the Platform Key) submits a signed update to Microsoft, which can then be applied to the flash/NVRAM like the step before. Windows updates include several hundred of such KEK updates, and if DB updated has been performed and such a KEK is available for your machine, KEK will be updated as well automatically. (There are various event log event IDs that are logged if this step fails due to missing signature or other reasons)
- Change the bootloader (bootmgfw.efi file) stored in your Efi System Partition (replace the one from c:\Windows\Boot\EFI by the one from c:\windows\Boot\EFI_EX). As of February CU, if the new certificates are in DB (on one way or other), the bootloader will be changed automatically.
Optional steps:
- Add the old DB certificates to the DBX blocklist. This is not applied automatically, only possible via registry key/GPO/... as it has the consequence that "older" Windows install/recovery media (i.e. including everything that you can download right now as .ISO from Microsoft) will stop booting on those machines without manual intervention
- Add extra SVN (Secure Version Number) update to DBX blacklist, blocking bootloaders older than mid of last year. Same as above, the impact would be too high to deploy them now automatically. If you are scared of Black Lotus, you can apply them
The reasons why this is done so cautiously are manifold:
- This is the first time those certificates are updated (since inception of Secure Boot in 2011). Therefore, some firmware implementations have bugs which may result them in freezing or requiring other manual attention when they try to install the Secure Boot updates. Therefore it is too high a risk for Micrsoft to install them unattended on all machines at once.
- Some machines even require a firmware update to make the process work flawlessly. This includes some virtualization solutions, e.g. Hyper-V will ship a fix in March 2026 CU which makes it possible to perform the process inside Hyper-V VMs that have Secure Boot and TPM both enabled. The fix needs to be applied to the Hyper-V host, not to the guests (so it is like a firmware update for the virtual firmware of the virtual machine).
- On some exotic machines where the manufacturers do not exist any longer or have lost their Platform Key secret part (yes also this happens), it will require manual intervention - either go to Firmware Setup and load the new KEK manually - if the firmware provides an option to do so - or install a firmware update. If neither option works for your device, and you have a sufficiently large amount of such devices (or sufficient free time) to justify the effort, it is also possible to set up your own root of trust (Platform Key) and install it to your firmware (unlike installing a KEK this option is required by Secure Boot certification. Of course it does not guarantee that it actually works). Probably something for tinkerers and not something you want to do in a professional/business environment.
Looking forwared to the event, although I will have to watch the recording as I don't have time to attend it.
