Secure Boot certificates expire in June 2026

Microsoft’s Windows UEFI CA 2011 and Microsoft Corporation KEK CA 2011 expire in June 2026. Every Windows device with Secure Boot enabled needs the 2023 replacement certificates installed in firmware before that, or it will eventually stop receiving boot-level security updates. The deadline is real, the deployment is straightforward, and the inventory across a mixed Windows 11 and Windows Server estate is the part that takes time. I have spent the last few weeks building a tooling chain that covers all of it, and made it public on GitHub.

What is changing

Two certificates run out in June 2026:

1. Windows UEFI CA 2011 in the firmware db variable, used to sign Windows boot components.
2. Microsoft Corporation KEK CA 2011 in the firmware KEK variable, used to authorize updates to db and DBX.

Microsoft replaces them with Windows UEFI CA 2023 and Microsoft Corporation KEK 2K CA 2023 respectively. The replacements have been available since 2024 and are deployed via Intune Settings Catalog, OMA-URI, Group Policy, registry, or OEM firmware updates.

What happens if you do not update

Per Microsoft’s official guidance, devices without the 2023 certificates will continue to boot and receive normal Windows updates after June 2026. What they will not receive are future Secure Boot protections for boot components, including new revocations and updated boot manager signatures. In practice, devices become slowly less protected over time as new boot-level threats emerge.

In environments with outdated firmware, or where the certificate update fails, the symptoms are worse: BitLocker recovery prompts (sometimes in loops), startup hangs, or full failure to boot signed components. Pilot before broad deployment.

CVE-2023-24932 context

This whole transition is intertwined with the BlackLotus UEFI bootkit and CVE-2023-24932. Fully fixing the vulnerability requires updating boot trust anchors and then applying revocations so older vulnerable boot managers can no longer pass Secure Boot validation. Microsoft’s MSRC blog post is the authoritative read. The certificate update is the foundation, not the endpoint.

The four phases

I think about the work in four phases. Each one needs tooling.

Inventory. You need to know which devices are still on 2011 certificates. For Windows 11 in Intune, that is a Proactive Remediation script that reads Get-SecureBootUEFI and reports thumbprints. For Windows Server without Intune, that is an AD plus WinRM fan-out. For Azure Local, the platform handles it as part of the orchestrated update flow.

Deploy. Push the cert update via Intune Settings Catalog (SecureBoot/EnableSecurebootCertificateUpdates = 22852), Group Policy, or OMA-URI. The setting value is opt-in, the firmware applies the update on the next reboot if it can.

Verify. Read the firmware variables again and confirm both db and KEK now hold the 2023 thumbprints alongside (or replacing) the 2011 ones. Check the UEFICA2023Status registry value, which Microsoft sets to Updated when the firmware accepted the change.

Report. For an enterprise estate you need CSV evidence per device. CSV reports tied to an inventory cycle let you track migration progress over time and identify the long tail of stuck devices.

Reference UEFI thumbprints

For inventory scripts and detection logic, the four thumbprints (SHA-1) you will care about:

The repo

I have published a complete tooling chain at github.com/maskovli/secure-boot covering:

• Windows 11 + Intune. Compliance policy, Settings Catalog policies for the cert update and Device Guard / VBS, two flavours of Proactive Remediation (basic compliance check and full inventory harvest), Graph API reporting scripts.
• Windows Server + Active Directory. AD plus WinRM inventory script that fans out via Invoke-Command (parallel, throttled) to collect Secure Boot state, db/KEK thumbprints, TPM, VBS/HVCI, and Credential Guard state per host. CSV out.
• Windows Server + ConfigMgr. Configuration Items, Compliance Baselines, Run Scripts, and CMPivot queries.
• Azure Monitor / Sentinel. A Logs Ingestion API channel for the inventory data (newer addition, validate in a lab first).

Each component has a maturity status in the README so you know what is production-tested versus what is still being validated.

Microsoft references worth reading

The Microsoft Learn and TechCommunity material on this topic is genuinely good, and a few sources are essential reading before you deploy anything broadly.

Primary guidance:

• Update Secure Boot Certificates for Windows Devices (Microsoft Learn)
• Secure Boot playbook for certificates expiring in 2026 (Windows IT Pro Blog)
• Windows Server Secure Boot playbook (Windows Server News and Best Practices)

CVE and bootkit context:

• Enterprise deployment guidance for CVE-2023-24932 (Microsoft Support)
• MSRC: Guidance related to Secure Boot manager changes (CVE-2023-24932)

Operational detail:

• Updating Windows bootable media to use the PCA2023 signed boot manager
• KB: Secure Boot DB and DBX variable update events
• FAQ about the Secure Boot update process
• OEM pages for Secure Boot

Azure Local specific:

• Manage Secure Boot updates on Azure Local (Microsoft Learn)

Get started

If you are starting from zero on this, the order I would follow:

1. Read the Microsoft Learn primary article end to end.
2. Read the Windows IT Pro Blog playbook.
3. Clone github.com/maskovli/secure-boot and run the local validation script (Test-SecureBootInventoryLocal.ps1) on your own machine first.
4. Deploy the inventory Proactive Remediation to a small Intune pilot group.
5. Pull the report, see the spread, plan the rollout.

The deadline is fixed. The work is not optional. The tooling is now mature enough that nobody should be doing this by hand.

---