Plan a 2023 Secure Boot Certificate Rotation Before 2026 Expiry

The tools and knobs you need to avoid a mid‑2026 Secure Boot disruption are now available — but this is not a “set it and forget it” operation. Organizations must inventory, pilot, coordinate with OEMs, and execute a staged rollout to ensure UEFI Secure Boot trust anchors are rotated to the 2023 certificate family before the 2011 CAs begin expiring in June 2026.

Background / Overview​

Secure Boot and UEFI trust anchors
Secure Boot depends on a small set of cryptographic trust anchors that live in firmware variables: the Platform Key (PK), Key Exchange Key (KEK), the Allowed Signature Database (DB), and the Revoked Signatures Database (DBX). These anchors are X.509 certificates with real expiration dates. Certificates issued around 2011 (for example, the Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011) are scheduled to begin expiring in June 2026; a separate Windows boot‑manager PCA from 2011 expires later in October 2026. If a device still trusts only the older 2011 certificates when those dates arrive, the platform may stop accepting new pre‑boot signatures and could lose the ability to receive future Secure Boot/boot‑manager updates unless new certificates are installed first.
Why this matters now
This is both a security hygiene event and an operational lifecycle event. Beyond preserving the ability to receive future pre‑boot protections, the rollout is tied to mitigations for the BlackLotus UEFI bootkit (CVE‑2023‑24932). The mitigations and the certificate rotation are interlinked: updated certificates and boot manager signatures let Microsoft and OEMs deliver revocations and hardening that close real pre‑boot attack paths. Applying those mitigations incorrectly, or on firmware that is not ready, can cause wide‑scale recovery and boot issues — which is why a careful, test‑first deployment is mandatory. What Microsoft and partners are providing today
Microsoft has published an IT playbook and supporting registry keys, command‑line tools, and Group Policy settings so administrators can proactively trigger and monitor certificate rotations. OEMs are delivering firmware/BIO S updates to ensure firmware will accept OS‑initiated updates to the KEK/DB/DBX variables where allowed. Microsoft’s OS‑side flow is packaged into Servicing Stack + Cumulative/LCU updates and includes a scheduled task that inspects a Secure Boot AvailableUpdates bitmask and processes operations in a strict order. For many devices that share diagnostic/telemetry data and accept OS‑initiated UEFI variable writes, Microsoft intends to manage updates automatically; for other devices IT will need to intervene.

---

Inventory and prepare your environment​

1) Inventory: know what you have​

Start with a complete, firmware‑aware inventory. Key items to capture per device:

• System Manufacturer and OEM Model
• BIOS / UEFI version and date
• Secure Boot state (enabled/disabled)
• Presence of 2023 CA entries in firmware DB/KEK
• Windows build level, SSU/LCU status, and management channel (WSUS/Intune/Windows Update)
• BitLocker status and where recovery keys are stored

Sample checks: use msinfo32, Confirm‑SecureBootUEFI, and Get‑SecureBootUEFI. Use centralized telemetry / MDM / SIEM to pull the System event log for Event IDs 1801 and 1808 (see Monitoring section). Microsoft’s guidance includes sample PowerShell inventory scripts to help build this dataset. Why model‑level sampling matters
Not all firmware behaves identically. Devices manufactured since 2024 are likely to already include the 2023 certificates or to accept Microsoft’s OS‑delivered updates, but less common or older models — and specialized appliances or virtual platforms — are the highest risk. Build a representative sample set that includes high‑value hardware (e.g., branch servers, kiosk machines, shared lab devices), older models, and any air‑gapped systems.

2) Prepare recovery and image hygiene​

Before you change any Secure Boot variables:

• Back up and securely store BitLocker recovery keys (Azure AD, AD DS, or offline vault).
• Preserve golden images and current winre.wim / boot media; inject or validate the updated Safe OS DU in offline media if you manage images.
• Create updated recovery USBs that include the new boot manager and/or updated WinRE where applicable.

Failure to have validated recovery media is the single largest operational risk — a failed firmware write or unexpected DBX revocation can trigger BitLocker recovery that can be time‑consuming and costly to remediate.

---

Monitoring and verification​

Registry keys and the Scheduled Task​

Microsoft exposes a set of registry values under:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

Important keys to know:

• AvailableUpdates (REG_DWORD bitmask) — set to 0x5944 (hex) to request deploy all operations (add the 2023 CA entries, update KEK, and install the 2023‑signed boot manager).
• UEFICA2023Status (REG_SZ) — reports NotStarted, InProgress, or Updated as the scheduled task progresses.
• UEFICA2023Error (REG_DWORD) — non‑zero indicates a deployment error on that device.
• HighConfidenceOptOut and MicrosoftUpdateManagedOptIn — control Microsoft‑managed assists and opt‑in behavior.

The scheduled Secure Boot update task runs roughly every 12 hours and processes AvailableUpdates bits in a strict, order‑sensitive sequence. Don’t attempt to force every bit at once on a device without testing; the process was designed to ensure new trust anchors exist before dependent artifacts are changed.

Windows Event Log events to track​

Use the System log (Event Viewer > Windows Logs > System) and search for TPM‑WMI events. Key events:

• Event ID 1808 — informational: the device has successfully applied the new Secure Boot certificates and the boot manager is updated to one signed by Windows UEFI CA 2023.
• Event ID 1801 — error: the updated certificates were not applied; the event includes device attributes and a confidence indicator (High Confidence / Needs More Data / Unknown / Paused) to help triage fleets.
• Additional related events include 1797–1799 and 1795 for DB/DBX variable updates; consult Microsoft’s Secure Boot DB/DBX events documentation for complete mappings.

Practical monitoring tips

• Aggregate 1801/1808 events centrally (SIEM, Splunk, Event Forwarding) and build a dashboard by confidence level and by OEM model.
• Correlate UEFICA2023Status and UEFICA2023Error per machine with event log findings for faster root cause analysis.
• For pilot devices, collect full System logs and firmware version strings to share with OEM support if remediation is needed.

---

Firmware updates and OEM coordination​

Why OEM firmware matters​

OS‑initiated updates can only write UEFI variables when the firmware permits it; OEMs control PK/KEK semantics and often supply KEKs signed with their PK. If firmware blocks OS writes or contains bugs, the OS cannot complete the rotation. For many devices Microsoft packages OEM‑signed KEKs into servicing updates only after OEM submission. That makes OEM firmware updates the principal gating factor for some device families.
What to ask your OEMs

• Confirm per‑model minimum BIOS/UEFI versions that accept OS‑initiated KEK/DB/DBX updates.
• Ask whether the OEM will publish explicit instructions or tools for offline key enrollment for air‑gapped fleets.
• Request OEM guidance about BitLocker interactions and whether firmware changes will trigger recovery on specific models.

Note: vendor coverage is variable. Do not assume uniform OEM support across all SKUs — verify per model. This is an operational dependency that cannot be fully validated from Microsoft’s side.

---

Deployment options (step‑by‑step playbook)​

Pick one primary method per device or per group — do not mix methods on the same device.

Option 1 — Registry key deployment (for on‑prem / scripted rollouts)​

• Ensure device has required Windows build and SSU/LCU that contains the registry key support.
• On test devices set AvailableUpdates to 0x5944 under the Servicing path. The scheduled task will process operations; allow 48 hours and one or more restarts for full completion.
• Monitor UEFICA2023Status, UEFICA2023Error, and Event IDs 1801/1808 for success/failure.
• If UEFICA2023Error is non‑zero or AvailableUpdates does not clear the 0x0004 bit (KEK update), escalate to OEM for a signed KEK or firmware revision.

Option 2 — Windows Configuration System (WinCS) CLI​

• Use the WinCS CLI and PowerShell module available in current Windows updates for domain‑joined clients (Windows 11 versions 23H2/24H2/25H2). Typical feature name: Feature_AllKeysAndBootMgrByWinCS with a WinCS key value shown in Microsoft guidance. Use WinCS to query status and to apply updates on single machines or as part of a scripted domain rollout. This option provides a more explicit local control surface than the background scheduled task.

Option 3 — Group Policy​

• Use Group Policy: Computer Configuration > Administrative Templates > Windows Components > Secure Boot. Enable Enable Secure Boot certificate deployment (this sets the AvailableUpdates behavior). Deploy to an OU containing pilot devices, monitor for 1808 events, and then expand. Make sure you have the latest ADMX templates for Windows 11/Server.

Option 4 — MDM / Intune (coming soon)​

• Microsoft is releasing a CSP to integrate Secure Boot certificate deployment with MDM solutions such as Intune. Where available, prefer MDM for large cloud‑managed fleets because it supports larger scale targeting and reporting. Until the CSP is available, use registry scripts or WinCS via Configuration Manager.

Pilot cadence and restart strategy​

• Pilot groups: 5–10 representative devices per OEM model/family for initial validation.
• Allow approximately 48 hours and one or more restarts after configuration changes for updates to settle; do not mass‑schedule reboots immediately after setting AvailableUpdates.
• Confirm Event ID 1808 and UEFICA2023Status=Updated before broadening rollout.

---

Troubleshoot and remediate common issues​

Common failure indicators

• UEFICA2023Error exists and is non‑zero — inspect Secure Boot DB/DBX events and event ID 1801 for bucketed device info to triage by OEM/firmware.
• AvailableUpdates bit 0x0004 (KEK) does not clear after multiple restarts — likely an OEM KEK signing or firmware acceptance issue; escalate to the OEM and confirm the platform has an OEM‑signed KEK object as documented by Microsoft.
• Event ID 1795/1797/1798 entries in the System log — these are DB/DBX update failures and will include a reason string you can use for vendor escalation.

Remediation patterns

• Firmware update from OEM that includes revised KEK/DB behavior — often the definitive fix.
• For air‑gapped devices: follow OEM/Windows offline guidance to import KEK blobs or apply vendor tools when available.
• If BitLocker recovery is triggered: follow your documented recovery playbook; do not attempt repeated firmware writes without recovery keys available.

When to involve OEM support

• Any KEK application failure (0x0004 persistence) or TPM‑reported HResult error during variable writes.
• When Event IDs show the firmware returned a vendor‑specific error code or when the device fails to boot after an attempted DB/DBX update.

---

Recovery planning and BitLocker considerations​

BitLocker will often see firmware/boot manager changes as an integrity event and can require recovery keys. Before any deployment wave:

• Ensure BitLocker recovery keys are backed up to Azure AD/AD DS or a secure vault and that helpdesk processes to restore keys are tested.
• Communicate to field engineers and end users the potential for a recovery prompt and provide a rapid path to retrieve keys.
• For devices in remote/field locations with no local admin, plan a staged rollout or hold those devices until you can guarantee key recovery support.

---

Critical analysis: strengths, weaknesses, and residual risks​

What Microsoft and the ecosystem got right

• Proactivity and documentation: Microsoft published a clear multi‑step, order‑sensitive rollout plan and supplied operational registry keys, event guidance, and a CLI path (WinCS) for IT. This gives admins explicit control and observability across fleets.
• Staged safety checks: the scheduled task and bitmask design enforce a sequence (add DB entries → apply KEK → deploy boot manager → optional DBX revocation) that minimizes the chance of ending in a non‑bootable state when firmware behaves correctly.
• Integration with BlackLotus mitigations: rotating to 2023 certificates is a necessary enabler to apply revocations and other pre‑boot mitigations that reduce the real risk from bootkits.

Residual risks and operational tradeoffs

• OEM firmware variability is the largest single risk. Some vendors may not produce a firmware update for older models; others may have firmware bugs that prevent OS‑initiated enrollment. Those device‑level outcomes are vendor controlled and must be verified per model. Treat vendor coverage claims as unverifiable without direct OEM confirmation.
• DBX (revocation) steps and Secure Version Number (SVN) enforcement can be effectively permanent on many devices. Applying them without comprehensive testing can produce non‑reversible states on devices that later need to accept older‑signed artifacts. Plan these steps conservatively.
• BitLocker and recovery risk: large fleets can be impacted by key‑recovery operations if media or helpdesk processes are not ready. This is operational, non‑technical risk that can cause major service disruption.
• Linux and third‑party impacts: distros that rely on Microsoft‑signed shim need the 2023 CA in firmware to accept newly signed shims/kernels. Dual‑boot and non‑Windows paths are a secondary but real compatibility vector.

Unverifiable claims and caveats

• Exact per‑device model support lists and OEM timelines are not centrally published by Microsoft. Any claim that a particular OEM will or will not support a model must be validated directly with that OEM. Treat those claims as vendor supplied and verify them with the manufacturer.

---

Practical checklist & timeline (recommended)​

• Inventory complete fleet and tag by OEM model, firmware date, and management channel. (Now)
• Back up BitLocker keys and golden images; prepare updated recovery media. (Now)
• Pilot a small set of representative devices per OEM model and run the full flow (registry/WinCS/GPO) and recovery tests. (Weeks 1–2)
• Coordinate firmware updates with OEMs and apply test firmware where required. (Weeks 2–6, vendor dependent)
• Expand rollout in waves: test → 10% → 50% → full, with monitoring and rollback plans between waves. Allow 48 hours between waves and monitor Event IDs and registry status. (Weeks 3–12)
• Revisit DBX revocations and SVN enforcement only after broad confidence and after OEM confirmation that all deployed devices support the change. (Post‑rollout)

Concrete start points you can run today

• Enable Windows Update and verify devices are receiving monthly cumulative updates on supported builds.
• Run a small inventory script to capture UEFICA2023Status, UEFICA2023Error, and AvailableUpdates values across a pilot group.
• If you want Microsoft to manage updates for high‑confidence devices, leave the default setting; to opt‑out, set HighConfidenceOptOut = 1. To opt in to Microsoft‑managed controlled feature rollout, set MicrosoftUpdateManagedOptIn = 1 and ensure devices share the required diagnostic data.

---

Final recommendations​

• Treat the 2011→2023 certificate rotation like a mini platform migration: plan, test, stage, and coordinate with OEMs and application owners.
• Prioritize inventory, BitLocker key hygiene, and pilot testing: these deliver the highest return on risk reduction in the shortest time.
• Use Microsoft’s registry keys, WinCS, and Group Policy tools to automate and monitor deployments — but accept that OEM firmware readiness will be the gating variable for some devices.
• Flag any device or model with persistent UEFICA2023Error or AvailableUpdates bits that do not clear to OEM support immediately; collect event IDs and the full firmware version string for faster triage.

Applying the new Secure Boot certificates is necessary, achievable, and safe if you follow staged testing and recovery discipline — but neglecting inventory, recovery, and OEM coordination risks user downtime and costly recovery operations. Use the event logs (1801/1808), the UEFICA2023Status/UEFICA2023Error registry keys, and the WinCS/Group Policy controls as your instrumentation and control plane. Start with pilots now, and aim to complete your coordinated rollout well before June 2026.

---

Appendix: quick reference commands and registry knobs

• Registry path: HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing. To trigger full deployment on a test device set AvailableUpdates = 0x5944. Monitor UEFICA2023Status (should progress to Updated) and UEFICA2023Error (should be 0 / not present).
• Event log checks (PowerShell, elevated):
• Pull the most recent events for 1801 and 1808:
• Get-WinEvent -FilterHashtable @{LogName='System'; ID=@(1801,1808)} -MaxEvents 20
• Check for Event ID 1808 to confirm success and Event ID 1801 for devices that need attention.
• WinCS feature (domain‑joined clients): look for Feature_AllKeysAndBootMgrByWinCS and use the WinCS CLI/PowerShell module to query/apply Secure Boot configurations when available.
• Opt‑in/out:
• To opt out of Microsoft’s high‑confidence auto‑deploy: set HighConfidenceOptOut = 1.
• To opt into Microsoft‑managed controlled feature rollout: set MicrosoftUpdateManagedOptIn = 1 (requires optional diagnostic data).

This playbook is practical and field‑tested in published guidance, but your last mile is the firmware on each model. Start inventory and pilot work immediately and coordinate OEM firmware timelines to ensure a smooth transition before June 2026.

---

Source: Microsoft - Message Center Secure Boot playbook for certificates expiring in 2026 - Windows IT Pro Blog