Microsoft Secure Boot Certificates Expire in 2026, Affecting Windows and Linux Systems

Microsoft’s original Secure Boot certificates from 2011 have started reaching the end of their validity period, creating a major maintenance deadline for Windows PCs, servers, virtual machines, and many Linux systems that rely on Microsoft-signed boot components.

The first certificate, Microsoft Corporation KEK CA 2011, expired on June 24, 2026. The Microsoft UEFI CA 2011 followed on June 27, 2026, while Microsoft Windows Production PCA 2011 expires on October 19, 2026, according to Microsoft’s Secure Boot certificate guidance.

This does not mean affected devices suddenly stop working. The real risk is that systems without the newer 2023 certificates may lose access to future Secure Boot protections, bootloader updates, revocation updates, and some future compatibility paths.

What is changing with Secure Boot certificates

Secure Boot uses certificates stored in UEFI firmware to decide whether boot software can run before the operating system starts. Microsoft introduced this model during the Windows 8 era to help block bootkits and other pre-boot malware.

The trust chain includes the Platform Key, Key Enrollment Key, Secure Boot allowed database, and Secure Boot forbidden database. These are often shortened to PK, KEK, DB, and DBX.

When a system starts, firmware checks whether bootloaders, drivers, and EFI applications are signed by trusted certificates in DB and not blocked by DBX. If the certificates are outdated, the device may still boot, but it may not receive the latest boot-level security protections.

Expiring certificate	Expiry date	Replacement certificate	Location	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 bootloaders 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 Windows Boot Manager

Existing PCs should still boot, but protection can degrade

The most important point for users is simple: certificate expiration alone does not brick a Windows PC. Microsoft says devices without the newer certificates will continue to start and operate normally, and standard Windows updates can continue to install.

The problem is what happens over time. Microsoft warns that systems that do not move to the 2023 certificates may no longer receive new protections for early boot components, including Windows Boot Manager updates, Secure Boot database updates, revocation list updates, and mitigations for newly discovered boot-level vulnerabilities.

That creates a slower security problem rather than an instant outage. A device may appear healthy while its Secure Boot trust chain stops receiving the newest protections against bootkits and unsafe boot components.

Why Linux distributions are affected too

The issue also affects Linux because many mainstream distributions rely on a Microsoft-signed shim bootloader to work with Secure Boot on common PC hardware. That includes systems where Windows is not installed at all.

Fedora Magazine says Microsoft will no longer be able to sign new shim builds with the 2011 key after expiry. Fedora also says machines should continue to boot as long as the current public keys remain in firmware and are not revoked.

Future updates matter more than current booting. If a Linux system receives a newer shim signed only with the 2023 key, older firmware that lacks the new certificate may not trust that bootloader.

• Existing Windows systems should continue to boot after the June 2026 certificate expirations.
• Existing Linux systems should also continue to boot if their current keys remain enrolled.
• Future Windows Boot Manager updates may require the 2023 certificate chain.
• Future Linux shim updates may require the Microsoft UEFI CA 2023 key.
• Systems without updated keys may lose future Secure Boot servicing and protection.

Red Hat and Fedora recommend preparing now

Red Hat has published similar guidance for enterprise Linux environments. The company says Secure Boot-enabled systems will continue to boot after June 2026 whether they are updated immediately or not, but it recommends updating firmware databases and shim when updates are available.

The Red Hat Secure Boot guidance says Microsoft began signing shim with both the 2011 and 2023 keys in October 2025. After June 2026, Microsoft can only sign with the 2023 key.

Fedora has also moved toward dual-signed and 2023-ready shim builds. The goal is to preserve compatibility on older machines while preparing for future hardware that may ship without the older 2011 certificate.

How Linux firmware updates fit into the transition

Firmware matters because the Secure Boot certificates live in UEFI storage, not only inside the operating system. A Linux system may have an updated shim package but still need the 2023 certificate in firmware to trust future boot components.

The fwupd UEFI Secure Boot certificate documentation says Linux systems will not stop booting when the certificate expires. It also explains that fwupd gives Linux vendors a way to distribute updated certificates without asking users to disable Secure Boot.

This is especially important for bare-metal servers, developer workstations, and laptop fleets that use Linux with Secure Boot enabled. If the firmware database cannot be updated, future boot package updates may become harder to deploy safely.

System type	Main risk	Recommended action
Windows 11 PCs	Missing future Secure Boot protections	Install Windows updates and check Secure Boot certificate status
Windows 10 22H2 systems	Eligibility depends on support status and updates	Use supported update channels or ESU where required
Windows Server	Managed fleets may need controlled rollout	Use Microsoft’s IT deployment guidance and test firmware behavior
Linux desktops and servers	Future shim updates may need the 2023 key	Update firmware DB and install current shim packages
Virtual machines	Virtual firmware templates may need new certificates	Update VM images, templates, and Secure Boot-enabled environments

How Windows users can check update status

Microsoft has added Secure Boot certificate status information to the Windows Security app. The new status appears under Device security and Secure Boot on supported Windows devices.

The Windows Security app status guide says a green checkmark alone is not enough. Users should look for the message saying Secure Boot is on and all required certificate updates have been applied.

If Windows reports that Secure Boot is on but the device uses an older boot trust configuration, users should install the latest Windows updates, restart when prompted, and check for firmware or BIOS updates from the PC maker.

Enterprise admins have several deployment options

For managed Windows environments, Microsoft provides multiple ways to deploy and monitor the Secure Boot certificate updates. These include Windows Update, registry-based deployment, Group Policy, Windows Configuration System APIs, Intune, and Windows Autopatch reporting.

Microsoft’s IT professional guidance tells organizations to inventory devices, validate firmware compatibility, deploy the certificate updates, and monitor update status across the fleet.

This rollout needs testing because firmware behavior differs by vendor and model. Some devices may need OEM firmware updates before Windows can safely apply Secure Boot variable changes.

• Inventory Secure Boot-enabled devices across Windows, Linux, and virtual environments.
• Apply OEM BIOS or UEFI updates where required.
• Install the latest Windows updates or Linux shim and firmware updates.
• Check Secure Boot certificate status after reboot.
• Monitor devices that remain on 2011 certificates.
• Test BitLocker, TPM-bound secrets, and measured boot workflows before broad rollout.

Linux admins should check Secure Boot state and enrolled keys

Linux administrators can start by confirming whether a system uses UEFI and whether Secure Boot is enabled. Fedora recommends using mokutil to check Secure Boot status and inspect firmware database keys.

Fedora’s Secure Boot article shows that mokutil can display enrolled certificates such as Microsoft Windows Production PCA 2011, Windows UEFI CA 2023, Microsoft Corporation UEFI CA 2011, and Microsoft UEFI CA 2023.

If only the older Microsoft 2011 certificate appears, administrators should check whether their hardware vendor or Linux distribution offers a firmware DB update. On supported systems, fwupd can help deliver those updates.

What happens if organizations do nothing

Doing nothing may not create an immediate outage, but it can create long-term security debt. The biggest risk is that boot-level security updates stop applying cleanly, leaving older trust decisions in place.

Microsoft’s certificate guidance says devices without the newer certificates may miss future Windows Boot Manager updates, Secure Boot database updates, revocation list updates, and mitigations for newly found boot-level vulnerabilities. The company also warns that scenarios relying on Secure Boot trust, including BitLocker hardening and third-party bootloaders, may be affected.

For Linux, Red Hat says legacy systems without a Secure Boot DB update may face issues when a bootloader or shim update becomes necessary after the expiration. The Red Hat post recommends updating the firmware database where available and keeping shim updated.

Secure Boot update checklist

Step	Windows action	Linux action
1. Confirm Secure Boot status	Open Windows Security, then Device security and Secure Boot	Run mokutil –sb-state
2. Check certificates	Use Windows Security status or enterprise inventory tools	Run mokutil –db –short
3. Update firmware	Use OEM update tools or IT deployment channels	Use fwupd or vendor firmware packages
4. Update OS components	Install cumulative Windows updates	Install current shim and bootloader packages
5. Verify after reboot	Look for the fully updated Secure Boot certificate message	Confirm 2023 Microsoft certificates appear in firmware DB

Why this is a managed transition, not a panic event

The Secure Boot certificate rollover is a planned trust-chain update, not a sudden failure event. The expired 2011 certificates can still be present in firmware, and existing signed boot components can continue to run as long as those public keys remain trusted and are not revoked.

The fwupd documentation explains the Linux side clearly: machines running Linux will not stop booting when the certificate expires, but future boot media and shim updates may require newer firmware trust entries.

That is why organizations should act now. The safest approach is to update firmware, operating system components, and Secure Boot certificates before a future bootloader, revocation, or platform update depends on the 2023 chain.

Bottom line

The June 2026 Secure Boot certificate expirations mark the start of a major platform trust transition for Windows and Linux systems. The immediate risk is not mass boot failure, but a growing gap in future boot-level security coverage.

Home users should keep Windows and firmware updates current and check the Secure Boot message in Windows Security. Enterprise teams should inventory devices, test firmware updates, and deploy Microsoft’s supported Secure Boot certificate rollout controls.

Linux administrators should update shim packages, check enrolled keys, and use firmware update channels where available. The systems that get the 2023 certificates now will be better prepared for future Secure Boot updates, hardware changes, and bootloader security fixes.

FAQ