Two of the Three Secure Boot Certificates Already Expired. The Third Is 19 October.

The Secure Boot certificates that have been in x86 firmware since 2011 came with expiry dates, and two of the three passed in June. Microsoft Corporation KEK CA 2011 expired on 24 June 2026, Microsoft UEFI CA 2011 on 27 June. Nothing bricked. Nobody’s laptop refused to POST, and the machines that had not been updated kept booting exactly as before.

That was always going to happen, and understanding why is the whole thing. The last of the three, Microsoft Windows Production PCA 2011, expires on 19 October 2026, which is eight weeks out. Dates below came off Microsoft’s certificate expiration page and Red Hat’s guidance on 22 August 2026.

Why nothing broke, stated precisely

UEFI firmware checks whether the signing certificate is present in the signature database. It does not check whether that certificate is still within its validity window. Red Hat puts it plainly: “As long as the public certificate is available, a program signed by its private key will be loaded.” A shim signed in 2024 by a certificate that expired in June still boots today, and will keep booting until the certificate is removed from db or revoked through DBX.

What expiry removes is the ability to produce new signatures. After 27 June, Microsoft can only sign third-party bootloaders with the 2023 key. After 19 October, the same becomes true of Windows boot components.

That flips the risk from “my machines stop booting” to something quieter. A device without the 2023 certificates enrolled keeps running and keeps taking normal Windows updates, but it can no longer receive boot chain security servicing: new boot manager builds, new signature database entries, and new revocation lists. DBX is the blocklist that gets updated when a BlackLotus-class bootkit is found. On a machine stuck at the 2011 trust anchor, that pipeline is closed.

What June already changed

For Linux, the third-party CA that expired in June is the one that signs shim, so this was never a Windows-only story. Red Hat shipped a dual-signed shim, carrying both 2011 and 2023 signatures, with RHEL 9.8 and RHEL 10.2 and their supported z-streams, and RHEL 8 z-streams got it in June 2026. RHEL 7.9 does not get one.

Dual-signed is the trick that makes the transition survivable: the same binary boots on firmware that trusts either generation. New shim releases after June are signed only by the 2023 key, which means the exposure moved to installation media and re-imaging. An existing host keeps booting. A host you rebuild from current media onto firmware that only knows the 2011 certificates is the one that will not come up.

Check what a machine actually has rather than trusting an inventory:

mokutil --sb-state
mokutil --db | grep -A13 '\[key'

The certificate entries print their validity window, so you can read the June and October dates back out of your own firmware.

What 19 October does

On that date Windows Production PCA 2011 stops being usable for signing, and Windows boot managers going forward carry Windows UEFI CA 2023. A machine that has not enrolled the 2023 trust cannot run those binaries, so Microsoft holds boot-critical servicing back rather than shipping something the device would refuse. Later, full feature updates are expected to fail the upgrade deliberately rather than leave an unbootable machine, which is the right call and also a wall.

For managed Windows fleets, Microsoft delivers the certificates through monthly updates and will move high-confidence devices automatically. If you would rather drive it, the playbook documents a registry opt-in under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' `
  -Name 'AvailableUpdates' -Value 0x5944

0x5944 deploys every needed certificate and moves the device to the Windows UEFI CA 2023 signed boot manager. The same thing is available as the Group Policy setting named “Enable Secure Boot certificate deployment”, and through Intune, which is the path Microsoft recommends.

Verification has three signals worth wiring into reporting rather than eyeballing. The UEFICA2023Status registry value moves through not started, in progress, and finally updated. Event ID 1808 in the System log means the certificates landed. Event ID 1801 means they did not. Event ID 1795 is the specific one to escalate: Windows tried to hand the certificates to firmware and firmware refused, which usually means the device needs an OEM firmware update first.

One carve-out worth knowing before you build a remediation campaign: Copilot+ PCs released in 2025 are not affected, and for dual-boot machines Windows updates the certificates that Linux relies on too, since both sides read the same firmware database.

The parts each vendor’s doc stops short of

Virtual machines carry their own copy. A VM’s Secure Boot variables live in firmware the hypervisor hands it, so updating the guest does nothing. On KVM and QEMU the certificates come from the edk2-ovmf NVRAM template on the host. Update that package and newly created VMs inherit the 2023 chain. Existing ones do not, and on RHEL 9 and later you reset them explicitly:

virsh shutdown <vm>
virsh start <vm> --reset-nvram

On RHEL 8 there is no such flag and you replace /var/lib/libvirt/qemu/nvram/<vm>.fd by hand, after backing it up.

Do not force db updates on HP or Fujitsu hardware. Red Hat notes that standalone db updates are blocked on those platforms because they produced boot failures, and that those systems need a full firmware update first. This is the one place in the whole exercise where pushing harder makes things worse.

TPM-sealed disks are where you can actually lose data. Updating db changes PCR7. If your LUKS or BitLocker volumes open against TPM PCR values, reseal them against the new measurements before you reboot into a state where the TPM will not release the key. Everything else in this migration is recoverable by trying again. This one ends with someone looking for a recovery passphrase that was written down in 2023.

Golden images propagate the problem. An AMI, a VMware template, or a Packer output that carries only 2011 trust mints a new behind-the-line machine every time it runs, and it will keep doing that into 2027 without ever showing up as a failure. The same applies to self-hosted CI runners, which are usually built from those templates, live outside whatever is quietly fixing the laptops, and get rebuilt often enough that they are among the first hosts to need a shim that no longer exists in 2011-signed form. If your build agents do not run Secure Boot at all, that is fine, but it should be a decision on the page rather than something you find out during the audit.

What to do in the next eight weeks

Pull the inventory and sort it by who can act rather than by machine count. The managed Windows fleet is the easy part and Autopatch reports on it. The hard part is everything with its own firmware store: VMs, templates, build agents, and the appliance with a UEFI password nobody remembers.

Run Get-SecureBootUEFI -Name DB on one machine of each class you think you have, and mokutil --db on one of each Linux class, and compare that against what your dashboard claims. The gap between those two answers is the actual project.