Secure Boot 2011 CA expires June 2026: KB5025885 and Secure Score check

TL;DR

Expiration dates Microsoft Corporation KEK CA 2011: 2026-06-24 / Microsoft UEFI CA 2011 (third-party): 2026-06-27 / Microsoft Windows Production PCA 2011 (Windows boot loader): 2026-10-19.

New Secure Score check “Ensure devices are updated to Secure Boot 2023 certificates and boot manager” (MC1293483, GA May 2026).

Rollout steps Per KB5025885 enterprise guidance, set HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\AvailableUpdates to 0x140 (add DB + update Boot Manager) → verify → 0x280 (revoke PCA2011 + bump SVN). Two-phase apply.

After expiry No bricking. Devices boot and Windows Update keeps working, but Secure Boot DB/DBX updates, new boot-kit mitigations, and BitLocker bypass fixes stop being delivered.

Background The 2023 CA was issued early to address the 2022 BlackLotus boot kit; it now lines up with the 2011 CA’s natural 15-year expiry, and the two were folded into one rollover project.

I covered the Windows Recovery Environment side of the Secure Boot trust chain in the YellowKey CVE-2026-45585 BitLocker bypass article.
That one was a specific vulnerability mitigation. This one is structural: the root CAs of Secure Boot itself expire starting in June 2026.

In response, Microsoft added a new Secure Score check in Defender for Endpoint in May 2026 — it scores your fleet on whether the 2023-signed Boot Manager and 2023 CA have been distributed.

Leaving it alone doesn’t make devices stop booting in June, but new early-boot vulnerabilities surfacing after June won’t have mitigations delivered to those devices.
If something like BlackLotus surfaces again, those devices won’t receive the fix.

The three certificates that expire

From Microsoft’s official support article, the expiration schedule:

Certificate	Expiry	Stored in	2023 successor
Microsoft Corporation KEK CA 2011	2026-06-24	KEK	Microsoft Corporation KEK 2K CA 2023
Microsoft UEFI CA 2011 (third-party OS / option ROM signing)	2026-06-27	DB	Microsoft UEFI CA 2023 / Microsoft Option ROM UEFI CA 2023
Microsoft Windows Production PCA 2011 (Windows boot loader signing)	2026-10-19	DB	Windows UEFI CA 2023

The KEK expiring first matters most.
KEK (Key Exchange Key) is the CA that holds signing authority over writes to DB and DBX (allow / deny lists). Once KEK CA 2011 expires, no further revocation entries can be added to DB.
So dbx (the revocation list) itself doesn’t expire, but no new revocation entries can be pushed.

For DB, July brings the UEFI CA 2011 expiry (third-party OS signing — Linux shims are trusted via this CA) and October brings Windows Production PCA 2011 expiry (Windows Boot Manager signing).
Once the Windows Boot Manager signing CA expires in October, freshly built Windows boot media will only start on devices whose DB carries the 2023 signature.

New Secure Score check (MC1293483)

In May, Microsoft 365 Message Center notice MC1293483 announced a new entry added to Defender for Endpoint’s Secure Score (Microsoft Secure Score for Devices).

Item	Value
Full name	Ensure devices are updated to Secure Boot 2023 certificates and boot manager
Target	Windows 10 / Windows 11 / Windows Server
What it measures	Identifies devices missing Windows UEFI CA 2023 and the 2023-signed Boot Manager, and rolls fleet readiness into the score
Rollout	Public Preview late April–early May 2026, GA early–late May 2026
Configuration	On by default, no config required

If you have Defender for Endpoint, the recommendation should already be visible in Secure Score.
If it isn’t, either the tenant rollout hasn’t landed yet, or the devices haven’t reached the check boundary.

aka.ms/GetSecureBoot and aka.ms/secureboot-mde are Microsoft’s official entry-point URLs.

KB5025885 two-phase rollout

The actual deployment runbook is KB5025885 (enterprise deployment guidance for CVE-2023-24932).
It covers Windows 10 / 11 / Server. The relevant registry is HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\AvailableUpdates (DWORD).

Bit flags control the phase.

Value	Effect
`0x40`	Add the PCA2023 certificate to DB
`0x80`	Update to the 2023-signed Boot Manager
`0x100`	Revoke PCA2011 via DBX
`0x200`	Bump the Boot Manager SVN (Secure Version Number) for rollback prevention

The guidance recommends staged application as follows.

Phase 1: AvailableUpdates = 0x140 (= 0x40 + 0x80)

Add PCA2023 to DB and update the Boot Manager to the 2023-signed version.
This phase is reversible — the 2011 CA boot path is still present if something goes wrong.

After two or more reboots, verify the WindowsUEFICA2023Capable flag is 2.

# Verification
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot' WindowsUEFICA2023Capable

Phase 2: AvailableUpdates = 0x280 (= 0x100 + 0x200)

Revoke PCA2011 via DBX and bump Boot Manager SVN.
This operation is irreversible while Secure Boot is enabled — you can’t roll back.
Apply on pilot devices, validate, then roll out to the fleet.

When the phase completes, AvailableUpdates auto-clears to 0x000.

A note on the MicrosoftUpdateManagedOptIn key referenced in secondary sources: it appears to be an opt-in key that lets Windows Update perform the staged rollout automatically, but I couldn’t confirm the verbatim documentation from Microsoft’s primary source (uncertain).
Whether to opt in (Windows Update-driven) or self-drive Phase 1 first is a policy choice.

What stops working after expiry

Microsoft’s support article states: post-expiry behavior is “devices boot and operate as usual.” Regular Windows Updates continue.

What stops being delivered:

Windows Boot Manager updates
Secure Boot DB / DBX updates
Revocation list updates
New early-boot vulnerability mitigations
BitLocker bypass mitigations
“Third-party components dependent on Microsoft Secure Boot trust” updates

Not a brick, not boot failure — the security posture degrades cumulatively over time.

The practical implication: from June 2026 onward, devices that didn’t migrate sit in a state where new boot-kit mitigations don’t reach them.
You may not notice for one or two years; but during a five-year support lifecycle, if a new UEFI boot kit drops, those devices stay vulnerable.

OEM firmware update is a prerequisite

Touching the Windows registry alone isn’t enough.
An OEM firmware update is a precondition — if the UEFI firmware can’t accept the new 2023 certs, the KEK / DB writes from Windows fail.

Major OEMs (Surface, Dell, HP, Lenovo) have been shipping the corresponding firmware updates.
Microsoft’s own Windows Security app added a new status badge in April 2026.

Color	Meaning
Green	Done
Yellow	Waiting on auto-delivery, or hardware constraint
Red	Action required

Don’t forget VMs.
VMware KB notes certificate-update failure cases; both Hyper-V and VMware VMs are in scope.
The Secure Boot template on the VM side (VM TPM Configuration on VMware, Set-VMFirmware on Hyper-V) needs updating too.

Why the 2023 CA: the BlackLotus connection

“The 2011 CA’s 15-year lifespan just happens to end in June 2026” is only half the story.
The 2023 successor CAs were issued in response to the September 2022 BlackLotus boot kit.

BlackLotus — reported by Kaspersky / ESET in September 2022 — was the first in-the-wild UEFI boot kit.
It used CVE-2022-21894 (Baton Drop, patched January 2022) to roll back to an older Boot Manager, evade Secure Boot, and persist in the EFI system partition.
The old Boot Manager was signed by the 2011 CA, and until the 2011 CA was removed from DB outright, per-binary DBX revocations could be evaded.

Microsoft disclosed CVE-2023-24932 on 2023-05-09 and designed a four-stage mitigation: “stop trusting the 2011 PCA structure itself, move to a new CA (Windows UEFI CA 2023), and revoke the old Boot Manager via DBX.” That’s the body of the KB5025885 guidance.

So the 2023 CA — issued early as the BlackLotus mitigation — happened to line up with the 2011 CA’s natural 15-year expiry, and the two converged into the same June 2026 rollover project.
”Routine 2011 CA expiry” and “permanent BlackLotus-class mitigation” are running as two faces of the same migration.

Admin checklist

#	Step	Notes
1	Roll OEM firmware updates to the whole fleet	This comes first; Windows-side changes follow
2	Escrow BitLocker recovery keys	DB changes affect TPM measurements and can trigger recovery mode
3	Pilot Phase 1 (`0x140`)	Reboot ≥ 2 times → verify `WindowsUEFICA2023Capable = 2`
4	Update bootable media (KB5053484)	Re-sign ISO / USB / PXE / WinRE under PCA2023
5	Pilot Phase 2 (`0x280`)	Validate, then roll out to fleet
6	Track via Defender for Endpoint / Secure Score	Use the new recommendation as the fleet-progress dashboard

Skipping the WinRE update leaves a path where Recovery boots the 2011-signed bootmgr and fails, so step 4 (bootable media update) is easy to forget.

Windows 10 ESU environments are expected to receive the rollout, but ESU-specific rollout timing should be confirmed with Microsoft on a case basis.

UEFI-area work isn’t something you touch often, and I had to re-read the guidance to remember “wait, what was KEK again.” A 2011-issued CA running for 15 years before flipping over isn’t a time scale that’s in muscle memory.
The fact that firmware sits on a longer software timescale than apps becomes visible exactly at these expirations.

It’s an independent topic from the YellowKey BitLocker mitigation, but both belong to the same family of “old parts of the Secure Boot trust chain driving change.”
The June 2026 KEK expiry is a good moment to inventory Windows-side Secure Boot work once more.