🏛️ Architecture

Secure Boot Certificates Expire June 2026 — Enterprise Action Window Is Now

Microsoft's 2011 Secure Boot signing certificates expire on 26 June 2026, with the Windows bootloader certificate following in October. Organisations that fail to apply firmware and OS updates before these deadlines lose the ability to receive boot-level security fixes and risk UEFI bootkit exposure. Microsoft has begun displaying warnings in Windows Security app in April 2026, but the update process requires OEM firmware coordination that takes weeks.

5 min read
#secure-boot#uefi#certificate-expiry#microsoft#bootkit#pki#firmware#windows#enterprise-security

In eleven weeks, Secure Boot — the firmware mechanism that validates the integrity of the Windows boot chain before the operating system loads — loses a foundational component of its trust anchor. The Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011 certificates expire on 26 June 2026. The Microsoft Windows Production PCA 2011, which signs the Windows bootloader itself, follows in October 2026. Organisations that have not coordinated firmware and OS updates before these deadlines will find themselves locked out of future boot-level security patches and vulnerable to UEFI bootkit attacks that Secure Boot is specifically designed to prevent.

This is not a theoretical future risk. It is a deadline with a fixed date and a real attack surface consequence: bootkits like BlackLotus (CVE-2023-24932) exploit exactly the boot-integrity gap that expired Secure Boot certificates create. Microsoft is now surfacing warnings in the Windows Security application for devices in affected states — but the warning alone is not a fix.

What Expires and What It Means

Secure Boot relies on a chain of certificate authorities embedded in UEFI firmware. When Microsoft issues a signed bootloader, the chain must validate from the device firmware through these CAs to be accepted at boot time. There are three expiring components, each with different consequences:

Microsoft UEFI CA 2011 — Signs third-party software in the Secure Boot chain: Linux distributions, many dual-boot configurations, and third-party endpoint security agents that operate at boot time. When this expires, devices will reject bootloaders and firmware signed only under the 2011 UEFI CA, including unupdated Linux shims and some vendor drivers.

Microsoft Corporation KEK CA 2011 — The Key Exchange Key authority used to issue updates to the Secure Boot Forbidden Signature Database (dbx). After expiry, devices cannot receive dbx updates, which is the primary mechanism for revoking compromised boot software. Without dbx updates, known malicious bootloaders — including those used by BlackLotus — cannot be blocked.

Microsoft Windows Production PCA 2011 — Signs the Windows Boot Manager itself. Expiry in October 2026 means Windows bootloader security patches issued after that date will not be trusted on systems running only the 2011 PCA.

The Update Dependency Problem

The complication is that applying Microsoft’s replacement 2023 certificates is a two-step process that requires coordination between OEM firmware updates and Windows OS updates — and some devices cannot complete it at all.

Step 1 — OEM firmware update: Device UEFI firmware must be updated to include the new 2023 certificates in its trusted database. This requires a firmware update from the original equipment manufacturer. For enterprise hardware managed through WSUS, SCCM, or Intune, this means OEM-specific firmware update packages need to be available, tested, and deployed before the OS update step.

Step 2 — Windows OS update: Once the firmware is updated, the Windows update that applies the certificate transition can be installed. Installing the OS update before the firmware is ready can, in some configurations, result in a device that fails to boot.

Devices that may never receive the fix: Systems manufactured between approximately 2011 and 2015 may not receive firmware updates from their OEMs — a reality Microsoft has acknowledged. For these devices, the practical outcome is loss of Secure Boot integrity over time, making them permanent targets for boot-level attacks.

The Bootkit Risk Context

The specific threat Secure Boot addresses — UEFI bootkits — represents one of the most persistent and difficult-to-detect attack categories available to sophisticated threat actors. A bootkit that executes before the OS loads can disable security tooling, tamper with OS integrity verification, and survive full OS reinstallation. BlackLotus, the first publicly known UEFI bootkit to bypass Secure Boot on fully patched Windows 11 systems, demonstrated that this threat class is operational in the wild.

Without functional dbx updates (which depend on the KEK CA), known bootkit signatures cannot be added to the revocation database. An organisation operating on expired Secure Boot certificates is effectively running Secure Boot in a static, never-updated state — unable to block newly discovered bootloaders even after public CVE disclosure.

  • Inventory your estate for Secure Boot certificate status now. Starting in April 2026, Windows Security on supported devices displays a Secure Boot certificate update status indicator. Use Intune or SCCM compliance policies to query SecureBootUEFI state and certificate binding dates across your managed fleet, and identify systems showing the yellow or red warning state.
  • Pull OEM firmware updates immediately. Contact your hardware vendors for available UEFI firmware updates that include the 2023 certificate set. For Dell, HP, Lenovo, and Microsoft Surface, firmware packages are available through vendor update portals and WSUS integration. Do not apply the Windows certificate transition update before firmware is confirmed updated.
  • Follow Microsoft’s published Secure Boot playbook. Microsoft has published a step-by-step enterprise playbook at the Windows IT Pro Blog specifically for the 2026 certificate transition. Apply it in a test group before broad deployment — certificate updates interact with BitLocker recovery and some third-party endpoint agents.
  • Identify systems that cannot be updated. Isolate 2011-era hardware that will not receive OEM firmware support. Evaluate whether these systems should be decommissioned before June 2026, or placed in a network segment with compensating controls reflecting their permanent Secure Boot limitation.
  • Review dual-boot and Linux configurations. Linux distributions using shims signed under the Microsoft UEFI CA 2011 may fail to boot after expiry if not updated. Red Hat has published specific RHEL guidance; coordinate with Linux distribution maintainers for updated shim versions before the deadline.
  • Update BitLocker recovery documentation. Certificate updates may trigger BitLocker recovery on some configurations. Ensure recovery keys are accessible and documented before initiating the update process.

The June 26 deadline is eleven weeks away. The OEM firmware dependency means enterprises cannot leave this to the last week — the minimum realistic timeline for a safe, tested rollout across a managed fleet is four to six weeks.