Early 2026 brings a problem that is easy to overlook if you manage Windows fleets. The original Microsoft Secure Boot certificates from 2011 are coming to the end of their trust period. The Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011 become invalid from June 2026, and the Microsoft Windows Production PCA 2011 follows in October 2026. All of them have to be replaced by the new 2023 CAs. In many of the tenants I support, the situation is messy. There are devices from several OEMs, firmware update histories with gaps, and very little thought given to what happens once the Secure Boot trust anchors actually expire.

Devices keep booting until an update removes the 2011 CAs

First, a common misconception. Devices will not suddenly stop booting on the day the old Secure Boot certificates expire, unless they receive a firmware or DBX update that actively removes the 2011 CAs. As long as no such update is installed, most systems will carry on booting normally, even after June or October 2026. That is exactly why the risk is easy to underestimate. Once a device installs a Windows or firmware update that enforces the new certificate set, any machine without support for the 2023 CAs will fail to boot, often with no warning at all. In mixed fleets where not every device is current, a future rollout can turn into a sudden and very disruptive incident.

Practical tip: Find your legacy devices and check their firmware status before you push updates at scale. Don't wait for everything to break at once.

An inventory of Secure Boot certificates starts with three questions

Inventory is where things usually stall. Most organizations run a mix of OEM brands, models and firmware versions. To actually get a handle on it, you need to know:

  • Which devices have Secure Boot enabled
  • Which certificates are currently in the UEFI database
  • Whether recent firmware or Windows updates have applied the 2023 CAs

Microsoft's documentation on Secure Boot key creation and management and on securing the Windows boot process is a good starting point. In most environments the quickest check is the System Event Log. Filter for the source "TPM-WMI" and Event IDs 1794 or 1795 to see whether the latest Secure Boot certificates have been applied. If you have Intune, Proactive Remediation scripts can collect this for you. If not, a short PowerShell check on the endpoints does the job as well.

Get-WinEvent -LogName System | Where-Object {
  ($_.ProviderName -eq "TPM-WMI") -and ($_.Id -in 1794,1795)
} | Select-Object TimeCreated, Id, Message

Run locally on the device in PowerShell 7 as admin.

OEMs and Microsoft deliver the new certificates through separate channels

The new Secure Boot certificates reach devices through two main routes. Most of the large OEMs (Dell, HP, Lenovo and others) ship firmware updates that add the 2023 CAs and update the DBX where needed. At the same time, Microsoft distributes certificate updates for Windows 10 and 11 via Windows Update. Not every device will pick these up automatically, though, particularly older hardware or machines running custom images. What has worked for me is checking the OEM support matrices against the fleet and running a controlled test group before any wide rollout. Skipping that step is how surprises happen.

The flowchart below shows how certificate updates relate to the boot process:

flowchart TD
  Start["Device boots"] --> UEFI["UEFI Secure Boot checks certificates"]
  UEFI -->|"2011 CA valid"| BootOld["Boots OK"]
  UEFI -->|"2011 CA expired, 2023 CA present"| BootNew["Boots OK"]
  UEFI -->|"2011 CA expired, 2023 CA missing"| BootFail["Boot fails"]
  Updates["Firmware/Windows Update installed?"] -->|"Yes"| CertsUpdate["2023 CA applied"]
  CertsUpdate --> UEFI
  Updates -->|"No"| UEFI

Figure: Secure Boot certificate expiry, device and update flow.

A pilot group has to come before any wide rollout

Take the pilot seriously. Specialist devices, embedded systems and a few unusual OEM product lines tend to be the worst documented, and in my experience they are also the most likely to break when Secure Boot changes. Build a pilot group that includes these edge cases, watch the boot events closely and set up feedback channels so failures surface early. Intune or a comparable management tool helps a lot here, because you can react quickly if a firmware or Windows update bricks a test device. Without central tooling, you fall back on manual sampling and Event Log checks. Before you roll certificate or firmware updates out more broadly, have a rollback plan in place.

I recommend a calm but systematic start in early 2026

Secure Boot certificates 2026 are no reason to panic, but admins do need to move from knowing about the issue to acting on it. In practice that means taking inventory, running pilot updates and documenting exceptions now, in Q1, before the real deadlines arrive. Flag older devices that are close to the end of their lifecycle for a closer look, and pair every rollout with a clear recovery plan. If you start early, you avoid a wave of sudden outages when Microsoft or an OEM eventually makes the new CAs mandatory. I've written more on device lifecycle and update management in my posts on Windows 10 end of support and Windows Autopilot device preparation.