Secure Boot certificate chains have rarely been near the top of any admin's priority list. That has changed. The Microsoft Corporation KEK CA 2011 and UEFI CA 2011 certificates expire this month (June 2026), and the Secure Boot KEK expiry is now an urgent topic. For device fleets this is more than a theoretical cryptography update. It decides whether Windows, VMs and even Linux dual-boot setups stay updatable and secure when the next round of UEFI and bootloader changes arrives. I've already seen plenty of confusion, usually when updates or recovery images suddenly won't install on devices with stale firmware or without the new certificates.

Secure Boot KEK expiry breaks future updates but not existing installs

From now on, any device that relies only on the 2011 KEKs will have problems with new UEFI DBX (revocation list) updates, future firmware updates and, before long, Windows Boot Manager updates. Existing installs keep working for the time being. But the next time such a device tries to install a DBX or bootloader update signed only with the 2023 keys, the install will fail. Windows isn't the only thing affected: Linux dual-boot systems and virtual machines are in the same boat. I fully expect more support calls once feature and security updates start requiring the new certificate chain.

If you want the background on how Secure Boot and its keys work, I covered that in an earlier post: what admins need to know about the 2026 Secure Boot certificates.

The registry and Event Log show which devices already have the 2023 keys

The first job is finding out which devices are already prepared. Microsoft has a detailed walkthrough at https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance. On Windows 10/11 (you need local admin), the registry records every Secure Boot key servicing event under:

HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

Each subkey holds the latest timestamp and thumbprint for KEK, DB and DBX updates. For quick checks I usually go to the Windows Event Log instead:

  1. Event Viewer → Applications and Services Logs → Microsoft → Windows → SecureBoot-Management → Operational
  2. Look for events that show KEK or DB updates with the 2023 key thumbprints.

If you have Intune device inventory, you can use it to check Secure Boot status across the fleet. Be careful, though. Not every OEM or device model reports reliably, and older hardware is the worst offender. I normally combine the Intune inventory with spot checks in the Event Log and Registry, particularly on devices that have run for years without a firmware update. In my experience that combination is the only way to avoid surprises.

Outdated firmware, VMs and dual-boot machines carry the most risk

Three scenarios worry me most:

  • Devices with outdated firmware: Some OEMs no longer ship updates, which leaves no official way to add the 2023 KEKs. These devices will hit a hard wall with future UEFI or DBX updates.
  • Virtual machines: Hyper-V Gen2 and Azure Trusted Launch VMs have their own Secure Boot key sets. Azure Trusted Launch VMs should receive the new keys automatically (based on current announcements), while on-premises Hyper-V may need manual work, especially for VMs created years ago. If you deploy from old base images, check their Secure Boot status.
  • Linux dual-boot machines: Every distro handles its own signed shim/bootloader. If the firmware lacks the 2023 Microsoft KEKs, kernel or bootloader updates can fail after the expiry. Details differ between distributions, so test before you update.

If any of these are in your environment, expect support escalations if (or rather when) something stops working after a security or feature update.

# Check KEK status in PowerShell (run locally as admin):
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' | Select-Object KEKUpdateTimestamp, KEKThumbprint

Prerequisite: local admin, Windows 10 or newer. The command returns the timestamp and thumbprint of the most recent KEK update.

Tip from the trenches: OEM firmware tools often don't tell you which Secure Boot keys are actually in place after an update. Check the Registry or Event Log before you sign off a device.

Existing installs keep booting while new signed updates fail

After the expiry date, systems that still depend on the old KEKs can boot their existing Windows or Linux installs. What they can't do is apply signed DBX updates (the ones that block dangerous bootloaders) or install new Boot Manager versions once those are signed only with the 2023 keys. Security-conscious organizations should treat this as a problem that will get worse over time, because a future compliance or feature update could leave devices unbootable. For VMs (Hyper-V Gen2, Azure Trusted Launch), the Secure Boot policy state depends on the host and the VM image. In Azure you'll find it under the VM → Settings → Secure Boot Policy blade.

On Linux, future kernel or shim updates may fail after the KEK expiry on hardware that never got the latest keys, so some dual-boot setups could break without warning. If your fleet is a mix of updated and legacy devices, build an inventory and plan now.

This diagram sums up the update decision flow:

flowchart TD
    User["Admin checks status"] --> CheckReg["Registry HKLM...Servicing"]
    User --> CheckEvt["Eventlog SecureBoot-Management"]
    CheckReg --> Status2023["2023 KEK present?"]
    CheckEvt --> Status2023
    Status2023 -- "Yes" --> OK["Ready for updates"]
    Status2023 -- "No" --> FWUpdate["Firmware/VM update needed"]
    FWUpdate -- "Update available" --> OK
    FWUpdate -- "No update" --> Risk["Long-term at risk"]

Figure: Decision tree for Secure Boot KEK expiry and update readiness.

OEMs are responsible when no firmware update exists

I regularly run into hardware where the OEM has stopped shipping firmware updates or the documentation has gaps. Microsoft's current documentation is clear that shipping the new keys is the OEM's job. If you're stuck, escalate through your business channels as early as possible. For critical fleets, being left without UEFI or OS updates is too big a risk to sit out.

One thing that sometimes helps is searching for your model together with “UEFI Secure Boot KEK update”. Community forums or unofficial OEM channels occasionally point to a solution. Never install unsigned or unofficial firmware, though. For VMs, look for updated Hyper-V images or think about rebuilding them with current Secure Boot policies.

KEK expiry belongs on every fleet management to-do list

I don't see the KEK expiry as a compliance or security checkbox. If you want to avoid expensive outages or support escalations later this year, use the Registry and Event Log to find at-risk devices, push your OEMs for updates and refresh your VM images now. It's tedious work, but much less painful than dealing with bricked endpoints or missed patch windows. Document your exceptions, automate what you can, and work through Microsoft's guidance step by step. There isn't much time left.