Since 2024, Microsoft has been gradually rolling out the Windows UEFI CA 2023 certificate update to replace the 2011 certificates used by Secure Boot.
Normally, this migration is transparent to the user. However, some machines remain stuck with 2011 certificates despite the latest Windows updates.
We will analyze a real case on an HP ZBook 15u G3 and show how to precisely identify the cause.
The Context:
The machine configuration:
- Model: HP ZBook 15u G3
- BIOS version: N75 v01.62 (17/03/2024)
- OS: Windows 11 24H2 Build 26200
- Secure boot: Enabled
Checking the UEFI CA 2023 certificate update status:
To check the certificate update status, open Windows settings then navigate to “Privacy & Security > Windows Security > Device security“

According to the Microsoft documentation, you may encounter the following situations related to the certificate update status;
If you see this message in the Secure Boot section What you should do Secure Boot is on and all required certificate updates have been applied. No further certificate changes are needed. No action is needed. Secure Boot is on, but your device is using an older boot trust configuration that should be updated. Make sure your device has the latest Windows updates installed. Restart if prompted. Secure Boot is on, but your device is affected by a known issue. To reduce risk, Secure Boot certificate updates are temporarily paused while Microsoft and partners work toward a supported resolution. The update will resume automatically once resolved. No action is needed. The certificates update will resume automatically once the issue is resolved. Secure Boot is on, but your device is using an older boot trust configuration that should be updated. There is not yet enough data to classify your device for automatic update. Visit the link below for more information. Your device might need additional validation before the update can proceed automatically. Visit aka.ms/getsecureboot for more information. Secure Boot is on, but your device does not support the automated Secure Boot certificate update due to hardware or firmware limitations. Contact your device manufacturer for assistance. Contact your device manufacturer for assistance. Secure Boot is on, but this device can no longer receive required updates for the Windows boot experience. Your device is still using an old certificate after the expiration dates. Visit aka.ms/getsecureboot for guidance.
In the case I encountered, this message indicates that no action is needed, and I have to wait for the certificate update to resume automatically. But I need more details to identify the root cause of the issue preventing this computer from performing the update.
Since the 𝐊𝐁5089549 update, a new folder has been added under the “𝐂:\𝐖𝐢𝐧𝐝𝐨𝐰𝐬\𝐒𝐞𝐜𝐮𝐫𝐞𝐁𝐨𝐨𝐭” that contains scripts to manage expiring Secure Boot certificates.
It contains scripts to help administrators check certificate deployment status and to push certificate updates across the organization’s device fleets.

I will use the “Detect-SecureBootCertUpdateStatus.ps1” to get those details;

Here, I get more details so I can investigate further. The first point to highlight is that secure boot is enabled, it’s the first condition to meet so that the certificate update succeed.
It also appears that Windows initiated the certificate update but failed to complete according to the message: “Update not complete – checking for error events …“
There are two particular event IDs reported that must be checked: event ID 1801 logged 26 times, and event ID 1796 logged 8 times.


The first event 1801, indicates that the secure boot certificates are available but have not been applied!
The second event indicates that the update failed because secure boot is not enabled on that machine. The last event was logged in November 2025.
My next step was to check whether secure boot is effectively enabled by issuing the following command:
Confirm-SecureBootUEFI

Secure boot is enabled on this machine.
Mybe before the 4th november secure boot was disabled, but since then it was enabled.
Checking the registry keys:
The next step is to check the registry keys related to secure boot to get more information, especially the value of the following keys:
- Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates
- Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\ConfidenceLevel
- Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\UEFICA2023Status


The registry key values suggest that the certificate update service didn’t start since secure boot was disabled, but after enabling it Windows should attempt the update process!
Attempts to fix the problem
Changing the registry key values to relaunch the update process
- Change the “AvailableUpdates” key from “0x00” to “0x40” to force Windows to relaunch the update process.
reg add HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates /t REG_DWORD /d 0x40 /f
- Restart the computer
After the computer restarted, I ran the Detect-SecureBootCertUpdateStatus.ps1 PowerShell script again and this time the result came out with a new event ID 1802 (Known Firmware Issue).

The events viewer will tell us more about that event;

The error message clearely indicates that the certificate update fails because of a known firmware issue. So Windows has detected an issue on the computer firmware (BIOS) that prevent it from applying the new secure boot certificate.
Usually, this happens when the firmware is outdated. In this particular case, the firmware was N75 ver. 01.62 released in 03/17/2024
Update the Firmware:
Now that I know that problem is related to the firmware, maybe a firmware update will fix it.
On the HP wabsite, I found a newer firmware available issued on May 2024, just one month newer that the on already installed.

When trying to update the firmware I got the following warning:

It seems that’s the same firmware version.
Conclusion:
If HP will not roll out a new firmware update, the new UEFI certificate can’t be updated.
What are the risks?
The computer continues to boot and run normally, but cannot receive certain security updates. It may also be vulnerable to new bootkit and rootkit exploits.
