Event details
This topic comes right in place to share what I saw on a old computer from 2013.
I read carefully the blog page on the topic: Updating Microsoft Secure Boot keys | Windows IT Pro blog
and the registry key settings:
https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d#articlefootersupportbridge=communitybridge
If I understand properly, the task
Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”
is trying to update the UEFI with the new certificates. It is correct?
BUT the whole is missing a critical scenario: what if the UEFI do NOT support the update of certificates?
On my mainboard from 2013, an Asrock Z87E-ITX, with last bios 2.5 from 2018, out of support from Asrock for years already, running the task is having a very strange behavior on Windows 10 Pro:
- if the wifi is off, I get an error 1801 with "Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware"
- if the wifi is on, the computer is freezing completely (exactly 5 min after start, matching the delay of the trigger in the task), nothing is written is any logs, as if the task trying to touch the UEFI will reach a critical address.
In the bios/UEFI on this machine, there is no way whatsoever to manage the keys and certificates. No way to read (and less to write). It seems Asrock did not implement the SecureBoot completely there...
And there is NO TPM chip on that board...
So next question: what if the certificates are not updated in the UEFI? Should not the update within Windows be enough?
Lots of people are seeing the 'hang/freeze after 5 minutes' (Windows 10) when Task Scheduler runs 'Microsoft\Windows\PI\Secure-Boot-Update'. Numerous people (including me) started seeing this issue after January's ESU KB5073724. Reddit etc. is full of similar stories. I've been getting by by disabling the network (stopping NSI service at startup and enabling after 5 mins). Hopefully Microsoft will pick up on this and resolve things as it's hurting lots of people!
I've added my story to this Windows forum:https://www.tenforums.com/windows-updates-activation/222472-january-2026-esu-kb5073724-windows-freezes-after-4-5-minutes.html
Does it avoid the freeze if you set in registry
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
- AvailableUpdates = 0 (remember the previous value)
- HighConfidenceOptOut = 1 (you may have to create as DWORD if not present)
That way, the scheduled task should not pick up any Secure Boot update and future cumulative updates will not automatically try to install any Secure Boot updates either. On the other hand, you should try manually to install all the ones you can (without freezing) if you intend to have Secure Boot protecting your machine at the same level after June 2026. If you cannot install any of them, leaving Secure Boot on with old certificates is still more secure than turning it off.
Out of curiositry, in
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
Can you look up BucketHash and ConfidenceLevel and post them here? Thanks.
- Arden_White
Microsoft
Hi Eric, I can help clarify this.
Event 1801 indicates that the Secure Boot certificates on the device have not yet been applied. It is marked as an error to make sure it stands out, since having current certificates is important for device security.
Wi‑Fi or network connectivity shouldn’t affect this process. Secure Boot does not rely on the network, and certificate updates do not require network access to complete. The updated certificates were included in last year’s monthly Windows updates, so any device that installed those updates already has the new certificates available.
What remains is the step where Windows applies those certificates to the device’s firmware. That final step can occur in several ways:
- Controlled Feature Rollout for devices receiving Windows Update directly from Microsoft.
- High confidence updates included in monthly cumulative updates for devices that have shown, through observed behavior, that they can successfully apply new Secure Boot certificates.
- Direct configuration by setting the AvailableUpdates registry key, or indirectly through Group Policy or Intune.
I don’t have specific information on ASRock firmware behavior, so I can’t speak to that. A TPM is not required for Secure Boot certificate updates.
After the Secure Boot certificates expire, devices that haven’t received the newer 2023 certificates will continue to start and operate normally, and standard Windows updates will continue to install. However, these devices will no longer be able to receive new security protections for the early boot process, including updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities.
