Secure Boot's 2011 Certificate Expired on 19 October: What to Check on Your Windows Servers

On 19 October 2026 the Microsoft Windows Production PCA 2011 certificate reached the end of its 15-year life. Three days later Microsoft published KB5132953, and its first point is reassuring: the expiration "does not cause computers to stop turning on or prevent Windows from starting." The second point is the one to read twice. The last Windows Boot Manager builds signed with the 2011 certificate are now "frozen in static binary form" and will not receive future security patches.

So nothing broke on 20 October. What changed is quieter. Any server whose firmware still trusts only the 2011 chain has stopped receiving boot-level fixes, and the next boot manager vulnerability Microsoft patches will pass it by. For a small company with a few physical hosts and a couple of dozen VMs, sorting this out takes an afternoon if you do it now. Waiting until a boot exploit is in the news makes it a weekend.

The October patch cycle has already been busy for anyone running Microsoft servers on their own hardware (we covered the Exchange side of it here). This one is less noisy and touches every Windows machine with Secure Boot turned on.

The three expiry dates, in one place

Microsoft's Secure Boot certificate expiration page lists the 2011 certificates and what replaces them:

The June dates passed without much fuss. October matters more because the Production PCA signs the Windows boot loader itself, and Microsoft also used it for ordinary Windows files. According to KB5132953, since 19 October Microsoft "no longer digitally signs any binary or security catalog using the 2011 PCA certificate."

What actually changed after 19 October

Reading KB5132953 with a server room in mind, four changes stand out:

• Every future security patch for the Windows boot loader is signed only with the Windows UEFI CA 2023 chain. A server whose firmware signature database (DB) lacks that certificate cannot use those patches.
• Future installation media for current Windows versions will boot by default with the 2023-signed boot manager. On hardware whose firmware lacks the 2023 certificate, that media fails with a Secure Boot violation unless you run the reversion script Microsoft says it will provide.
• Future major Windows client and server releases will need Windows UEFI CA 2023 in the DB just to boot their installation media.
• App Control for Business (WDAC) policies, CI/CD signature checks and security tools that pin trust to PCA 2011 may block updated Windows files. Microsoft lists failed cumulative updates, services failing at startup and Code Integrity Event 3077 as symptoms.

Which machines need attention

KB5132953 applies to Windows 11, Windows 10 ESU, Windows Server 2019, 2022 and 2025, and Azure. Home users on Windows Update don't need to do anything, Microsoft says. The article is written for teams that manage their own updates, and in small and mid-sized setups these are the cases we run into most:

• Physical servers with Secure Boot enabled, particularly older models whose vendor no longer ships BIOS updates.
• Hyper-V Generation 2 VMs. Microsoft says they receive the new certificates through normal cumulative updates, so your job is to confirm it actually happened.
• VMware guests. Microsoft's advice is to bring ESXi hosts and VM hardware versions up to releases whose guest UEFI templates include the 2023 certificates.
• Anyone running App Control policies, or endpoint software that inspects Authenticode signatures directly.
• Teams that still build servers from old USB sticks or PXE images.

Windows Server 2016 deserves its own line. It appears in the older boot manager guidance, KB5025885, but not in KB5132953, and the Windows Server 2016 lifecycle page puts the end of extended support in January 2027. If you still run 2016 hosts, plan the OS move and the certificate work together. The same logic drove our Exchange 2016/2019 exit plan: one maintenance project beats two rushed ones.

Check status with PowerShell

Run these from an elevated PowerShell window. Start with whether Secure Boot is on at all. Confirm-SecureBootUEFI returns True or False, and an error on hardware that doesn't support UEFI Secure Boot.

Confirm-SecureBootUEFI

Next, read the servicing keys documented on Microsoft's Secure Boot registry key page. UEFICA2023Status moves from NotStarted to InProgress to Updated. A non-zero UEFICA2023Error means a step failed, and UEFICA2023ErrorEvent tells you which event ID to look up.

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' |
  Select-Object UEFICA2023Status, UEFICA2023Error, UEFICA2023ErrorEvent

To see whether the firmware DB already holds the new Windows certificate, KB5025885 gives this one-liner. It should return True:

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

Then check the System log. KB5016061 explains the event IDs: 1801 means the certificates "have been updated but are not yet applied to the device firmware", 1808 means "This device has updated Secure Boot CA/keys", 1795 is an error returned by the firmware, and 1803 means no PK-signed KEK exists for the device, which is a question for the hardware vendor.

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1795,1796,1801,1803,1808} -MaxEvents 20 |
  Format-Table TimeCreated, Id, Message -Wrap

If you need to open a case with the server manufacturer, Microsoft's IT guidance page collects firmware details with these inventory commands:

(Get-CIMInstance Win32_BIOS).Description + ", " + (Get-CIMInstance Win32_BIOS).ReleaseDate.ToString("MM/dd/yyyy")
(Get-CIMInstance Win32_ComputerSystem).Manufacturer
(Get-CIMInstance Win32_ComputerSystem).Model
(Get-CIMInstance Win32_BaseBoard).Product

Applying the update, step by step

Pick one non-critical server of each hardware model first. The order below follows Microsoft's documented test procedure.

1. Save the BitLocker recovery key. KB5132953 warns that unexpected recovery prompts can follow boot-chain updates. KB5025885 shows how to read the 48-digit recovery password: manage-bde -protectors -get %systemdrive%
2. Install the latest BIOS/UEFI firmware from the server vendor. Microsoft's guidance tells admins to check with the OEM for updated firmware, and events 1795 and 1803 usually point the same way.
3. Trigger the deployment and run the scheduled task now instead of waiting for its 12-hour cycle. Both commands come from the registry key page:

   reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
   Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

4. Watch AvailableUpdates. When it reads 0x4100, restart the server and run the scheduled task again. It should settle at 0x4000 once the boot manager has been replaced.
5. Confirm that UEFICA2023Status reads Updated and that event 1808 shows up in the System log.
6. Roll out to the rest. In Group Policy the setting is "Enable Secure Boot Certificate Deployment" under Computer Configuration, Administrative Templates, Windows Components, Secure Boot (see Microsoft's GPO method). Intune has its own equivalent policy.

Starting the deployment does not force a restart. Per the registry key page, the boot manager swap waits for the next normal restart, which for most servers means the next patch window.

App Control and old install media

If you use App Control for Business, KB5132953 asks you to search policy XML for signer rules that reference Microsoft CAs, including rules inherited from example base policies, and to push changes in audit mode before enforcing them. An earlier Microsoft article on new CA handling says App Control infers trust for replacement CAs when a policy already trusts the current ones. We would still run audit mode first. Custom policies and third-party agents are where the surprises tend to live.

For media, Microsoft publishes Make2023BootableMedia.ps1 to convert existing ISOs and USB sticks to the 2023 boot manager (KB5053484). Keep one older stick, clearly labelled, for hardware still waiting on a firmware update.

Rollback: what you can and cannot undo

Say this to your team before you begin: Microsoft documents how to stop a deployment, not how to pull certificates back out of firmware.

• Before the task runs: per the registry key page, an AvailableUpdates value of 0 means no Secure Boot key updates are performed. If the value came from Group Policy, removing the GPO leaves it in place, so reset it yourself.
• Automatic rollout: setting HighConfidenceOptOut to 1 opts a device out of the high-confidence buckets Microsoft applies through the monthly cumulative update. Use it on hardware you already know is fragile, then return to it after a firmware update.
• Firmware reset to defaults: KB5025885 warns that a device whose Secure Boot settings are reset to defaults after the mitigations "will not boot", and it documents a recovery USB built from securebootrecovery.efi that puts the 2023 certificate back in the DB. Tell whoever has BIOS access not to restore factory keys on an updated server without checking with you.

Certificate expiry is easy to ignore until the day it isn't. We keep a single calendar of every certificate and support date across the servers we run, from public TLS (see how we renew one wildcard across several servers) to firmware keys like these.

Frequently asked questions

If you would rather hand the firmware checks, patch windows and monitoring to someone else, Fanpino runs this work for small and mid-sized teams. See our cloud infrastructure and DevOps services.

Sources: KB5132953: Windows Production CA 2011 expiration and bootloader updates (Microsoft Support, 22 October 2026), Windows Secure Boot certificate expiration and CA updates, Registry key updates for Secure Boot, KB5016061: Secure Boot DB and DBX variable update events and KB5025885.

Certificate lifetimes are shrinking: TLS certificate lifetimes in 2027 and what to audit.