Windows Secure Boot Certificate Expiry Exposes Billions of PCs to Bootkit and Firmware Security Risks

Microsoft’s long-planned Secure Boot certificate rollover has reached a critical milestone, impacting more than just routine updates.

The Microsoft Corporation KEK CA 2011 expired on June 24, 2026, the Microsoft UEFI CA 2011 expires on June 27, 2026, and the Microsoft Windows Production PCA 2011 is scheduled to expire on October 19, 2026. This requires organizations to transition firmware trust from the 2011 certificate chain to the 2023 replacements.

This transition is important because Secure Boot is part of the pre-OS trust path, where UEFI firmware validates boot components before loading Windows or Linux. Therefore, certificate expiry becomes a firmware security issue rather than merely an endpoint patching task.

Windows Secure Boot Certificate Expiry Exposes PCs

At the core of the issue is Secure Boot’s layered trust hierarchy. UEFI firmware relies on the Platform Key to authorize the Key Enrollment Key (KEK), which is used to sign updates to the allowed signature database (DB) and the revocation database (DBX), as per reported by CSN.

During startup, the firmware checks whether bootloaders and EFI components are trusted in the DB and not blocked in the DBX before allowing execution. Microsoft has stated that devices that miss the 2023 certificate transition will still boot and run existing software.

However, they will lose access to future Windows Boot Manager protections, updates to Secure Boot DB and DBX, and new mitigations against boot-level threats.

This security concern is significant because bootkits and other early-boot malware specifically target the stage that Secure Boot is designed to protect. Microsoft indicates that systems remaining on the expired 2011 trust chain may continue to operate normally.

However, they will no longer receive new revocation lists or updated pre-boot trust materials. This weakens defenses against newly discovered bootloaders and firmware-level vulnerabilities over time. The company also notes that this can affect scenarios that depend on Secure Boot trust, including BitLocker hardening and support for third-party boot components.

The scope of this issue is extensive. Microsoft’s support matrix for the certificate transition includes Windows 10, Windows 11, and Windows Server versions from Server 2012 ESU to Server 2025.

According to Microsoft’s Windows IT Pro guidance, most devices manufactured since 2012 have Secure Boot enabled, and many PCs built since 2024 already include the 2023 certificates.

This means that the potential exposure spans a large installed base of UEFI-capable systems. At the same time, newer hardware is typically better equipped to handle the rollover.

Updated certificate transition table

Expiring certificate	Expiration date	Replacement certificate	Firmware location	Primary purpose
Microsoft Corporation KEK CA 2011	June 24, 2026	Microsoft Corporation KEK 2K CA 2023	KEK	Signs updates to DB and DBX
Microsoft UEFI CA 2011	June 27, 2026	Microsoft UEFI CA 2023	DB	Signs third-party boot loaders and EFI applications
Microsoft 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

Linux environments are also affected since Microsoft’s UEFI signing chain is widely utilized for third-party bootloaders. Fedora has warned that Microsoft will no longer sign shims with the 2011 key after June 2026, which may result in newer shim binaries signed under the 2023 certificate failing to boot on hardware that retains only the old trust anchors.

Red Hat has issued similar advisories, urging administrators to inspect enrolled keys, carefully test UEFI DB updates, and utilize vendor firmware updates through LVFS or OEM channels when available.

Microsoft and its hardware partners advocate a two-stage remediation process. First, organizations should apply OEM BIOS or UEFI firmware updates as necessary so that older devices can accept the new certificate set.

Second, they should deploy Microsoft’s certificate updates through supported Windows servicing channels, such as Intune, Group Policy, registry-based controls, or Windows Autopatch.

They should then verify the status using the UEFICA2023Status registry key, Windows Security, or event telemetry. With the first expiry date already passed and the UEFI CA 2011 deadline approaching rapidly, enterprises that delay migration risk locking systems into a frozen pre-boot trust state that attackers would exploit.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.