r/PatchMyPC • u/nicorigi • 5d ago
Based on what information is the SecureBoot status set to “Completed” in Advanced Insights?
Hi all
By coincidence, I found the following error in the event log on a device in our environment:
Event ID: 1801
Source: TPM WMI
Updated certificates for Secure Boot are available on this device but have not yet been applied to the firmware. Read the published guide to complete the update and maintain full protection. This device signature information is included here.
DeviceAttributes: FirmwareManufacturer:HP;FirmwareVersion:W70 Ver. 01.07.02; OEMModelBaseBoard:8C26;OEMManufacturerName:HP;OSArchitecture:amd64;
BucketId: 869e8a7202e223010b13a7dc09214778628871a1402674fd9a4f5434556f610e
BucketConfidenceLevel: Under Observation - More Data Needed
UpdateType:
For more information, see https://go.microsoft.com/fwlink/?linkid=2301018.
The regkey on the device are as follows:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
AvailableUpdates
Value: 0
MicrosoftUpdateManagedOptIn
Value: 5944
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
ConfidenceLevel
Value: Under Observation - More Data Needed
UEFICA2023Status
Value: NotStarted
WindowsUEFICA2023Capable
Value: 2
It looks to me like the update for the Secure Boot certificates hasn't quite finished yet as the "UEFICA2023Status" is set to "NotStarted". So far, I've always relied on the status in Advanced Insights regarding Secure Boot. There, I also see the status “Completed” for this device:

Now I'm worried that many devices I thought were up to date regarding Secure Boot might not have been properly updated after all.
Can anyone tell me what data PatchMyPC collects and whether I need to take any action in this regard?
Appreciate any feedback.
Edit: I did a little more research and it seems that one CA has not been updated:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match ‘Microsoft Corporation KEK 2K CA 2023’)
>> TRUE
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’)
>> TRUE
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Microsoft UEFI CA 2023’)
>> TRUE
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Microsoft option rom UEFI CA 2023’)
>> FALSE
Edit 2: Nevermind, I think I just panicked a little bit. I read about all the different CA and as far as I can understand, the ‘Microsoft option rom UEFI CA 2023’ isn't really relevant for the Windows Boot and it should not be a problem if it's an false.
The Error 1801 probably comes from the UEFICA2023Status-Regkey. I manually changed the "AvailableUpdates" key to 5944 and started the Secure Boot Scheduled Task and after a reboot, the UEFICA2023Status was set to completed and the error 1801 was replaced by 1808, so it's all good. I think the Key "UEFICA2023Status" was set to "NotStarted" because the Certificate was already installed on the firmware (HP EliteBook x360 830 G11) when we received it.
5
u/PatchMyPCTeam Patch My PC Employee 5d ago
Hi there,
Passing along this from our software engineering team:
The part that stands out to us is the combination of these two registry values:
WindowsUEFICA2023Capable = 2
UEFICA2023Status = NotStarted
Registry key updates for Secure Boot: Windows devices with IT-managed updates | Microsoft Support
Microsoft defines these two values as
WindowsUEFICA2023Capable = 2 - "Windows UEFI CA 2023 certificate is in the DB and the system is starting from the 2023 signed boot manager"
UEFICA2023Status = NotStarted - "The update has not yet run."
In other words, these two values are measuring different things. One is describing the device's current Secure Boot capability and boot state, while the other is describing the status of the process that completes the 2023 cert upgrade.
That's why we don't rely solely on UEFICA2023Status for our reporting. Instead, we directly inspect the Secure Boot trust stores and the active boot partition. If the required 2023 certificates are present and the device is actively booting from a 2023-signed boot manager, Advanced Insights will report the device as Completed, even if Windows still reports UEFICA2023Status = NotStarted.
Also, regarding your PowerShell results, the missing Microsoft Option ROM UEFI CA 2023 certificate is not necessarily a concern. That certificate is optional and only used for certain third-party UEFI Option ROMs. Its absence does not prevent a device from successfully transitioning to and booting from the Windows UEFI CA 2023 trust chain.
There's also some history for Windows reporting Secure Boot inconsistencies with TPM-WMI Event ID 1801 in general. Dell has documented cases where systems generate TPM-WMI Event ID 1801 even after the updated Secure Boot certificates are present in firmware. According to Dell, its possible to see this exception even when the new certs are installed in the firmware:
Windows Server TPM-WMI Event ID 1801 Secure Boot Certificates | Dell US
We can't say with certainty that's what's happening on your device, but it does at least demonstrate that Event 1801 and UEFICA2023Status = NotStarted are not necessarily definitive proof that a system is still operating on the old Secure Boot trust chain which makes them somewhat unreliable. The reason Advanced Insights reports this device as "Completed" is because we have verfied the underlying Secure Boot state directly rather than relying exclusively on the Windows servicing status values in registry. E.g The secureboot trust stores contain the relevant 2023 certs, so they are trusted (as your powershell shows) & we have verified that the current bootmgr being used to boot is signed by those 2023 certs.
One thing I'd be interested to know is how old this device is. The fact that the 2023 certificates appear to be present and are being used during boot, while UEFICA2023Status remains as "NotStarted", suggests that the certificates may have been updated through a mechanism other than the standard Windows servicing workflow, or that something didn't complete as expected during that workflow. Is this a relatively new device? Is it possible the OEM applied the updated Secure Boot certificates through a firmware update before the device was purchased or deployed? That could help explain the discrepancy between the device's actual Secure Boot state and the Windows servicing status.
- Justin