Microsoft's 2011 Secure Boot Certificates Are Expiring and Most Windows Users Don't Know It

Here's the thing about Secure Boot: when it works correctly, you never think about it. Your PC turns on, Windows loads, you log in, and none of the cryptographic key verification happening between the firmware and the bootloader is visible to you in any way. That invisibility is intentional and, mostly, a feature.

It becomes a serious problem when the infrastructure underpinning that invisible verification reaches end of life and most users have no idea it exists at all.

The Microsoft Corporation KEK CA 2011 certificate — the key that has been anchoring Windows Secure Boot trust chains for fifteen years — starts expiring in June 2026. The most significant date is October 19, 2026, when the main certificate expires. On that date, PCs that have not received firmware updates containing replacement certificates will have degraded Secure Boot posture and may face boot failures as Microsoft tightens enforcement over the following months.

Starting May 13, 2026 for Windows 10 and May 16, 2026 for Windows 11, Windows Security is displaying escalating warning banners under Device Security to force this invisible maintenance problem into users' field of view. Most users will ignore the first yellow warning. Many will ignore the orange one. This article explains why that's a mistake.

What Is Secure Boot and Why Does It Have Certificates?

Secure Boot is a UEFI feature that prevents your computer from loading unauthorized operating systems or bootloaders during startup. It works by verifying cryptographic signatures on everything that runs before the operating system starts: the bootloader, any pre-OS security tools, the Windows Boot Manager.

The trust chain works like this:

1. Your UEFI firmware contains a database of trusted certificates (the "db") and a Key Enrollment Key (KEK)
2. The KEK is used to authorize updates to the signature database
3. Microsoft's certificates are in both the KEK and the signature database
4. When Windows boots, the firmware verifies that the Windows Boot Manager's signature was made by a certificate in the trusted database
5. If verification passes, the boot continues. If it fails, the firmware stops the boot and displays an error
   The certificates in this chain are time-limited. Like all X.509 certificates, they have a NotAfter date. When that date passes, software that checks certificate validity will reject them as expired. The Microsoft Corporation KEK CA 2011 certificate was issued in 2011 with a 15-year validity period — which is actually unusual by certificate standards, where one to three years is common. Fifteen years of security relevance was ambitious in 2011. Now we're finding out how that timeline plays out.

The Three-Certificate Problem

Microsoft's Secure Boot trust chain involves several certificates with different expiration timelines. The situation is more complex than "one cert expires, update it."

Microsoft Corporation KEK CA 2011 — This is the Key Enrollment Key that authorizes updates to the Secure Boot signature database. Expiration: October 19, 2026. This is the critical one. Without a valid KEK, the firmware cannot verify updates to the trusted signature database, and signed bootloaders can't be added to the trust chain.

Microsoft Windows Production PCA 2011 — The certificate that signs the Windows Boot Manager and other Windows boot components. This certificate is in the process of being rotated to a 2023 variant. Systems that only have the 2011 version in their firmware trust store may stop trusting newly-signed Windows Boot Manager versions as Microsoft transitions signing to the new certificate.

Microsoft UEFI CA 2011 — Signs third-party UEFI code including Linux shims, option ROMs, and other pre-OS components. This is what makes dual-boot Linux systems work with Secure Boot. Also being rotated.

The replacement certificates are:

• Microsoft Corporation KEK CA 2023 — The new KEK
• Windows UEFI CA 2023 — Replacement for the UEFI CA used to sign bootloaders
• Microsoft Corporation UEFI CA 2023 — For Windows boot components
  These replacement certificates are delivered via firmware updates, not via Windows Update alone. This is the critical point that explains why this is hard and why millions of machines will miss the transition. Firmware updates come from your PC's manufacturer — Lenovo, Dell, HP, ASUS, Microsoft (Surface), etc. Windows Update can install firmware updates if the manufacturer packages them correctly, but not every manufacturer does, and not every model receives firmware support past a certain age.

Why Firmware Updates Make This More Complex Than a Regular Patch

A Windows cumulative update arrives through Windows Update, applies automatically if you have auto-updates enabled, and requires a reboot. The security change is complete.

Secure Boot certificate rotation doesn't work this way. The certificates live in the UEFI firmware's NVRAM — the same protected storage that holds your boot order, Secure Boot state, and platform configuration. To update these certificates, either the firmware itself needs to be updated (a BIOS/UEFI firmware flash), or a new signed certificate database needs to be enrolled into NVRAM.

Microsoft has been working with OEMs and firmware vendors to issue updated firmware that includes the new Microsoft Corporation KEK CA 2023 along with refreshed UEFI CA certificates. The new keys are valid well into the future, but the transition must be completed before the old ones expire.

The categories of machines at different risk levels:

Low risk: Modern PCs (2021 and newer) from major OEMs with active firmware support. These have received firmware updates distributing the new certificates. Windows Update installs them if the manufacturer packaged them as drivers. Most users in this category are already updated without knowing it.

Moderate risk: Older machines (2017-2020) from major OEMs. Firmware support may have ended. The machine may still be capable of running the update if it exists, but Windows Update won't deliver it automatically. You need to check the manufacturer's support site for your specific model and manually install the firmware update if available.

High risk: Very old machines (pre-2017), budget OEM hardware with limited firmware support, end-of-life hardware. No firmware update may be available. The manufacturer may no longer exist. The device may require replacement if Secure Boot is required for your security posture.

Complicated situations: Virtual machines, dual-boot Linux systems, custom-built PCs using consumer motherboards, enterprise images with customized Secure Boot configurations. Each of these has specific guidance that varies by configuration.

The Warning Escalation Timeline

Microsoft's warning system follows a staged escalation to give maximum notice before enforcement:

Initial Phase (Starting May 13, 2026 for Windows 10; May 16, 2026 for Windows 11):
A yellow advisory banner appears in Windows Security → Device Security → Secure Boot. The text indicates your current Secure Boot configuration will become unsupported. No immediate impact on boot, but the PC is flagged. This is the phase starting now.

Intermediate Phase (Approximately Q3 2026, 3-4 months after initial):
The banner turns orange. Full-screen notifications may appear during logon. The warning becomes more intrusive — designed to reach users who dismissed the yellow banner.

Enforcement Phase (October 2026 onwards):
The Microsoft Corporation KEK CA 2011 certificate expires on October 19, 2026. At this point, systems relying solely on the expired certificate to validate Secure Boot operations face real consequences: Secure Boot database updates signed with old certificates may be rejected; future Windows updates that rely on re-signing bootloaders with new certificates may fail validation; Microsoft may begin enforcing stricter requirements in Windows boot verification.

A PC that misses the update should still boot and run, but it may stop receiving future early-boot security protections. Disabling Secure Boot is not a proper fix for the certificate transition.

How to Check and Fix Your Secure Boot Certificate Status

Check your certificate status in Windows Security:

Open Windows Security → Device Security → Secure Boot. Green = current. Yellow = attention needed. Red = configuration will become unsupported.

Check via PowerShell (more detail):

# Check Secure Boot status
Confirm-SecureBootUEFI
 
# List the KEK certificates in your firmware
Get-SecureBootUEFI KEK | Select-Object -ExpandProperty bytes | 
  ForEach-Object { [System.Security.Cryptography.X509Certificates.X509Certificate2]$_ } |
  Select-Object Subject, NotBefore, NotAfter
 
# Check if the new 2023 certificate is present
Get-SecureBootUEFI KEK | Select-Object -ExpandProperty bytes |
  ForEach-Object { 
    $cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]$_
    if ($cert.Subject -match "2023") { $cert | Select Subject, NotAfter }
  }

Check for available firmware updates:

# Check for firmware updates via Windows Update
Get-WindowsUpdateLog
winget upgrade --include-unknown | grep -i firmware
 
# Or use manufacturer-specific tools:
# Lenovo: Vantage app or support.lenovo.com
# Dell: Dell Command Update or dell.com/support
# HP: HP Support Assistant
# ASUS: MyASUS or asus.com/support
# Surface: Windows Update delivers Surface firmware automatically

For enterprise environments:

# Inventory Secure Boot certificate status across managed devices
# Using Intune or Configuration Manager to query:
Get-CimInstance -ClassName Win32_SystemEnclosure | Select-Object Manufacturer, Model, SerialNumber
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard -ClassName Win32_DeviceGuard |
  Select-Object SecureBootState, CodeIntegrityPolicyEnforcementStatus

Microsoft's guidance for enterprise IT administrators is explicit: inventory all Windows 10 and 11 devices in the environment, use PowerShell scripts or Intune reports to check Secure Boot certificate versions, work with OEMs to identify firmware update availability, schedule a phased rollout prioritizing critical systems, and test on a small set of machines before broad deployment.

The Dual-Boot Linux Complication

If you run a dual-boot system with Linux and Windows, this certificate rotation is more complicated and potentially more dangerous than for Windows-only systems.

Linux Secure Boot support relies on a chain: the UEFI firmware trusts Microsoft's certificate, Microsoft's certificate is used to sign the Shim bootloader, Shim verifies the signature on GRUB or systemd-boot, and the bootloader verifies the kernel. If any link in this chain uses a certificate that's no longer trusted, the boot fails with a Secure Boot policy violation.

The practical implications:

New installs: Distributions shipping new versions of Shim signed by the Microsoft UEFI CA 2023 certificate will work fine on updated firmware. Distributions still shipping Shim signed only by the 2011 certificate may fail to boot on systems that have completed the certificate transition.

Existing installs: If your Linux Shim was enrolled with trust based on the 2011 certificate and your firmware updates remove or deprioritize the 2011 certificate, the bootloader chain may break. The fix is to re-enroll the bootloader trust or update to a newer Shim signed by the 2023 certificate.

MokManager (Machine Owner Key): If you enrolled a custom MOK for your Linux kernel, that enrollment is stored in NVRAM. Firmware updates should preserve this, but it's worth verifying after any firmware update that your custom keys are still enrolled.

The Linux distributions are aware of this and are preparing updated Shim packages. Ubuntu, Fedora, SUSE, and Debian have all issued advisories. The general guidance: update your Linux distribution fully before the certificate transition completes, verify that your boot still works after any Windows firmware updates, and file a bug with your distribution if you encounter boot failures.

Thousands of Devices, Variable OEM Support

For enterprise IT administrators, this is a familiar type of problem with an unfamiliar urgency.

For businesses, this could mean thousands of machines becoming inaccessible, leading to costly IT remediation. Microsoft is giving over a year of warning, so IT administrators should start planning now.

The specific complications for enterprise environments:

Custom Secure Boot policies: Some enterprises customize the Secure Boot signature database to restrict which operating systems and bootloaders can run on company hardware. These custom databases may reference the 2011 certificates explicitly. A certificate rotation requires updating the custom policy, not just installing firmware updates.

BitLocker interaction: BitLocker uses Secure Boot measurements as part of its TPM-based key protection. If Secure Boot configuration changes — including certificate updates — cause PCR (Platform Configuration Register) values to change, BitLocker may refuse to release the encryption key, requiring recovery key entry. Test firmware updates on a small set of BitLocker-protected machines before broad deployment.

WDS/PXE deployments: Windows Deployment Services and PXE boot environments use their own Secure Boot certificates. An enterprise with a custom PXE environment may need to update bootloader signing in addition to client firmware.

VMs: Virtual machines with UEFI firmware (Generation 2 VMs in Hyper-V, UEFI VMs in VMware) have their own virtual UEFI firmware. Hypervisor vendors need to ship updated virtual firmware for their UEFI implementations. Hyper-V's virtual UEFI is updated via Windows Server updates. VMware ships UEFI updates through their normal patch channels.

The recommended enterprise sequence: audit, then test, then phase, then verify. Do not deploy firmware updates to BitLocker-protected machines without testing the BitLocker recovery flow first. Do not deploy to domain controllers without a tested rollback procedure.

What Microsoft Is Actually Communicating

Microsoft's Secure Boot certificate rollover is the kind of story Windows users are trained to underestimate because nothing explodes immediately. That is the point: the warning arrives before the failure mode becomes obvious, and the fix for most people is still mundane enough to do today.

Microsoft can move fast on software changes. Firmware is different. Apple can move platform trust with far fewer hardware permutations. Microsoft has to drag along OEMs, enterprise images, hobbyist builds, old servers, dual-boot users, virtual machines, and unsupported-but-still-running PCs. That complexity is not a reason to avoid the migration. It is the reason Microsoft is pushing visible warnings before the cliff edge.

The machines most likely to sail through are the ones already receiving current Windows and firmware updates. The machines most worth checking are the ones that have been ignored precisely because they have been stable — the old workstation in the corner that still runs, the server that's been chugging along since 2018, the PC under someone's desk that nobody thinks about.

Check now. The update is boring. The alternative is not.

The cybersecurity overview covers the threat model that Secure Boot exists to address — firmware-level malware (bootkits) that load before the operating system and are invisible to traditional antivirus. The encryption article covers the cryptographic key infrastructure that makes certificate-based boot verification work. For organizations also managing Linux fleet security in parallel with this Windows migration, the Copy Fail CVE-2026-31431 article [link] covers a simultaneous high-severity Linux kernel vulnerability.