Windows Secure boot updates?

Another simple question - i notice the relevance is only for systems with SecureBoot enabled.

  • should it not be on all systems, so that future enablement will succeed?
1 Like

As Windows 11 requires Secure Boot, the likelihood that it’s not already enabled on a computer that doesn’t already require a LOT of attention is likely pretty low.

Ideally, I would think you would have a policy that is active and targeting devices with Secure Boot enabled so that if it does get enabled but isn't currently it would then get the policy and update the certificates as needed. I don't think these configurations not being there will ever prevent secure boot from being able to be enabled.
This is what Microsoft Documentation states regarding certificates that don't get renewed in time:
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.
Windows Secure Boot certificate expiration and CA updates - Microsoft Support

1 Like

Is anyone encountering errors with the Bigfix secure boot process? I’ve tried it on a few lab computers with mixed results. The computers’ BIOS has been updated to the latest from HP that is supposed to support the secure boot change.

Bigfix Secure Boot fixlet Action 1 completes successfully. Action 2 shows each line completed both in the console and the client log, but the action status shows a failure.

Action 2 calls OS scheduled task "\Microsoft\Windows\PI\Secure-Boot-Update". Scheduled task history shows success as well. Action executed at 2:00:20pm.

There are no errors in the event logs. The only clue is from the analysis which shows “2147500037” for “UEFI CA 2023 Error” column. Google wasn’t helpful. Anyone have any experience or suggestions?

Have the systems been rebooted?

Yes, they’ve been rebooted multiple times.

There is a potential issue with some vmware vm’s updating the KEK CA to 2023

The first command initiates the certificate and boot manager deployment on the device. The second command causes the task that processes the AvailableUpdates registry key to run right away. Normally the task runs every 12 hours. The registry key should quickly change to 0x4100. Rebooting and running task again will cause the boot manager to be updated and the AvailableUpdates to become 0x4000. See Troubleshooting for more details on the how AvailableUpdates behaves.

What is this returning?

values "UEFICA2023Status" of keys "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" of native registry

Microsoft says the “WindowsUEFICA2023Capable” key isn’t for general use, but in my analysis it pretty much line up 1:1 with the “UEFICA2023Status” key.

If “UEFICA2023Status” = “Not Started” then “WindowsUEFICA2023Capable” = “0 - Windows UEFI CA 2023 certificate is not in the DB”

If “UEFICA2023Status” = “In Progress” then “WindowsUEFICA2023Capable” = “1 - Windows UEFI CA 2023 certificate is in the DB”

If “UEFICA2023Status” = “In Progress” then “WindowsUEFICA2023Capable” = “2 - Windows UEFI CA 2023 certificate is in the DB and the system is starting from the 2023 signed boot manager”

This is my analysis.

if (exists value "WindowsUEFICA2023Capable" of key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" of native registry) then (if (it = "0") then "0 - Windows UEFI CA 2023 certificate is not in the DB" else if (it = "1") then "1 - Windows UEFI CA 2023 certificate is in the DB" else if (it = "2") then "2 - Windows UEFI CA 2023 certificate is in the DB and the system is starting from the 2023 signed boot manager" else "Unexpected Value: " & it) of (value "WindowsUEFICA2023Capable" of key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" of native registry as string) else "Key Missing"

Microsoft Reference

WindowsUEFICA2023Capable

REG_DWORD (code)

This registry key is intended for limited deployment scenarios and is not recommended for general use. For most cases, use the UEFICA2023Status registry key instead.

Valid values:

0 – or key does not exist - “Windows UEFI CA 2023” certificate is not in the DB

1 - “Windows UEFI CA 2023” certificate is in the DB

2 - “Windows UEFI CA 2023” certificate is in the DB and the system is starting from the 2023 signed boot manager ​​​​​​​

This is the output of the query and analysis that you’re recommending from my problem lab computer.

q: values "UEFICA2023Status" of keys "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" of native registry
A: InProgress
T: 0.401 ms
I: plural registry key value

q: if (exists value "WindowsUEFICA2023Capable" of key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" of native registry) then (if (it = "0") then "0 - Windows UEFI CA 2023 certificate is not in the DB" else if (it = "1") then "1 - Windows UEFI CA 2023 certificate is in the DB" else if (it = "2") then "2 - Windows UEFI CA 2023 certificate is in the DB and the system is starting from the 2023 signed boot manager" else "Unexpected Value: " & it) of (value "WindowsUEFICA2023Capable" of key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" of native registry as string) else "Key Missing"
A: 0 - Windows UEFI CA 2023 certificate is not in the DB
T: 0.274 ms
I: singular string

This is a view of the registry of that computer as well.

The UEFICA2023Status of “in Progress” should mean that the 2023 cert is in the DB, but the analysis results say the opposite.

I have Vmware Virtual machines that are showing InProgress but have Platform key issues on the vcenter side that we are trying to address. It might help to look at the event logs to see if there is any valuable information in there. try to run this relevance query and see what events come back.

(Source of it, time generated of it, event id of it, description of it) of (records whose ((event id of it is contained by set of (1032;1033;1034;1035;1036;1037;1043;1044;1045;1795;1796;1797;1798;1799;1800;1801;1802;1803;1808)) and source of it = "Microsoft-Windows-TPM-WMI" and now - time generated of it < 7*day) of system event log)

Following up to my posts in early March to share my experience in hopes that it benefits someone.

On some computer models that we have, following the default advice and fixlet that HCL provides has worked fine. However, we have a large set of computers where we had gotten incomplete results (see my prior posts in this thread). This was even after upgrading the BIOS to the latest version that is specifically designed to support Secure Boot. I worked with HP’s upper tier of support to find a solution. In my specific case for HP Engage One Pro model registers, I created a baseline that: 1) disables BIOS password ahead of Secure Boot updates using the HP BIOS configuration tool 2) run HCL’s secure boot fixlet 3) use HP’s BIOS configuration tool to specifically toggle some of the secure boot settings 4) reboot up to five times (for some models) and 5) reenable BIOS password at the end of the process using HP’s BIOS configuration tool.

It’s a bit ugly and takes about an hour to run with all the reboots, but it does work.

This is the HP BIOS config that we used.

createfile until EOF
BIOSConfig 1.0
;
;     Originally created by BIOS Configuration Utility
;     Version: 4.0.32.1
;     Date="2026/03/12" Time="11:10:42" UTC="-4"
;
Windows UEFI CA 2023
	Disable
	*Enable
Microsoft Option ROM UEFI CA 2023
	Disable
	*Enable
Microsoft UEFI CA 2023
	Disable
	*Enable
Ready to disable MS UEFI CA Key
	*Not Ready
	Ready

EOF
1 Like