Windows

Secure Boot's last 2011 certificate expires October 19

By Yaali. October 4, 2026, 6 min read, Windows, Patching.

Microsoft's Windows boot loader signing certificate expires on October 19. How to check every PC and server, and push the 2023 certificates where Windows will not.

On October 19, 2026, the Microsoft Windows Production PCA 2011 certificate expires. It is the certificate that signs the Windows boot loader, and it is the last of the three 2011 Secure Boot certificates to run out. The Microsoft Corporation KEK CA 2011 expired on June 24 and the Microsoft UEFI CA 2011 on June 27.

Machines that still trust only the 2011 certificates will keep booting after October 19. What they lose is the ability to take new protections for the early boot process: new Windows Boot Manager versions, updates to the Secure Boot allow and block lists, and fixes for boot level vulnerabilities. Microsoft is moving a large share of Windows 10 and 11 PCs to the 2023 certificates through monthly updates. Windows Server is not. Microsoft's server playbook says plainly that "Windows Server does not receive them automatically", so every physical server and Generation 2 virtual machine needs an administrator to start the change.

How it works

Secure Boot is a UEFI firmware feature that checks a signature on each piece of boot code before running it. The firmware keeps the trust anchors in a few variables. The KEK (Key Exchange Key) list holds the keys allowed to change the other lists. The DB holds the certificates whose signatures are trusted. The DBX holds revoked signatures and hashes, which is how Microsoft blocks a vulnerable boot manager after the fact.

Each 2011 certificate has a 2023 replacement. Microsoft Corporation KEK 2K CA 2023 goes into the KEK. Windows UEFI CA 2023 goes into the DB and signs the new Windows boot manager. Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 go into the DB for third party boot loaders and for option ROMs, the firmware on add-in cards.

The ordering matters. A new KEK entry has to be signed by the device's Platform Key, which belongs to the hardware maker, so OEMs sign the Microsoft KEK with their own key and Microsoft ships those signed payloads in the monthly cumulative updates. With the 2023 KEK in place, Windows can add the 2023 certificates to the DB, then install a boot manager signed by Windows UEFI CA 2023. A machine without the new KEK cannot take DB or DBX changes signed with it. A machine without Windows UEFI CA 2023 in its DB cannot boot any boot manager Microsoft signs only with the new certificate.

Where things stand

Windows client PCs that report diagnostic data are grouped into "buckets" by hardware and firmware. When Microsoft's data shows a bucket updates cleanly, it is marked high confidence, and the monthly update applies the certificates on those devices without any admin action.

Servers do not get this. The server playbook notes that machines certified for Windows Server 2025 already ship the 2023 certificates in firmware. Every other server, whether it runs Windows Server 2016, 2019, 2022 or 2025, and every Generation 2 Hyper-V guest, needs the update triggered by hand. Generation 1 VMs do not support Secure Boot and are out of scope.

What to do

1. Check every server and PC. In an elevated PowerShell session, this returns True when the new certificate is in the active DB:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

For an inventory at scale, read UEFICA2023Status under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing. It moves from NotStarted through InProgress to Updated, and Updated means the certificates and the new boot manager are both in place. A UEFICA2023Error value under the same key appears only when something failed.

2. Update firmware first. Microsoft's guidance is to install the OEM's current UEFI firmware before changing certificates, because some firmware mishandles the update and some updates also add the 2023 certificates to the firmware defaults. Dell, for example, lists minimum PowerEdge BIOS versions per model for this change. If the OEM has ended support for an older model, there may be no fixed firmware at all.

3. Protect BitLocker. Changing Secure Boot variables and the boot manager can send a BitLocker protected machine to the recovery screen on the next boot. Before you start, run manage-bde -protectors -get %systemdrive% and confirm the 48 digit recovery password is escrowed where your support desk can reach it. Dell's guidance also says to suspend BitLocker before applying its BIOS update.

4. Trigger the update on servers. Pick one method per machine; Microsoft warns against mixing them.

• Registry: set the AvailableUpdates DWORD under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot to 0x5944, which deploys all the certificates and the 2023 signed boot manager.
• Group Policy: enable Enable Secure Boot certificate deployment under Computer Configuration > Administrative Templates > Windows Components > Secure Boot. Import the latest Windows Server ADMX templates first.
• On Windows Server 2022, the Windows Configuration System (WinCS) tools can apply the feature Feature_AllKeysAndBootMgrByWinCS (key F33E0C8E002).

The work is done by the scheduled task \Microsoft\Windows\PI\Secure-Boot-Update. Microsoft says certificates usually land within about 12 hours, and setting the value does not reboot the machine. If a step needs a restart, Event ID 1800 is logged and the update finishes after the next reboot. Once the certificates are in firmware, Windows cannot remove them, so pilot on a few low impact servers of each hardware model first.

5. Decide on the client opt-out. HighConfidenceOptOut (DWORD under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot, 0 by default) set to 1 stops the high confidence update that ships in the monthly cumulative update. The matching policy is Automatic Certificate Deployment via Updates: enabling it blocks the automatic deployment. Use it only if you are running your own rollout. An opt-out without a replacement plan leaves PCs on certificates that have expired or expire on October 19.

Confirming success and reading failures

The events go to the System log from source TPM-WMI.

Events 1801 and 1808 carry BucketId and BucketConfidenceLevel fields, which show where Microsoft has classed that hardware. If AvailableUpdates sits at 0x4104 after several restarts, the machine has not got past the KEK step. Microsoft's playbook links that state to Event 1803 and says to ask the hardware maker, or the virtualization platform for a VM, whether a signed KEK is coming. Event 1795 also points at firmware, and the answer is usually a firmware update.

Plan for hardware that cannot move

Some servers will log 1803 or 1795 and have no firmware fix. They will boot, but every future boot manager fix and DBX revocation will pass them by. Keep a list of those machines with the reason, and plan them into the next hardware refresh or a move to a current VM generation rather than letting them drop off the radar.

If you want help with the inventory or the rollout, our safeguarding and hardening team does this kind of fleet wide change, and platform and cloud engineering can help with VM templates and hosts. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: Microsoft: Windows Secure Boot certificate expiration and CA updates, Microsoft: Windows Server Secure Boot playbook, Microsoft: Registry key updates for Secure Boot, Microsoft: GPO method, Microsoft: Secure Boot DB and DBX variable update events, Microsoft: Secure Boot troubleshooting guide, Microsoft: Managing boot manager revocations (KB5025885), Microsoft: Guidance for IT professionals, Google Cloud: Microsoft Secure Boot certificate expiration, Dell: PowerEdge BIOS guidelines for Secure Boot certificates.