Microsoft’s Secure Boot certificate rollover is a platform-level change that will touch firmware, OS servicing, BitLocker, and recovery processes — and IT teams must treat it as a multi-quarter program, not a routine patch. The company’s managed update flow uses a scheduled Windows task that inspects the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates registry DWORD and processes a set of discrete bits in a defined order to add new certificates, update the KEK, and replace the Windows boot manager; when anything in that chain fails (firmware rejects a variable write, OEM-signed KEK is missing, or BitLocker recovery keys aren’t available) devices can be left in a mixed or recovery-only state.
Secure Boot enforces pre-OS trust by maintaining a small number of signed firmware variables: the Platform Key (PK), Key Exchange Key (KEK), the Allowed Signature Database (DB), and the Forbidden/Revoked Signature Database (DBX). When Microsoft rotates the signing certificates it uses for boot components, those new certificates must be present in firmware (or written into the active UEFI variables) before boot components signed with the new keys are deployed. If the firmware still trusts only the legacy 2011 keys when those keys expire, the system may stop accepting new pre-boot updates or, worse, refuse to boot new boot managers.
Microsoft created a family of replacement certificates in 2023 (Windows UEFI CA 2023, Microsoft UEFI CA 2023, Microsoft Option ROM UEFI CA 2023, and Microsoft Corporation KEK CA 2023) and provided an OS-side flow, packaged into SSU + LCU/CU servicing updates, that attempts to update firmware variables where permitted. The intent is to (1) add the 2023 certificates into the DB/KEK, (2) deploy a boot manager signed by the 2023 Windows UEFI CA, and (3) optionally add the old 2011 certificates to DBX and raise the Secure Version Number (SVN) to prevent rollbacks — a deliberate multi-step, order-sensitive process.
Key calendar constraints make this urgent for IT teams: several 2011 CA entries begin expiring in June 2026 and the Windows Production PCA 2011 bootloader certificate is scheduled to expire in October 2026. Organizations should plan and test well before these dates.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecureBoot\AvailableUpdates
That DWORD contains flags (bits) that instruct the scheduled task what firmware/boot updates to attempt. Each bit corresponds to a specific operation; bits are processed in a strict order so that trust anchors exist before trust-dependent artifacts are changed. When an operation completes successfully its corresponding bit is cleared; the 0x4000 modifier bit behaves differently (see next section).
For immediate action: inventory Secure Boot state and firmware versions, secure BitLocker recovery keys, and engage OEMs for firmware timelines — these are the highest-return early steps to avoid surprises when the 2011 CA expirations approach.
Source: Microsoft Support Secure Boot Certificate updates: Guidance for IT professionals and organizations - Microsoft Support
Background / Overview
Secure Boot enforces pre-OS trust by maintaining a small number of signed firmware variables: the Platform Key (PK), Key Exchange Key (KEK), the Allowed Signature Database (DB), and the Forbidden/Revoked Signature Database (DBX). When Microsoft rotates the signing certificates it uses for boot components, those new certificates must be present in firmware (or written into the active UEFI variables) before boot components signed with the new keys are deployed. If the firmware still trusts only the legacy 2011 keys when those keys expire, the system may stop accepting new pre-boot updates or, worse, refuse to boot new boot managers.Microsoft created a family of replacement certificates in 2023 (Windows UEFI CA 2023, Microsoft UEFI CA 2023, Microsoft Option ROM UEFI CA 2023, and Microsoft Corporation KEK CA 2023) and provided an OS-side flow, packaged into SSU + LCU/CU servicing updates, that attempts to update firmware variables where permitted. The intent is to (1) add the 2023 certificates into the DB/KEK, (2) deploy a boot manager signed by the 2023 Windows UEFI CA, and (3) optionally add the old 2011 certificates to DBX and raise the Secure Version Number (SVN) to prevent rollbacks — a deliberate multi-step, order-sensitive process.
Key calendar constraints make this urgent for IT teams: several 2011 CA entries begin expiring in June 2026 and the Windows Production PCA 2011 bootloader certificate is scheduled to expire in October 2026. Organizations should plan and test well before these dates.
How the Secure Boot certificate update flow works (technical summary)
The scheduled task and AvailableUpdates registry key
Windows includes a scheduled task that runs every 12 hours to examine the AvailableUpdates DWORD at:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecureBoot\AvailableUpdates
That DWORD contains flags (bits) that instruct the scheduled task what firmware/boot updates to attempt. Each bit corresponds to a specific operation; bits are processed in a strict order so that trust anchors exist before trust-dependent artifacts are changed. When an operation completes successfully its corresponding bit is cleared; the 0x4000 modifier bit behaves differently (see next section).
The bits, meanings, and processing order
The scheduled task processes these bits in the following order. The Order below is the enforced processing sequence:- Order 1 — 0x0040: Add Windows UEFI CA 2023 to the Secure Boot DB. This allows firmware to trust boot managers signed by the new Windows PCA.
- Order 2 — 0x0800: Apply Microsoft UEFI CA 2023 to the DB. If the modifier bit 0x4000 is set, the task only applies this if Microsoft Corporation UEFI CA 2011 is present in the DB.
- Order 3 — 0x1000: Apply Microsoft Option ROM CA 2023 to the DB. If 0x4000 is set, this step also checks for the presence of the 2011 CA before applying.
- Modifier — 0x4000: When set, only apply the Microsoft UEFI CA 2023 (0x0800) and Microsoft Option ROM CA 2023 (0x1000) if the device previously trusted Microsoft Corporation UEFI CA 2011. This ensures the security profile is preserved and prevents adding new Microsoft certificates where the device did not trust the older Microsoft 2011 CA — an important compatibility guard. Note that 0x4000 will remain set after processing; other bits are cleared as they succeed.
- Order 4 — 0x0004: Look for a Key Exchange Key (KEK) object signed by the device’s Platform Key (PK) and apply it to the firmware KEK. OEMs control the PK and are responsible for provisioning a KEK signed by their PK; Microsoft packages OEM-signed KEKs into cumulative updates after OEM submission.
- Order 5 — 0x0100: Deploy the boot manager signed by Windows UEFI CA 2023 to the boot partition, replacing the Microsoft Windows Production PCA 2011–signed boot manager.
- Start: 0x5944
- 0x0040 applied → 0x5904
- 0x0800 applied → 0x5104
- 0x1000 applied → 0x4104
- 0x0004 applied → 0x4100
- 0x0100 applied → 0x4000
Troubleshooting: common failure modes and remediation
Symptom A — KEK update stalls (AvailableUpdates remains at 0x4104; 0x0004 not cleared)
- What happens: The device successfully accepts new DB entries but does not progress past the KEK application step. The scheduled task keeps retrying and logs an Event ID: 1796. The AvailableUpdates DWORD includes the 0x0004 bit and it does not clear after multiple attempts.
- Most likely cause: There is no KEK signed by the OEM’s PK available to apply for that device. OEMs manage the Platform Key (PK) and must sign the Microsoft KEK with the device’s PK and return the signed KEK to Microsoft for inclusion in cumulative updates. If the OEM has not created or provisioned that signed KEK for the affected models, the OS-side flow cannot perform the KEK update.
- Remediation steps:
- Confirm the logged event: check System and Windows logs for Event ID 1796 and any Secure Boot DB/DBX variable update event details.
- Export the current firmware KEK/db contents (PowerShell Get-SecureBootUEFI) and validate whether the legacy Microsoft Corporation KEK CA 2011 is present — if it isn’t, the 0x4000 modifier may be gating behavior.
- Contact the OEM’s support channel and confirm whether the model has a KEK signed by the OEM PK in Microsoft’s cumulative updates or whether an OEM firmware update is required. Provide the OEM with the machine model, firmware version, and the Event log details.
- Where OEMs provide a signed KEK, apply the OEM firmware or the cumulative update containing the KEK and allow the scheduled task to retry (or trigger the Secure-Boot-Update scheduled task). If a signed KEK is not forthcoming, treat affected models as requiring OEM remediation or device replacement.
Symptom B — Firmware rejects variable write (Event ID: 1795)
- What happens: The OS hands certificates and KEK objects to firmware but the firmware returns an error. Windows logs Event ID: 1795, indicating a firmware-level refusal or failure during the variable update.
- Most likely cause: Firmware implementation refuses OS-initiated writes for that variable, has a bug, or requires an OEM firmware update to permit the change (or to embed the new certificates into firmware defaults). Some firmware will accept active variables written by the OS but will lose those writings after a firmware reset or Secure Boot default reset unless the OEM also updates the firmware defaults.
- Remediation steps:
- Review the event record details and note the failing variable (db, KEK, or dbx) and the firmware error code.
- Check for OEM firmware updates for that model that explicitly mention Secure Boot or the 2023 certificates and apply after confirming vendor guidance and testing on a non-production machine.
- If no firmware update exists, consult OEM documentation for manual re-enrollment procedures or escalate with OEM support. For managed fleets, consider blocking the automated Microsoft-managed flow for that model until firmware is ready and plan a coordinated remediation schedule.
Verifications and commands administrators should run
- Confirm Secure Boot is enabled: run msinfo32 and look for Secure Boot State or use PowerShell Confirm-SecureBootUEFI (elevated).
- Inspect DB and DBX contents: PowerShell Get-SecureBootUEFI db / dbx and search for the 2023 CA names to confirm presence. Use ASCII.GetString((Get‑SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023' to detect the new CA.
- Check AvailableUpdates registry value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates — verify which bits remain set and correlate to the intended processing stage.
Deployment playbook for IT professionals (practical checklist)
Treat this as an operational program with pilot rings, OEM coordination, and recovery validation.- Inventory and classify (2–4 weeks)
- Collect OEM, model, firmware/BIOS version, Windows build, Secure Boot state, and method of management (Windows Update vs WSUS/Intune).
- Prioritize critical systems, servers, and air-gapped devices.
- Back up recovery materials (immediately)
- Export and securely store all BitLocker recovery keys (AD, Azure AD, M365 accounts, or an offline vault).
- Rebuild and test recovery USB/ISO images against pilot devices.
- Confirm servicing baseline
- Ensure devices have the required Servicing Stack Update (SSU) + Latest Cumulative Update (LCU) packages that contain the Secure Boot update payload.
- For air-gapped systems, prep offline MSU packages and test DISM injection into images.
- OEM firmware coordination
- For each OEM/model, confirm whether a firmware update embeds the 2023 certificates into firmware defaults or permits OS-written active variables.
- Collect firmware update timelines and schedule devices accordingly.
- Pilot ring (weeks 4–12)
- Build representative test groups across OEMs and firmware revisions.
- Validate the full sequence: DB updates, KEK application, boot manager replacement, BitLocker behavior, WinRE/Reset flows, and DBX/SVN consequences if you plan to enable revocation/SVN steps later.
- Decide Microsoft-managed vs IT-managed rollout
- If you permit Microsoft-managed updates, use the MicrosoftUpdateManagedOptIn DWORD (HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\MicrosoftUpdateManagedOptIn) with value 0x5944 to opt devices into the managed flow — only after suitable policy review on telemetry implications.
- For restricted environments, prepare self-service MSU/DISM or scripted updates and plan for offline KEK/DB updates where supported.
- Staged rollout and monitoring (weeks 8–16)
- Roll out in waves, monitor Secure Boot event logs, and keep a fast rollback or isolation plan for firmware families that show problems.
- Monitor telemetry and OEM advisories; pause rollout for any model showing elevated recovery/boot errors.
- DBX and SVN decisions
- DBX (revoking the old 2011 CA) and SVN enforcement are powerful but often irreversible in practice. Only apply DBX/SVN steps after broad testing, vendor validation, and stakeholder buy-in. Prepare updated bootable media and recovery images that include new signing chains before enabling DBX/SVN enforcement.
Risks, strengths, and trade-offs — critical analysis
Strengths (what this change accomplishes)
- Improved pre-boot security: The 2023 certificates plus SVN protections materially reduce the risk of rollback attacks and enable Microsoft to sign future pre-boot mitigations. This is a long-term security improvement for the Windows boot chain.
- Staged, documented process: Microsoft packages the flow as SSU+LCU and exposes registry and detection controls for IT, enabling predictable staging and scripted checks.
- Flexible delivery channels: Support for Microsoft-managed rollouts, WSUS/ConfigMgr/Intune, and offline MSU/DISM flows lets organizations choose the path best aligned to policy.
Operational risks and gaps (where organizations must be careful)
- OEM firmware dependency: The largest single operational risk is firmware readiness. Many failure modes (Event ID 1795, 1796, inability to write KEK/db variables) are firmware-dependent and require OEM-supplied fixes. Without OEM cooperation some devices may never accept OS-side certificate updates.
- BitLocker and recovery impact: Changes to boot components or firmware variables can trigger BitLocker recovery on large numbers of devices. If recovery keys aren’t available, systems could become effectively unusable until keys are recovered. IT must back up keys proactively.
- Irreversible outcomes: Adding entries to DBX (revoking old CAs) and SVN enforcement are effectively permanent on many devices — rolling back is difficult or impossible without vendor-specific firmware tools or re-imaging. Test before committing.
- Linux and dual-boot edge cases: Many Linux distributions rely on a shim signed by Microsoft. If firmware lacks the new 2023 CA, Linux boot paths may break until shims/distros are re-signed or firmware updated. This requires coordination with distro maintainers and/or OEMs.
Concrete commands and checks (quick reference)
- Check Secure Boot state (GUI): run msinfo32 → System Summary → Secure Boot State.
- Check Secure Boot state (PowerShell, elevated):
Confirm-SecureBootUEFI
(returns True/False). - Inspect DB contents (PowerShell, elevated):
ASCII.GetString((Get‑SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
(True indicates the DB contains the 2023 Windows CA). - View AvailableUpdates registry:
HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates — interpret bits per the earlier table. - Opt-in to Microsoft-managed updates (set via MDM/GPO or script):
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot" /v MicrosoftUpdateManagedOptIn /t REG_DWORD /d 0x5944 /f
(Treat as a policy decision — this has telemetry implications). - Offline image injection (example):
DISM /Online /Add-Package /PackagePath:C:\packages\<SSU+LCU>.msu
(use only after testing in your image pipeline).
Recovery scenarios and recommendations
- Always keep a validated recovery path: updated recovery USBs, golden images containing new boot manager and CA chain, and a secure vault for BitLocker recovery keys.
- If a machine enters BitLocker recovery after an attempted Secure Boot update, don’t attempt repeated firmware changes without first recovering the key — repeated firmware writes or resets can complicate recovery.
- For air‑gapped or heavily restricted systems, capture a documented manual process (signed KEK objects, necessary key blobs) and coordinate with OEMs to perform offline enrollment or firmware updates.
- If an OEM never produces firmware to accept the 2023 certificates for a model you must keep in production, consider hardware refresh or isolate the device until a secure mitigation is achievable.
Conclusion
This certificate update program is necessary to preserve the integrity and updateability of Secure Boot into the next certificate lifetime window. Microsoft’s OS-side flow and the scheduled task that processes the AvailableUpdates registry bits are powerful automation tools for many devices, but OEM firmware readiness and BitLocker/recovery planning are the critical gating factors. IT organizations should treat the transition as a program: inventory hardware, back up keys, pilot with representative devices, coordinate with OEMs for firmware readiness, and only after careful validation move to revoke legacy CAs or enable SVN enforcement. The technical controls (AvailableUpdates bits, the scheduled Secure-Boot-Update task, Get‑SecureBootUEFI and Confirm‑SecureBootUEFI commands, and the MicrosoftUpdateManagedOptIn registry knob) give administrators operational control — but those controls must be used with discipline and thorough testing to avoid mass recovery events or unbootable fleets.For immediate action: inventory Secure Boot state and firmware versions, secure BitLocker recovery keys, and engage OEMs for firmware timelines — these are the highest-return early steps to avoid surprises when the 2011 CA expirations approach.
Source: Microsoft Support Secure Boot Certificate updates: Guidance for IT professionals and organizations - Microsoft Support
