Event details
I had exactly the same thought. Current answers below are not completely clear on the long term.
Scott and Richard added some contributions in a related question in the video:
https://www.youtube.com/live/ixq4RP33Am4?si=ccMm0X82PHChs40J&t=2303
From my understanding, it seems quite likely that a future Windows 12 or what ever coming next will REQUIRE Secure boot with the Boot manager signed with the 2023 certs only.
This would mean some older machines what were NOT able to update the certs will NOT be able to install such future version of Windows.
Is that correct?
It could be seen as another way from Microsoft to get rid of older machines.
But for simple people just ok with their current old machines and not willing to buy anything newer e.g. for environmental concerns, it means the end of a supported version of Windows in their machine. Sure, it will happen some times, sooner or later.
But Microsoft could help those people to stay on their older machines if they could sell them more years of ESU (after oct'26, ESU is said to be for business only, NOT for consumers) or even better to make the LTSC editions of Windows 11 (as the 24h2) officially available for those people!
MicrosoftA few clarifications that may help.
The goal here is to keep all supported devices updated with the newer Secure Boot certificates so they can continue to receive boot‑level security updates over time. In most cases this happens automatically. The determining factor is firmware capability, not device age. Older devices, including devices that are no longer in OEM support, can successfully update the certificates as long as their firmware implementation is able to accept them. The main limitation arises when a device’s firmware has an implementation issue that prevents the certificates from being updated, and there is no firmware update available to address it.
If a device can’t install the 2023 Secure Boot certificates, that does not by itself block current Windows feature updates. Those systems will continue to boot and can continue to receive standard Windows updates. What they won’t receive going forward are new boot‑chain security updates, such as Boot Manager updates or dbx revocations, once the 2011 certificates expire.
For future, unreleased versions of Windows, Microsoft hasn’t published specific requirements. That said, devices that can’t update their Secure Boot trust should expect increasing security and compatibility limitations over time as newer operating systems, firmware, and Secure Boot‑dependent protections assume an updated trust foundation.
This work isn’t about forcing device turnover. It’s about making sure systems that are capable of doing so can continue to receive critical boot‑level security updates and stay protected as the threat landscape evolves.
Arden – Microsoft
The determining factor is firmware capability, not device age. The main limitation arises when a device’s firmware has an implementation issue that prevents the certificates from being updated, and there is no firmware update available to address it.
back on the technical side: is there any plan in the update process to better care of those cases with "implementation issue that prevents the certificates from being updated".
As I wrote already 2 months ago in this previous comment, some machines are exactly there, and are just completely freezing when running the task
Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”
You already answered there (thanks!), the consequences are understood.
Today's question is just: Is there any way to prevent the machine to freeze while running the task?
I just tried again the "Device testing using registry keys" from https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d but just surprised to see the current value ofComputer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\
AvailableUpdates to be 0x5946 (while only 0x5944 is documented)
What does the 5946 means?
Anyway, either with value 5946 or 5944, my system still hangs / freezes on the task above.
So I leave the scheduled task disabled.0x0002 means that a DBX update is pending It should get installed automatically by the scheduled task and then the value should return to 0x0000. When your machine reached the value 0x5946, it probably means that it used to be 0x0002 before the last secure boot update has been applied. The last DBX update was issued in October 2025, so either the DBX update has been sitting there unable to be installed for so long, or you recently reset your Secure Boot keys in the firmware.
I would suggest to only set individual bits and see if the scheduled task freezes when you try to do so.
0x0002 Apply DBX update.
0x0040 Apply DB update (Windows CA)
0x5800 Apply rest of the DB updates (Third-Party CA, Option ROM CA) - only if old certificate present. Will go to 0x4000 once done
0x0004 Apply KEK update
0x0100 Update the boot manager (on EFI partition) if all neede certificates are there
After everything that can be has been applied, set the value back to 0 (the scheduled task should then run without issues) and set HighConfidenceOptOut to 1 so that it will not update your Secure Boot keys automatically as part of monthly cumulative updates any longer.
In case 0x0040 freezes as well, could you try (if you feel confident) putting
"C:\Windows\Boot\EFI\SecureBootRecovery.efi" as \Efi\Boot\Bootx64.efi onto a bootable (Fat32 formatted) USB drive and boot from it? That should apply this single update as well, but it will do so from outside of Windows, so that drivers cannot interfere with it.
If you want to, share your results (which updates worked and which froze, and whether it works from SecureBootRecovery).
Out of curiosity:
- What is the value of BucketHash and ConfidenceLevel in
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing registry? The first is a hash of your mainboard model and firmware version and is used for controlled rollout only to known machines. The second is what Microsoft thinks how confident it is that the update will succeed. I would assume the latter being High since you got the update as part of LCU without manually fiddling.
- Do you have any telemetry enabled on your machine?
- Are there any third-party security products (antivirus, firewall) installed on your machine?
- Do you use games that use Anti-Cheat software or any other software that integrates as a low-level driver?
Thanks.
This description of the values should be documented on Microsoft Learn pages!I tried to set 0x0040 and run the task after reboot, but still the same freeze.
As already said last month, I suspect the UEFI is simply badly implemented in regard to SecureBoot. It was one of the very first mainboard with SecureBoot in 2013/14...
So I think this mainboard simply do NOT allow any change in the SecureBoot settings. In the bios itself, there is also no other option than "reset key" to default .
As for Servicing values in Windows re:BucketHash is
90d5affce870e9b93ad23b45571bb389302ade84cbf4da5253d6d709ed043739
- ConfidenceLevel is empty
- UEFICA2023Error and ErrorEvent are 0
- UEFICA2023Status InProgess
- WindowsUEFICA2023Capable is 2
And other parameters:
- Telemetry let to the "Require" setting, I suppose the SecureBoot stuff should be part of it.
- No third party antivirus, only the Microsoft stack. The machine still has win10 22h2 with ESU / March 2026 update
- No gaming on this old machine, so no Anti-Cheat software AFAIK
- Hypervisor activated and virtual box installed
- What is the value of BucketHash and ConfidenceLevel in
This work isn’t about forcing device turnover. It’s about making sure systems that are capable of doing so can continue to receive critical boot‑level security updates and stay protected as the threat landscape evolves.
sure, and we thank you for your effort: I think we are here all very pleased that you and your team are taking care of a smooth process.
However, Microsoft is likely as any big firm: the technical teams may have quite different mid/long-term views than the marketing and top management teams.
When I wrote "another way from Microsoft to get rid of older machines", I thought of those marketing people: I wonder if any of those dare looking here... I just hope that the technical teams like yours could convince them internally to offer other alternatives to long term customers, as those I wrote in the last paragraph: I believe quite some customers will be happy to pay for longer service on their older machine instead of buying new machine. I am thinking especially (but not only) of elderly people like our parent generation that are just not interested of having new stuff and afraid of any change in their daily workflow..
