The June 2026 Secure Boot certificate transition has passed, but the work of verifying that every Windows device trusts the new 2023 certificates is just beginning. Microsoft’s two 2011 Certificate Authorities—the Microsoft Corporation KEK CA 2011 and the Microsoft UEFI CA 2011—began expiring in June 2026, with the Windows Production PCA 2011 set to expire in October. Yet PCs missing the new trust anchors aren’t crashing in a heap or refusing to boot. Instead, they’ll keep starting and installing ordinary Windows updates just fine. What they won’t get are future signed boot components like boot manager updates, Secure Boot database changes, or revocation lists. The diagnostic indicator that separates a protected machine from a partially blind one is a single registry value called UEFICA2023Status. If you’re an IT pro, you need to look at it now. Even if you’re just a careful PC owner, here’s what’s actually at stake.

Here’s What Changed with Secure Boot Certificates

Secure Boot is a UEFI firmware feature that checks the digital signatures of every piece of code that runs before the operating system loads—the boot manager, early drivers, and the OS loader itself. For a decade, the trust that underpinned those checks came from certificates issued in 2011. Like all digital certificates, they don’t last forever. Microsoft has been methodically rolling out replacements: the Microsoft Corporation KEK CA 2023, the Microsoft UEFI CA 2023, and a corresponding Production PCA.

The June 2026 date wasn’t a hard cut-off where devices suddenly fail. Microsoft’s own documentation, updated in the run-up to the deadline, confirms that “Windows may continue to boot and install standard updates” even without the 2023 certificates. But it also warns that Secure Boot “may no longer be able to validate or protect future updates to early boot components.” In other words, the protective shield around the boot path gradually thins instead of shattering overnight.

That nuance matters because it explains why a lot of systems might show a missing status yet still work—and why complacency is dangerous. The transition is being delivered in phases to eligible devices, and while you wait for the phase to reach your hardware, you’re running a Secure Boot implementation that can only partially enforce its own rules.

What the Transition Means for Your Windows PC

The impact splits cleanly across audiences.

For everyday home users, the most likely outcome is… nothing visible. The phased rollout should eventually land the 2023 certificates through a routine servicing update. But if your machine is older or from an OEM that’s slow to push firmware updates, you might stay stuck in the “not updated” column indefinitely. You won’t notice until you need a major boot component update or until revocations for compromised bootloaders can’t be applied. If you want to know now, you can check one registry value (instructions below). It takes ten seconds.

Power users who tinker with boot configurations, dual-boot Linux, or manage their own firmware settings have more to consider. A device with outdated trust anchors can still pass Secure Boot checks for existing components, but the moment Microsoft signs a new boot manager with the 2023 certificate only, trust breaks. That could manifest as a boot failure, a BitLocker recovery prompt, or a loop that’s hard to escape. Knowing your status helps you plan a maintenance window for the update rather than getting surprised.

For enterprise and IT administrators, the June 2026 milestone marks the moment inventory ceases to be optional. Every unmanaged client, every server, every virtual machine, and every offline asset in a drawer must be classified. Microsoft provides structured event IDs and a registry signal precisely for this purpose. The core question—does this device have the 2023 trust?—is answered by UEFICA2023Status. Anything short of “Updated” means that device belongs in a remediation queue. And the queues aren’t just “needs a restart” or “needs a firmware update”; they include Awaiting Phased Delivery and Offline, each with its own follow-up schedule.

How We Got to the 2026 Deadline

The 2011 certificates weren’t intended to last this long. Like many long-lifecycle infrastructure components, they received extensions while the ecosystem—OEMs, firmware vendors, and Microsoft itself—worked out how to safely replace root-of-trust artifacts in the field without bricking hardware. The rollout was characterized as coordinated certificate management, not a conventional patch check. The update can’t be delivered by a simple Windows Update alone because it requires the firmware to accept new Key Exchange Keys (KEKs) and database entries.

Microsoft began exploring a phased approach as early as 2022, with early previews and out-of-band updates for some Windows 11 devices. The company settled on a combination of Windows servicing updates that place the new certificate payloads onto the disk and firmware-level operations that actually install them into the Secure Boot databases. That’s why a typical “check for updates” might not be enough; a restart is often required to complete the transition, and in some cases a firmware update from the manufacturer is necessary.

The full expiration curve stretches from June to October 2026, with the Production PCA as the final piece. That gives enterprises a few extra months for the last stubborn devices, but the real operational deadline was always June—the moment the trust anchors started expiring.

The One Registry Check Everyone Can Run Right Now

Microsoft exposes the current Secure Boot certificate status through a registry value that’s kept under the Secure Boot servicing provider. It’s simple enough for anyone comfortable launching a command prompt. Open Command Prompt or PowerShell as an administrator and run:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" /v UEFICA2023Status

If the output shows UEFICA2023Status REG_DWORD 0x1 or the text “Updated,” your device trusts the 2023 certificates. Any other result—an empty value, a missing path, or a different number—means the transition hasn’t completed. That’s it. No special tools, no PowerShell coding.

Of course, a single registry value won’t tell you why it’s not updated. For that, you need to consult the Windows System event log. Microsoft defines five events that are directly relevant to Secure Boot certificate servicing:

  • 1808: The certificate update succeeded at some point in the past. This is good evidence, but it doesn’t replace the current status. A subsequent issue could have rolled back the trust.
  • 1800 or 1801: An update is pending or incomplete. Microsoft says the first action is a restart. Often, Windows has already placed the needed files; the system just needs to reboot to commit them.
  • 1803: A required Key Exchange Key is missing. This points to a firmware problem—the platform doesn’t have the right KEK to accept the 2023 certificates. You’ll need an OEM firmware update.
  • 1795: A generic firmware error occurred during the update attempt. Again, a firmware update from the manufacturer is the likely path.

These events, combined with the current UEFICA2023Status, give you a complete picture. And if you’re an IT admin staring at a fleet of hundreds or thousands of machines, you’ll want to collect both in bulk.

A Roadmap for Fleets: Remediation Queues Explained

The operational response to June 2026 is a four-step loop: inventory, classify, remediate, verify. Here’s the queue-based logic that has been tested across enterprise deployments and is reflected in Microsoft’s own Secure Boot playbook.

Step 1: Build the inventory. Collect the current UEFICA2023Status and all recent Secure Boot events (1795, 1800, 1801, 1803, 1808) from each device. For a small number of machines, you can do this manually with Event Viewer’s filter (Windows Logs > System, event IDs as above). For fleets, you’ll use PowerShell remoting or your existing endpoint management tool. The key is to record the status alongside the event IDs and timestamps so you can trace the history.

Step 2: Apply the decision table. Once you have the evidence, place each device into one of these queues:

  • Updated: UEFICA2023Status = Updated. Declare done.
  • Restart Required: Events 1800 or 1801 are present, but status is not Updated. Schedule a normal restart during the next maintenance window. After reboot, recollect status.
  • Missing KEK: Event 1803 is present, status not Updated. Check the manufacturer’s website for a firmware update that adds the required KEK. Pilot it, then deploy.
  • Firmware Error: Event 1795 is present, status not Updated. Obtain the latest BIOS/UEFI firmware, verify BitLocker recovery keys are accessible, and update during a controlled window.
  • Awaiting Phased Delivery: The device is reachable, eligible, and has none of the above events, yet status is not Updated. This is a temporary bucket. These machines are likely still in the phased rollout queue. Keep them updated with Windows servicing, set a recheck date, and monitor. Do not treat them as compliant.
  • Offline: The device can’t be contacted. Record its last known state, chassis type, and BitLocker recovery readiness. Schedule a reconnect. Until you collect a fresh status, you have no proof it’s secure.

Step 3: Execute the remediation. For Restart Required machines, confirm BitLocker recovery keys are available and reboot. For firmware-related queues, work with OEMs. Never manually delete 2011 certificates or reset Secure Boot keys unless the OEM’s instructions explicitly tell you to—a premature revocation can cause boot loops.

Step 4: Recollect and verify. After any action, run the registry check again and review the events. Only a confirmed “Updated” status moves a machine out of the queue.

This process applies to physical systems and to Windows virtual machines. VMs, including those on Azure Local, must be checked from inside the guest. Don’t assume that a Generation 2 VM or a host with Secure Boot enabled means the guest is fine. For Azure Local instances created before October 2024, Microsoft has a specific documented procedure that involves checking for the presence of the 2023 DB and KEK certificates inside the VM. Follow that guide; don’t substitute generic PowerShell one-liners.

What’s Next for Secure Boot After 2026

The October 2026 expiry of the Windows Production PCA 2011 will close the initial transition window. After that, Microsoft may begin revoking the 2011 certificates more aggressively, especially if new bootkits target the old trust chain. The company has repeatedly stated its intent to eventually remove the expired CAs, but it has not announced a date for that removal. In practice, the June-through-October period is the soft enforcement window. Enterprises that haven’t finalized their inventories by fall risk a sudden enforcement action that could break boot chains on unprepared machines.

For now, the most useful fleet metric isn’t how many devices have the latest cumulative update. It’s the count of devices with a current, verified UEFICA2023Status of “Updated.” Everything else is a work item. With a simple registry query and a handful of event IDs, you can turn an abstract certificate deadline into a clear, auditable project. And for individual users, ten seconds at a command prompt can give you peace of mind—or a heads-up that it’s time to plan a firmware refresh before the shield thins any further.