The clock has run out. As of June 24, 2026, the first of Microsoft’s original Secure Boot certificates, the Microsoft Corporation KEK CA 2011, has officially expired, with the Microsoft UEFI CA 2011 following on June 27, 2026.

A third, the Microsoft Windows Production PCA 2011, is set to expire on October 19, 2026. Together, these certificates have underpinned firmware-level boot trust on every UEFI-capable PC deployed since the Windows 8 era, more than a billion devices worldwide, including systems running Linux distributions.

This is not a routine patch Tuesday. It is a permanent, structural change to the cryptographic trust chain that runs every time a device powers on.

Identifying potential risks is the first step. Here is what IT teams can do to ensure readiness before the deadline. To grasp why this matters, you need to understand Secure Boot’s layered key hierarchy stored in UEFI firmware:

• The Platform Key (PK) sits at the top, authorizing the Key Enrollment Key (KEK).
• The KEK signs updates to two critical databases: the Allowed Signature Database (DB), which lists trusted boot signatures, and the Forbidden Signature Database (DBX), which blocks known-malicious ones.
• At boot time, firmware checks the bootloader’s cryptographic signature against the DB. If it matches and is not revoked in DBX, the system proceeds.

Four certificates that anchor this entire hierarchy are now at or approaching the end of life:

Expiring Certificate	Expiry Date	Replacement	Location	Purpose
Microsoft Corporation KEK CA 2011	June 24, 2026	Microsoft Corporation KEK 2K CA 2023	KEK	Signs updates to DB and DBX
Microsoft Corporation UEFI CA 2011	June 27, 2026	Microsoft UEFI CA 2023	DB	Signs third-party OS and hardware driver components
Microsoft Corporation UEFI CA 2011	June 27, 2026	Microsoft Option ROM UEFI CA 2023	DB	Signs third-party option ROMs
Microsoft Windows Production PCA 2011	October 19, 2026	Windows UEFI CA 2023	DB	Signs the Windows boot loader

The replacement 2023 certificates are valid through 2038, offering approximately 15 years of continued coverage.

The scope is enormous. Every computer manufactured with a UEFI-based motherboard spanning Windows 10, Windows 11, Windows Server 2012 through 2025, and any hardware released since approximately 2012 is potentially in scope.

The impacted device population is more than a billion PCs. Devices shipped in 2025 or later, including Copilot+ PCs, typically arrive with the 2023 certificates pre-installed and require no action.

Linux distributions are equally exposed. Nearly every mainstream Linux distro, Ubuntu, Fedora, Debian, RHEL, and others, uses Microsoft’s UEFI CA 2011 to sign the shim first-stage bootloader that enables those systems to boot with Secure Boot enabled.

The Fedora Project confirmed that once the 2011 key expires, any new shim binaries will only be signed with the 2023 key. This means Linux installation media relying on a new shim signed with the 2023 key will fail to boot on machines whose firmware only contains the old 2011 certificates, a direct impact on bare-metal installs, server deployments, and VM templates across enterprise environments.

Devices that fail to migrate will continue to boot and run existing software normally. What they permanently lose, however, is far more consequential:

• No future DBX revocation list updates — new bootkits and malicious bootloader variants will never be blacklisted at the firmware level.
• No Windows Boot Manager security updates — the bootloader is frozen at its last 2011-signed version.
• No new Secure Boot DB updates — third-party hardware components and OS drivers signed with new certificates will not be trusted.
• Potential blockage of future Windows feature updates, since newer builds may require a Boot Manager version that requires the 2023 certificate chain.

In practice, these devices accumulate compounding security debt with no clean remediation path back. Threat actors exploiting bootkit-class malware operate precisely at this firmware level that Secure Boot’s DBX revocation mechanism is designed to block.

Microsoft’s official guidance and OEM advisories make clear that remediation requires two sequential actions:

1. OEM Firmware (BIOS/UEFI) Update first — Devices manufactured before 2024 need a vendor-supplied firmware update to enable their UEFI to accept the 2023 certificates. Use Dell Command | Update, Lenovo System Update, or HP Image Assistant, depending on the hardware vendor.
2. Windows Certificate Update second — Delivered via Microsoft’s monthly cumulative updates. Requires Windows 10 22H2+ with ESU enrollment, or any supported Windows 11 build. A scheduled task runs approximately every 12 hours to stage the update, with Boot Manager replacement deferred to the next reboot.

For enterprise environments, Microsoft Intune’s Settings Catalog and Windows Autopatch include a dedicated Secure Boot Certificate Update policy and built-in Secure Boot Status report.

Group Policy administrators should enable “Enable Secure Boot Certificate Deployment” under Computer Configuration > Administrative Templates > Windows Components > Secure Boot after deploying the latest Windows 11 ADMX templates.

For Linux systems, administrators must update both the shim package (via apt full-upgrade, dnf upgrade, or equivalent) and apply the OEM firmware update that enrolls the Microsoft UEFI CA 2023 certificate into the firmware DB. The fwupd version 2.0.10 or later is required for Linux Vendor Firmware Service (LVFS) delivery to function correctly.

On Windows, navigate to Windows Security > Device Security > Secure Boot — a green badge confirming “all certificates are applied” is the required indicator, not merely a green checkmark. Alternatively, check the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\UEFICA2023Status for an “updated” value.

On Linux, run sudo mokutil --sb-state to confirm Secure Boot status and sudo mokutil --db to inspect enrolled certificates. If the output shows only the Microsoft Corporation UEFI CA 2011 certificate, your firmware needs an update immediately.

The October 19, 2026, expiry of the Windows Production PCA 2011 provides a secondary deadline, but organizations relying on the KEK and UEFI CA certificates have already passed their window as of today. For authoritative guidance, Microsoft’s dedicated portal is available.

The article (.md file) is ready to download above. It covers the full trust chain breakdown, the exact expiry dates for all four certificates, Linux shim impact, the consequences of non-remediation (DBX freeze, bootkit exposure, feature update blockage), and a two-step enterprise/Linux remediation playbook, all sourced from Microsoft’s official blog.

Windows Secure Boot Certificates to Expire – What IT Teams Should Do Before the Deadline.