Microsoft is currently rolling out a phased update to replace aging Secure Boot certificates that have been in use since 2011. As part of this process, Windows Update KB5077181 began collecting device telemetry to determine which machines are eligible to receive the new certificates. If you have been seeing unfamiliar entries in Event Viewer related to Secure Boot, you are likely observing this rollout in progress. This article explains what those logs mean, how to check your current certificate status, and what steps — if any — you may need to take.
Background: Why Secure Boot Keys Are Being Refreshed
Secure Boot is a UEFI firmware feature that prevents unauthorized operating systems and bootloaders from loading during startup. It relies on a set of cryptographic certificates stored in firmware — most notably the db (allowed signatures database) and KEK (Key Exchange Key). The certificates currently in widespread use were provisioned around 2011 and are considered due for rotation from a security hygiene standpoint.
Microsoft has been preparing this transition for some time and is now using Windows Update as the delivery mechanism. The new target certificate is the Windows UEFI CA 2023, which replaces the older Windows UEFI CA 2011 in the firmware signature database.
What KB5077181 Does
KB5077181 does not directly apply the new Secure Boot certificates to your firmware. Instead, it introduces a data collection layer that evaluates each device's update history, hardware compatibility, and OEM support signals. Only after sufficient positive signals are accumulated will a device be deemed eligible to receive the actual certificate update.
This is a deliberate, risk-managed rollout. Applying new certificates to firmware is an operation that, if it goes wrong, can render a system unbootable. Microsoft is proceeding cautiously and relies on OEM cooperation to validate that a given firmware revision supports the new certificate before pushing it.
Understanding Event Viewer Logs
To view the relevant logs, navigate to Event Viewer → Applications and Services Logs → Microsoft → Windows → TPM-WMI. The entries most relevant to this rollout include status fields such as:
- BucketConfidenceLevel: Reflects how confident Microsoft's telemetry system is that the device is ready to receive the update. A value of Under Observation – More Data Needed indicates the device is being monitored but has not yet been cleared for the certificate push.
- AvailableUpdates: A flag indicating which certificate-related updates are available or have been applied. A value of 0x4000 has been observed in cases where the Windows update process has completed successfully.
- A message reading "Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware" indicates that Windows has the new certificate but is waiting on firmware-level confirmation before writing it.
A log entry that simply says "This device has updated Secure Boot CA/keys" in the System log (Windows Logs → System) generally indicates the process has completed for that device.
The presence of an error-style log entry does not necessarily indicate a problem. In many cases, it reflects the intermediate state of an ongoing, multi-phase rollout rather than a failure condition.
How to Check Your Secure Boot Certificate Status
You can verify whether the Windows UEFI CA 2023 certificate is present in your firmware's allowed signature database by running the following command in PowerShell with Administrator privileges:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')A return value of True indicates the certificate is present in the db variable. However, this alone may not confirm that the full update process is complete, as the new boot manager and related components may still be in the process of being applied.
Note that receiving True from this command while still seeing an error in Event Viewer does not necessarily indicate a problem. These two signals can exist simultaneously during the rollout transition period.
BIOS Updates and Secure Boot: Is an Update Required?
This is one of the less clearly documented aspects of the rollout. Some OEMs have released firmware updates that include changes to Secure Boot logic or explicitly support the new certificate database. Whether such an update is required before the Windows-driven certificate process can complete appears to depend on the specific OEM and board.
A few observations that have been reported across different hardware configurations:
- Some users have successfully received the update without any BIOS change.
- Some OEMs (including at least one major laptop manufacturer) have issued firmware updates described as supporting the new Secure Boot certificate, with the update completing afterward.
- Other users on platforms without available firmware updates are still in a Under Observation state.
| Scenario | BIOS Update Needed? | Notes |
|---|---|---|
| OEM has released explicit Secure Boot cert support in firmware | Likely yes | Check OEM changelog for mention of KEK or Secure Boot db changes |
| No firmware update available from OEM | Unknown | Microsoft may still push the update via Windows; rollout is ongoing |
| Update already confirmed via PowerShell and System log | No | Process is complete; no further action required |
Microsoft's own documentation notes that writing keys and certificates directly to firmware carries some risk if performed without OEM validation. As such, it may be reasonable to wait for Microsoft's phased process to complete rather than manually intervening.
What "Under Observation – More Data Needed" Means
When the BucketConfidenceLevel field shows Under Observation – More Data Needed, it means the device is in Microsoft's monitoring pipeline but has not yet cleared the threshold to receive the certificate push. Earlier entries in the log may show an empty BucketConfidenceLevel field, which appears to represent the state before the telemetry process began populating that value.
This state is not permanent. As more update signals accumulate — successful reboots, consistent update history, hardware validation — the system's confidence classification is expected to change. There is currently no publicly confirmed timeline for how long this observation period lasts for any given device.
OEM-Specific Behavior
The rollout is not uniform across hardware. OEMs differ in how they handle Secure Boot key storage in firmware, and some are more conservative about allowing third-party key writes. Reported behavior includes:
- Some OEMs do not want Microsoft signatures embedded directly in their BIOS ROM, which may explain why the automatic Windows-driven process requires OEM sign-off before proceeding.
- Third-party tools (such as Mosby, developed by the Rufus developer) can manually add the new certificate, but doing so typically requires enabling UEFI Setup Mode, which in turn usually involves clearing existing Secure Boot keys. This process is not standardized and varies by OEM.
- Enabling Setup Mode by clearing keys temporarily removes Secure Boot protection, which carries its own risk profile and should be approached with care.
Advanced Status Checking: A More Reliable PowerShell Approach
A common mistake in PowerShell-based certificate checking is testing equality between two states rather than confirming both are explicitly True. For example, the following logic is considered unreliable:
if ($match1 -eq $match2) { Write-Output "PASS" }This returns PASS even when both variables are False — that is, when neither the db nor the dbDefault contains the new certificate. A more reliable check uses an explicit boolean AND:
$match1 = ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023') $match2 = ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbDefault).bytes) -match 'Windows UEFI CA 2023') if ($match1 -and $match2) { Write-Output "PASS" } else { Write-Output "FAIL" }This ensures both conditions are independently confirmed as true. For enterprise environments managing multiple machines, a more comprehensive script that also checks the boot manager version and related components may be appropriate.
How Long Will the Rollout Take?
There is no published timeline from Microsoft specifying how long individual devices remain in the observation state. Some users have reported receiving the update earlier in the rollout cycle, while others on similar or newer hardware are still waiting. Factors that may influence timing include:
- Whether the OEM has submitted compatibility validation to Microsoft
- The device's update history and signal consistency
- Whether a firmware update from the OEM is available and has been applied
Microsoft's official documentation on this topic is available at aka.ms/getsecureboot and aka.ms/securebootplaybook, and includes information on event IDs related to the Secure Boot db and dbx variable update process.
Post a Comment