Microsoft’s phased replacement of the aging Secure Boot certificate chain — the move from the 2011 trust anchors to the
Windows UEFI CA 2023 family — is now visible in Event Viewer and Windows update notes, but you don’t need to panic. The logs many people see right now (TPM‑WMI entries such as Event ID 1801 with messages like “BucketConfidenceLevel: Under Observation – More Data Needed”) are informational status signals from Windows’ staged rollout and compatibility checks — not evidence that your machine has failed Secure Boot. Microsoft is preparing, staging, and only later applying new certificates into firmware; you can verify that progression safely with a couple of built‑in tools and a brief PowerShell check. Practical verification steps, what the Event Viewer messages actually mean, and the right actions for home users and IT administrators follow below. t.com]
Background / Overview
Secure Boot is a UEFI feature that prevents untrusted firmware, drivers, and bootloaders from running before Windows starts. The platform’s trust is rooted in X.509 certificates stored in firmware variables (PK, KEK, DB, DBX). Microsoft and OEM partners originally provisioned a set of Microsoft CA certificates beginning in 2011. Those 2011‑era certificates are time‑limited and begin to expire in 2026. To preserve pre‑boot security and maintain the ability to deliver new signed boot updates, Microsoft produced a replacement family of certificates (the
2023 CA family) and has been rolling them out through a coordinated, phased process that involves both Windows updates and OEM firmware cooperation. Microsoft’s official guidance and KB notes describe the CA mappings, the rollout mechanics, and the event codes Windows emits during the process.
Why the change matters now: the older CA lifetimes lapse across the summer and autumn of 2026 (different 2011 certificates expire in June vs. October 2026 depending on purpose). If devices fail to receive the new CA entries, they risk losing the ability to accept future DB/DBX/boot manager updates and could drift into a degraded pre‑boot security posture over time. Microsoft and OEMs are deliberately staging updates to avoid mass disruption; many modern devices shipped since 2024 already include the 2023 certificates in firmware.
What you’re seeing in Event Viewer — and what it means
TPM‑WMI logs are telemetry and gating signals, not immediate failures
If you opened Event Viewer and saw entries from the
Microsoft‑Windows‑TPM‑WMI provider (often labeled TPM‑WMI) such as Event ID
1801 or messages containing “BucketConfidenceLevel: Under Observation — More Data Needed”, Windows is logging device readiness and telemetry confidence for the certificate rollout. Those messages indicate:
- Windows has detected that new Secure Boot certificates are available to the operating system (they may be staged inside the OS), but
- The new certificates have not yet been written into firmware (NVRAM) on that machine, or Microsoft has not yet given the device a high‑confidence flag to proceed with the firmware write.
Event ID 1801 specifically means “Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware.” This is an error‑level log entry by classification, but in practice it’s a
status entry used to track devices that are mid‑transition. Do not automatically interpret it as a broken TPM, corrupted BIOS, or failed Secure Boot. Many devices will stay in this staging state for days while Microsoft collects signals and vendors validate OEM model compatibility.
Events that show successful application
Once the firmware write and boot manager swap complete, you’ll see informational events confirming success:
- Event ID 1034 — “Secure Boot Dbx update applied successfully” (DBX updates).
- **Event oot Db update applied successfully” (DB updates).
- Event ID 1808 — informational event indicating the device has the required new Secure Boot certificates applied and the boot manager has been updated to a 2023‑signed bootmgfw.efi. This event can include a BucketConfidenceLevel value like support.microsoft.com]
If Event Viewer shows Event ID 1808 and/or 1036/1034 after you see staging logs, that confirms the firmware-level application finished successfully.
Simple, safe checks you can run right now (no firmware changes)
If you want to verify whether your machine has the new
Windows UEFI CA 2023 certificate in its Secure Boot database, do this — it is completely read‑only and safe.
- Open an elevated PowerShell or Windows Terminal as Administrator (right‑click Start → Windows PowerShell (Admin) or Terminal (Admin)).
- Run the verification command exactly as shown:
:ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
- Output: True if the certificate string is present in the currently active DB.
- if the DB does not show the 2023 certificate.
Notes on the check:
- The command queries the Secure Boot DB variable from the OS via the Get‑SecureBootUEFI cmdlet and converts the returned byte blob to ASCII, then uses a simple regex match for the certificate name string. nything to firmware; it only inspects OS‑visible variables.
- If you want to confirm whether the firmware’s default DB (the DB baked into firmware and persistent across a factory reset of the Secure Boot variables) contains the 2023 certificate, run the same commath
dbdefault:
:ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
A True there means the certificate is already embedded in firmware and will survive a reset of keys. A False means the firmware itself doesn’t contain the new CA and will rely on OS‑initiated writes or a firmware update from your OEM.
Quick checklist after running the Pow command returns True: your OS has the 2023 CA present in the DB and your system is ready for the boot manager swap (if not already done). Event Viewer staging messages can be safely ignored once this is True.
- If the command returns False: your device simply hasn’t been staged/applied yet. No immediate action is required; this is expected during the phased rollout. Check for Windows cumulative updates and OEM firmware updates to ensure your device becomes eligible.
How to verify the transition in Event Viewer (if you want the logs)
If PowerShell showed True and you prefer to verify via official event logs:
- Open Event Viewer (search Start for Event Viewer).
- Go to Windows Logs → System.
- Click Filter Current Log… on the right pane.
- In Event sources, check TPM‑WMI or Microsoft‑Windows‑TPM‑WMI and click OK.
- Look for:
- Event ID 1808 — confirms the new CA and boot manager update applied to firmware.
- Event ID 1034/1036 — DB/DBX applied successfully.
- Event ID 1801 — indicates certificates are available in the OS but not yet applied to firmware (staging/queue).
Important: these logs can appear out of sync. It’s normal to see True in PowerShell while Event Viewer still reports staging messages. The OS can stage the certificate blobs long before the firmware write happens.
Which Windows updates and KBs matter (what Microsoft shipped)
Microsoft has included the device targeting and servicing logic for this rollout in Windows cumulative updates released in early 2026. The February 2026 cumulative updates (for example,
KB5077181 for 24H2/25H2 builds and
KB5075941 for 23H2) contain logic and components that perform the
boot manager swap and control the staged certificate pipeline on eligible devices. In practice, the update flow is order‑sensitive:
- Add DB entries (new CA certificates),
- Add KEK entries if OEM PK‑signed KEK material is available,
- Replace the Windows boot manager (bootmgfw.efi) with a binary signed under Windows UEFI CA 2023 — but only on devices that already trust the 2023 CA.
Because Microsoft uses targeted gating (“device confidence” and telemetry), not every device receives the firmware write immediately after installing the KB; many devices will be staged and queued while Microsoft and OEMs validate telemetry signals.
Caveat: a small number of users have reported other side effects or update-related problems with February packages on certain hardware; if you encounter startup failures after installing these updates, you may need to follow Microsoft’s rollback and recovery guidance or contact OEM support. Always check the specific KB release notes for known issues relevant to your OS build.
Firmware, OEM coordination, and when to update BIOS/UEFI
A fundamental reality: Microsoft cannot blindly write firmware across all PC models without OEM cooperation. The Secure Boot variables (PK/KEK/DB/DBX) live in platform NVRAM under the firmware vendor’s control. Some machines disallow OS‑initiated KEK writes or require a PK‑signed KEK blob from the OEM. For those devices, the OEM must publish a firmware update (or provide signed KEK material) that allows the OS‑side enrollment to proceed. If Windows reports Event ID 1802 or 1803, it means the firmware intentionally blocked the update due to model‑specific concerns or missing PK‑signed KEK data. In such cases, contact your device manufacturer or check their support product pages for a firmware update that bakes the 2023 certificates into firmware.
When should
you update BIOS/UEFI manually?
- Only if your OEM explicitly instructs you to install a firmware update that contains the 2023 certificates or fixes Secure Boot enrollment issues.
- If Microsoft/OEM guidance for your model identifies a required minimum firmware revision.
- If your machine shows repeated firmware write failures in the Event Log and vendor support recommends a particular BIOS revision.
Do not perform risky workarounds such as clearing Secure Boot keys, toggling
Setup Mode, or manually modifying KEK/DB entries unless you are an experienced administrator and you have tested recovery paths. Incorrect firmware operations can make a PC unbootable or trigger BitLocker recovery. If you use BitLocker, back up and confirm recovery key access before performing firmware or key operations.
IT administrator guidance: fleet checks and remediation playbook
For administrators managing large fleets, Microsoft provides a deployment playbook and PowerShell examples for automated verification and telemetry collection:
- Inventory devices with Secure Boot enabled and record firmware versions and OEM models.
- Verify Secure Boot enablement via Confirm‑SecureBootUEFI on each device (returns True/False). The Microsoft docs include guidance on using Intune/SCCM/ConfigMgr to run checks at scale.
- Prioritize BIOS/UEFI updates on models the OEM identifies as requiring a minimum revision.
- Use Windows Update for Business, WSUS, or your management tooling to ensure the ordering of OS servicing + firmware updates is correct.
- Monitor event logs (TPM‑WMI events like 1034/1036/1808/1801) to confirm which machines have written the new DB/DBX/KEK entries and which are still observed/blocked.
For edge cases (air‑gapped servers, highly regulated endpoints, or devices that block telemetry), plan a manual enrollment or OEM firmware update path and prepare recovery media/steps. Prepare BitLocker recovery keys in advance; the Secure Boot enrollment flow can temporarily put BitLocker into recovery if keys or protectors aren’t accessible during firmware changes.
Common questions and quick answers
- Will Event ID 1801 or similar logs brick my PC?
No. They are informational staging logs indicating cert in the OS but have not yet been written to firmware. They’re part of Microsoft’s phased rollout and telemetry gating.
- If PowerShell returns True, do I need to do anything else?
Generally no. If :ASCII.GetString((Get‑SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023') returns True, your DB already contains the 2023 CA and you are ready; firmware application or boot manager swap may follow automatically. Event Viewer logs can be ignored once this shows True.
- Should I uninstall the February 2026 patches if I see problems?
Only as a last resort. If you get boot problems after an update, consult the KB release notes, check for documented known issues, and follow Microsoft/OEM recovery guidance before rolling back. If a rollback is necessary, remember updates may reinstall automatically unless you pause updates.
- I run Linux or dual‑boot — am I affected?
Yes, potentially. The certificate chain is used by shim and other boot components common to Linux Secure Boot deployments. Linux vendors have been coordinating upder the 2023 CA family. If you removed Windows entirely you may not receive OS‑driven updates; check your motherboard/OEM firmware or Linux distro guidance.
Risks, edge cases, and things to watch for
- NVRAM fragmentation and variable space: older motherboards with limited NVRAM may fail to accept DB/KEK writes until the firmware keys are reset or a vendor fix expands usable space. Resetting keys is nrce Secure Boot reconfiguration and BitLocker recovery. Always back up keys.
- Telemetry gating: devices that block diagnostic data or are air‑gapped may not be targeted automatically for the OS‑driven enrollment and may require manual intervention via OEM updates. Plan ahead for regulated fleets.
- Option ROM vs. bootloader trust separation: Microsoft split the 2011 Option ROM anchor into two 2023 CA variations (one for bootloaders and one for option ROMs) to enable finer trust control. On some platforms, administrators may choose to add only the option ROM CA if they need to trust option ROMs without expanding bootloader trust. That nuance can matter in specialized environments.
Flagging unverifiable claims: community posts and early reports may describe device‑specific oddities (startup loops, SENS errors, or update‑related error codes). These are model‑specific and changing — always check the KB release notes and OEM advisories for confirmed behavior and fixes before acting. If you see unusual startup issues after a particular KB, treat the OEM/MS KB pages and support channels as the authoritative sources.
Practical, conservative recommendations
- Run the PowerShell DB check now. It’s fast and read‑only: :ASCII.GetString((Get‑SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'). If True, you can relax; Windows has the new CA in the DB.
- Keep Windows Update enabled and install cumulative/security updates from Microsoft. The OS‑side components that manage certificate staging and enrollment ship via these packages.
- Check your OEM support site for firmware/BIOS updates and model advisories. Install manufacturer‑published firmware only when they state it contains the 2023 certificates or fixes Secure Boot enrollment issues.
- Back up BitLocker recovery keys (Azure AD, AD, or securely stored offline) before performing firmware updates or attempting manual Secure Boot key resets. Suspend BitLocker for two restart cycles if performing an operation that might trigger recovery.
- For administrators: automate the Confirm‑SecureBootUEFI and DB/DBDefault checks and report results into your management console (Intune, SCCM, ConfigMgr) so you can track which machines are staged, which have firmware‑embedded 2023 CAs, and which need OEM firmware intervention.
Bottom line
Microsoft’s Secure Boot certificate refresh is necessary maintenance — it replaces 15‑year‑old trust anchors with a modern CA family so Windows can keep protecting pre‑boot components and deliver new signed boot updates beyond 2026. The Event Viewer warnings many of you see are part of a cautious, telemetry‑driven rollout and are not an immediate sign of failure. Do a quick, read‑only PowerShell check to confirm whether your machine already has the
Windows UEFI CA 2023 certificate in the DB. If it’s present, you’re set. If not, keep Windows and firmware updated, back up BitLocker keys, and follow your OEM guidance; IT administrators should automate validation across fleets and use Microsoft’s monitoring events to track progress and troubleshoot any model‑specific blocks. In short: verify, prepare, and avoid risky manual key edits — the ecosystem is working behind the scenes to minimize disruption while preserving Secure Boot protection.
Source: Windows Latest
How to check if Windows 11 has applied the new Secure Boot 2023 certificates (replaces Secure Boot 2011)