Operational Advisory — Not a Security Vulnerability. This is a certificate expiry event with global operational impact. No patch is required — UEFI firmware updates from device manufacturers are the remediation path.

Certificates Expired: Microsoft Corporation KEK CA 2011 (June 24, 2026) + Microsoft UEFI CA 2011 (June 27, 2026) | Impact: Billions of PCs, all x86 devices since Windows 8 (2012), Linux distributions using shim bootloader

What Happened

Microsoft’s original Secure Boot certificates have reached their end-of-life. These certificates form the root of trust for the Secure Boot chain on virtually every x86 PC manufactured since the introduction of Windows 8 in 2012:

• Microsoft Corporation KEK CA 2011 — Expired June 24, 2026. The Key Exchange Key (KEK) certificate that authorizes which signing keys are trusted by the platform.
• Microsoft UEFI CA 2011 — Expired June 27, 2026. The Certificate Authority that signs bootloaders and Option ROMs validated during Secure Boot.

When these certificates expire, the UEFI firmware may refuse to validate boot components signed by them. This can manifest as:

• Boot failures — systems with Secure Boot enabled may fail to boot entirely
• Secure Boot disabled — firmware may silently disable Secure Boot, reducing platform security
• Linux boot failures — distributions using the Microsoft-signed shim bootloader may be unable to pass Secure Boot validation
• Peripheral failures — Option ROMs on graphics cards, network adapters, and storage controllers signed with the expired certificates may fail to load

Systems and Software Affected

• All Windows PCs manufactured since 2012 with Secure Boot enabled and UEFI firmware that has not been updated with replacement certificates
• Linux distributions using the Microsoft-signed shim bootloader for Secure Boot compatibility — includes Ubuntu, Fedora, Debian, RHEL, openSUSE, and most major distributions
• Virtual machines with Secure Boot enabled (VMware, Hyper-V, KVM, VirtualBox)
• Enterprise fleets where UEFI firmware updates are not regularly deployed via endpoint management
• Consumer devices from Dell, HP, Lenovo, ASUS, Acer, and other manufacturers that have not received firmware updates

Remediation

Microsoft has published replacement certificates (Microsoft UEFI CA 2023 and newer) that device manufacturers have been distributing via UEFI firmware updates over the past several years. The remediation path is:

1. Apply the latest UEFI firmware update from your device or motherboard manufacturer immediately
2. Verify Secure Boot functionality after the firmware update — enter UEFI settings and confirm Secure Boot is enabled and functioning
3. For systems that fail to boot: temporarily disable Secure Boot in UEFI settings, apply firmware updates, then re-enable Secure Boot
4. For Linux systems: ensure you are on the latest shim version that supports the new certificate chain. Most distributions have shipped updated shim packages.
5. For virtual machines: update the VM’s virtual UEFI firmware (typically distributed with hypervisor updates)

Recommendations

• Audit UEFI firmware status across your fleet immediately. This is one of the rare events where firmware updates become operationally urgent.
• Prioritise remote and field devices. Systems at remote locations or with limited physical access are hardest to recover if they fail to boot.
• Prepare help desk for boot failure calls. The primary user-visible symptom will be “computer won’t turn on” — have a triage script ready.
• Check virtual infrastructure. VMs with Secure Boot may also be affected — verify hypervisor firmware versions.
• Linux-specific: Verify shim version across Linux fleet. Update GRUB/systemd-boot as needed.
• This is not a one-time event. Additional Secure Boot certificates will expire in the future. Establish a recurring UEFI firmware update cadence as part of standard patch management.

References

• CybersecurityNews: Windows Secure Boot Certificate Expired
• Microsoft: Secure Boot Overview
• shim Bootloader GitHub Repository

This is an operational advisory, not a vulnerability disclosure. No CVE applies. Part of the Vulnerability Intelligence series on threat-modeling.com. See the June 28, 2026 Vulnerability Intelligence Report for broader context.