Secure Boot Certificate Expiry 2026: Deploying the 2023 Microsoft UEFI CAs Safely

The Microsoft certificates that anchor UEFI Secure Boot on almost every Windows PC, server and many Linux machines reached the end of their 15-year life during 2026, and devices that never receive the 2023 replacements are now frozen at their current boot security level. Nothing stops booting on expiry day, which is why many fleets have not acted. The risk is quieter: no new boot manager fixes, no new revocations, failed installs from future media and, for Linux, shim updates that will not boot. This guide is the deployment companion to the general Firmware and Boot Security Guide: which certificates are involved, how the DB and KEK updates are applied through registry, Group Policy and Intune, what firmware and Linux shim dependencies exist, and how to test and recover. It is written for endpoint, server and platform engineers. Dates and settings were checked against Microsoft's support articles on 8 November 2026.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Four certificates, three dates. The Microsoft Corporation KEK CA 2011 expired on 24 June 2026, the Microsoft UEFI CA 2011 on 27 June 2026 and the Microsoft Windows Production PCA 2011 on 19 October 2026, according to Microsoft KB5062710.
• Expiry does not brick devices. Firmware does not check CA expiry, so existing signed boot code keeps running; what stops is the ability to receive new early-boot protections signed by the 2011 chain.
• The update writes to firmware. Windows adds the 2023 certificates to the UEFI DB and KEK and installs a boot manager signed by the Windows UEFI CA 2023. Once in firmware, the certificates cannot be removed from Windows.
• The KEK step depends on your OEM. A KEK update must be signed by the manufacturer's Platform Key; where none exists, Event 1803 is logged and Microsoft states there is no supported manual recovery path.
• Linux needs the firmware update first. New shim releases are signed only with the Microsoft UEFI CA 2023, so update DB and KEK before taking a 2023-only shim, and never revoke the 2011 CA while dual-signed shims are in use.

What is changing and why

UEFI Secure Boot checks every pre-boot component against signature databases held in firmware NVRAM. The Platform Key (PK) belongs to the OEM; the Key Exchange Key (KEK) database authorises updates to the allowed database (DB) and forbidden database (DBX). Microsoft's certificates sit in the KEK and DB of most x64 devices, which is why one expiry affects Windows and Linux alike. The background on keys, modes and BlackLotus is covered in the Firmware and Boot Security Guide; this page focuses on the rotation itself.

Microsoft split the third-party CA in two so that an organisation can trust signed option ROMs without also trusting every third-party boot loader. That gives locked-down Windows-only fleets a way to narrow the DB rather than simply renewing what they had.

Expiry limits when a key can sign, not whether firmware will run code it already signed. Red Hat states that a 2011-signed shim "will continue to boot as long as the public certificate is not removed from or revoked", and Canonical states that firmware does not check CA expiry. The practical effect is a fork: devices with the 2023 certificates continue to receive boot fixes and revocations; devices without them do not.

Official timeline and current status

As announced on 22 October 2026 in KB5132953, the last Windows boot managers signed with PCA 2011 are frozen: they get no further code or security changes, and all future boot manager fixes are signed only with the Windows UEFI CA 2023 chain. Future installation media boots the 2023-signed boot manager by default, and Microsoft says future major Windows releases will require the 2023 certificate in DB to boot media and complete Setup. No date has been given for either, so treat them as near-term and plan accordingly.

Microsoft attempts the update automatically for many devices that send diagnostic data, through confidence-based deployment in monthly updates or the Controlled Feature Rollout. The FAQ calls this an assist, not a guarantee. Organisations that manage their own update cadence, block diagnostic traffic or run servers should assume they must drive the change themselves.

Who and what is affected

• Windows clients and servers: KB5062710 lists Windows 10 (1607, 22H2, LTSC and IoT), Windows 11 21H2 to 24H2 and Windows Server 2012 ESU through 2025. All share the same Microsoft certificates in KEK and DB.
• Linux on Secure Boot hardware: any distribution booting through a Microsoft-signed shim. Existing shims keep booting; future shims signed only by the 2023 CA will not boot without it in DB. Red Hat notes RHEL 7.9 will not receive a dual-signed shim.
• Virtual machines: Generation 2 Hyper-V guests receive the certificates through cumulative updates (Microsoft's troubleshooting guide says this needs the March 2026 updates on both the Hyper-V host and the guest, and Event 1795 in a guest means the host is missing them). Azure Trusted Launch and Confidential VMs are serviced by the platform, and Confidential VMs with old certificates must be recreated. VMware estates need updated ESXi hosts and VM hardware versions.
• App Control and signer allowlists: KB5132953 warns that App Control for Business (WDAC) policies, signed-catalog rules and CI/CD allowlists pinned to PCA 2011 can block Windows binaries now signed by replacement CAs, showing as failed cumulative updates, services failing at start and Code Integrity Event 3077.
• Endpoint products: third-party security tools that inspect Authenticode signers directly need confirmation from the vendor that the replacement chains are trusted.
• Old hardware: devices whose OEM never ships a PK-signed KEK or whose firmware cannot write DB. Red Hat names certain HP and Fujitsu models that could not receive DB updates at the time of its post.
• Deployment infrastructure: PXE, WDS and ISO media that boot a 2011-signed boot manager, and anything chained from them.

Finding affected systems and identities

Inventory has three questions per device: is Secure Boot on, which certificates are in DB and KEK, and which boot manager is running. Servicing does not progress while Secure Boot is off, and those devices remain exposed to bootkits (ATT&CK T1542.003 Bootkit) regardless of certificates.

Windows registry state

Under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing (KB5068202):

Under the parent SecureBoot key, AvailableUpdates is a bitmask that clears as each step succeeds; Microsoft's troubleshooting guide says a completed run ends at 0x4000. Collect these with an Intune remediation detection script, Configuration Manager hardware inventory or your RMM tool.

Event log

All events are in the System log, source TPM-WMI (KB5016061). The ones that matter for reporting:

Linux and VMs

Check mokutil --sb-state, then mokutil --db for "Microsoft UEFI CA 2023" and mokutil --kek for "Microsoft Corporation KEK 2K CA 2023"; efi-readvar -v db works where mokutil is absent. To see which keys signed the installed shim, Red Hat documents pesign -S against the shim binary.

Where identity fits

The non-human side of this change is signing trust, not accounts. Inventory every place that pins a Microsoft signing CA: App Control policy XML, build pipeline signer allowlists, private trust stores and code that checks certificate thumbprints. Microsoft's guidance is to use publisher rules and the WinVerifyTrust API rather than pinning to a CA or thumbprint, which is the same principle as avoiding hard-coded credentials. Also confirm BitLocker recovery keys are escrowed before any device enters the rollout; see the BitLocker guide.

Migration options

Choosing: a small organisation with consumer-grade devices on Windows Update and diagnostic data enabled can usually let Microsoft's automatic deployment run and monitor the Windows Security app status. Any estate with servers, App Control, Linux dual boot, PXE or strict change control should set HighConfidenceOptOut during testing and drive the change by ring, so that a firmware fault appears on ten devices rather than ten thousand. Do not mix Intune or Group Policy with direct registry writes on the same device: AvailableUpdatesPolicy is written by policy and should not be edited.

Revocation is a separate decision. Adding PCA 2011 to DBX (value 0x80, Event 1037) and raising the boot manager Secure Version Number (0x200, Event 1042) complete the BlackLotus mitigation, but cannot be undone while Secure Boot is on. Do it only after all media and recovery paths boot the 2023 boot manager. On dual-boot or Linux machines, never revoke the Microsoft UEFI CA 2011: Red Hat warns a dual-signed shim fails if either key is in DBX, and 2011-signed option ROMs stop running.

Testing and rollback

1. Prepare: escrow BitLocker recovery keys; record firmware version per model; update OEM firmware first where the vendor has a Secure Boot release; confirm the \Microsoft\Windows\PI\Secure-Boot-Update task reads Ready with schtasks /Query.
2. Lab one device per model: set AvailableUpdates to 0x5944, run the scheduled task, restart when prompted, run it again, and confirm UEFICA2023Status = Updated, AvailableUpdates = 0x4000 and Event 1808. Test a cold boot, a BitLocker unlock, PXE, recovery media and any dual boot.
3. Pilot ring by bucket: group devices by BucketHash so each firmware family is represented, and expand only when a bucket shows no 1795, 1796 or 1032 events. The task runs every 12 hours, so allow at least two cycles and a restart per ring.
4. Media and infrastructure: refresh WDS and PXE boot images and USB media; Microsoft provides Make2023BootableMedia.ps1 for older media. Microsoft's troubleshooting guide reports repeated BitLocker recovery when PXE is first in boot order: put the disk first or PXE-boot a 2023-signed loader.
5. Linux: update DB and KEK through fwupd or the hypervisor before installing any 2023-only shim. Microsoft's Azure Linux article warns that updating shim first can cause boot failure. Where LUKS unlock is sealed to TPM PCR7, Red Hat advises resealing because PCR7 changes after the DB update.
6. Broad rollout: enable the Intune or GPO setting for the remaining rings; report weekly on status counts.

Rollback reality: plan as if certificates already written to firmware cannot be rolled back from Windows. The useful rollback actions are narrower. Stop further devices by setting HighConfidenceOptOut and removing the deployment policy (remember the GPO value persists). If a device fails to boot after a firmware reset cleared DB, Microsoft documents a recovery USB with SecureBootRecovery.efi copied as \EFI\BOOT\bootx64.efi, which re-applies one certificate; re-apply the rest afterwards. Watch for the media reversion script that KB5132953 says Microsoft will provide, for hardware with no OEM fix that must boot the frozen 2011 boot manager.

Risks of doing nothing

• No future boot fixes: the next BlackLotus-class vulnerability will be fixed only with 2023-signed boot managers and DBX entries signed by the 2023 KEK. An unpatched boot chain is where bootkits (T1542.003) and firmware implants (T1542.001) persist below the operating system and its EDR.
• Install and upgrade failures: Microsoft says future major releases and media will require the 2023 certificate; booting such media on a device without it fails with a Secure Boot violation.
• Linux update blockage: Canonical expects future releases and updates from Q4 2026 to need the 2023 CA; Red Hat says devices without it will have to keep a vulnerable shim or disable Secure Boot.
• Pressure to turn Secure Boot off: the worst outcome is a help desk disabling Secure Boot to get a build to install, which also breaks BitLocker's PCR7 binding and removes the bootkit control altogether.

Practitioner checklist

• Report Secure Boot state, UEFICA2023Status, UEFICA2023Error and BucketHash for every Windows device and server.
• Escrow and verify BitLocker recovery keys before any device enters the rollout.
• Apply OEM firmware with Secure Boot updates first; open supplier cases for models logging 1795, 1802 or 1803.
• Choose one deployment channel per device group (automatic, registry, GPO or Intune) and pilot one device per firmware bucket.
• Refresh PXE, WDS and USB media to the 2023 boot manager before broad rollout.
• Review App Control policies and pipeline allowlists for rules pinned to PCA 2011; test replacements in audit mode.
• On Linux, update DB and KEK through fwupd or the hypervisor before 2023-only shims, and reseal TPM-bound LUKS keys.
• Track metrics: percentage of devices with Event 1808, devices in InProgress for more than 14 days, count of 1803 devices by model, BitLocker recovery tickets per ring, and devices with Secure Boot off.
• Treat DBX revocation of PCA 2011 as a separate, later change with its own approval.

Standards and references

• Microsoft: Windows Secure Boot certificate expiration and CA updates (KB5062710)
• Microsoft: Windows Production CA 2011 expiration and bootloader updates (KB5132953)
• Microsoft: Registry key updates for Secure Boot with IT-managed updates
• Microsoft: Secure Boot DB and DBX variable update events (KB5016061)
• Microsoft: Intune method of Secure Boot for Windows devices with IT-managed updates
• Microsoft: Secure Boot troubleshooting guide
• Red Hat: Expiration of Secure Boot signing certificates in 2026
• Canonical: Microsoft UEFI CA rotation, what it means for Ubuntu users and vendors

Related NHI Mgmt Group resources: Firmware and Boot Security Guide · Linux Secure Boot and Shim Guide · Firmware and Bootkit Compromise Playbook · Microsoft Intune Guide · BitLocker