Secure Boot 2026: planning the CA 2011 to CA 2023 transition

Questo articolo è disponibile anche in lingua italiana, al seguente link – Secure Boot 2026: la transizione dai certificati CA 2011 ai CA 2023 – WindowServer.it

Microsoft Secure Boot is approaching one of the most significant lifecycle events of the last decade. The Microsoft-issued certificates that have anchored the UEFI trust chain since Windows 8 and Windows Server 2012 begin expiring in June 2026, with the rollover continuing through October 2026. Devices that do not transition to the 2023 certificate family before expiration remain bootable, but they lose the ability to receive any future security update for the early boot environment — a serviceability and security risk that grows over time.

This article frames the transition as a platform security lifecycle event, comparable in operational impact to a cryptographic algorithm deprecation. The recommended approach is a controlled, ring-based rollout — inventory, pilot, broad deployment — with firmware readiness validated per hardware model, with particular attention to Windows Server, where the update is not delivered automatically.

Why Secure Boot certificates matter

Secure Boot is the UEFI feature that ensures only trusted software runs during the boot sequence. It validates digital signatures of pre-boot components — firmware modules, boot loaders, EFI applications — against certificates stored in firmware variables. The trust chain is governed by four stores: the Platform Key (PK), the Key Exchange Key (KEK), the Allowed Signature Database (DB), and the Revoked Signature Database (DBX).

The KEK authorizes updates to DB and DBX. DB defines what is trusted to run. DBX records what has been revoked — typically components proven vulnerable, such as the boot loaders implicated in the BlackLotus UEFI bootkit (CVE-2023-24932). Keeping these stores current is essential to maintain the chain of trust and to receive future revocation entries as new boot-level vulnerabilities are disclosed.

What is expiring and when

Three Microsoft-provided 2011 certificates begin expiring between June 2026 and October 2026, replaced by a 2023 certificate family. The mapping is straightforward, with one important asymmetry — the 2011 third-party UEFI CA is being split into two distinct 2023 successors, separating boot loader signing from option ROM signing for finer trust control.

Microsoft Corporation KEK CA 2011 (KEK store) → Microsoft Corporation KEK 2K CA 2023
Microsoft Windows Production PCA 2011 (DB store) → Windows UEFI CA 2023, used to sign the Windows boot manager
Microsoft Corporation UEFI CA 2011 (DB store) → Microsoft UEFI CA 2023 (boot loaders) and Microsoft Option ROM UEFI CA 2023 (option ROMs), applied only on devices that originally carried the 2011 third-party UEFI CA

Devices manufactured since 2024 typically ship with the 2023 certificates already provisioned in firmware. The remediation effort therefore concentrates on the long tail of systems built between 2012 and 2023 — both physical hardware and virtual machines.

The risk profile after expiration

When the 2011 certificates expire, devices that did not complete the rollover continue to start and operate normally. Standard Windows updates keep installing. What stops working is the ability to service the early boot environment: no new DBX revocations, no Secure Boot database updates, no Windows Boot Manager security fixes, no mitigations for newly disclosed boot-level vulnerabilities. Over time, this leaves the platform exposed to bootkit and rootkit techniques that operate before OS-level protections engage.

Operationally, the rollover is not a pure OS change. Firmware behavior is the gating factor, and OEM implementations differ substantially. Common pitfalls include:

Firmware that does not accept Secure Boot variable updates without an OEM BIOS update
“Restore defaults” actions in firmware that overwrite the active variables previously updated by Windows, blocking the next boot
BitLocker recovery prompts triggered by changes to TPM measurements during the transition
Generation 1 Hyper-V virtual machines, which do not use UEFI and cannot participate in Secure Boot at all
Generation 2 Hyper-V VMs created before 2023, which may stall in InProgress state because their virtual firmware was provisioned with an older trust anchor
Dual-boot or third-party boot loader scenarios where non-Windows components must remain trusted under the new databases

How Microsoft delivers the update

The deployment mechanism differs significantly between Windows client and Windows Server, and this distinction is central to planning the rollout.

On Windows 11 and supported Windows 10 builds, the new certificates are pushed through Controlled Feature Rollout (CFR) as part of the monthly cumulative updates. Microsoft targets devices identified as “high-confidence” first — based on hardware identity, firmware version, and prior success signals — and expands progressively. A device-side scheduled task named Secure-Boot-Update, located under \Microsoft\Windows\PI\ in Task Scheduler, runs every 12 hours and applies the certificate stages in order: Windows UEFI CA 2023 to DB, then Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 to DB if the device carried the 2011 third-party CA, then Microsoft Corporation KEK 2K CA 2023 to KEK, and finally the 2023-signed Windows boot manager — which requires a restart to take effect.

On Windows Server, the same mechanism is available, but the rollout is not automatic. IT administrators must validate readiness per platform and trigger the deployment manually using one of the supported methods. Windows Server 2025 systems that shipped with the 2023 certificates already in firmware are the exception — the rest require explicit action, including all Generation 2 Hyper-V VMs and physical servers with Secure Boot enabled.

Deployment methods for IT-managed environments

Microsoft documents three IT-controlled methods that drive the same scheduled task. Pick the one that fits the management model already in place; do not mix multiple methods on the same device fleet without a clear reason.

Registry — set HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates to 0x5944 to deploy all required certificates and update the boot manager to the Windows UEFI CA 2023-signed version. This is the recommended value for a complete transition. The earlier 0x40 documented in KB5036210 deploys only the Windows UEFI CA 2023 to DB and is suitable for a phased approach
Group Policy — navigate to Computer Configuration > Administrative Templates > Windows Components > Secure Boot and enable the Enable Secure Boot certificate deployment setting. This is the equivalent of the registry path, applied through GPO
Windows Configuration System (WinCS) — a PowerShell module and command-line executable available on domain-joined Windows 11 25H2, 24H2, and 23H2 clients, designed to query and apply Secure Boot configurations locally. This is the path Microsoft recommends for larger-scale rollouts in modern fleets

Microsoft Intune supports Secure Boot configuration through MDM policies, with a known limitation on Windows 10 and Windows 11 Pro editions that was resolved by the Intune licensing service update on 27 January 2026. Devices receive the corrected behavior via automatic monthly license renewal.

Monitoring and validation

Two signals carry the deployment state: the Windows System event log and the servicing registry key. Both should be baselined before any deployment ring starts.

In the System log, the relevant Event IDs are emitted by the TPM-WMI source. The most important to track:

1800 — a restart is required before the boot manager update can complete
1801 — staging issue; some certificates or the 2023-signed boot manager are not yet applied. Often transient and clears after the next scheduled task run plus reboot
1795 and 1796 — firmware-level errors, typically “the system firmware returned an error: the media is write protected”. Indicate that the OEM firmware does not accept the variable update
1803 — missing OEM PK-signed KEK. Hard stop, escalate to the OEM or hypervisor vendor
1808 — successful completion of the Secure Boot CA update

The servicing state is exposed under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing. The values UEFICA2023Status, UEFICA2023Error, and UEFICA2023ErrorEvent describe progress and any failure code. An UEFICA2023Error value of 0x0 indicates a clean update.

For client environments running Windows 11, the Windows Security app surfaces this state visually starting in April 2026. Under Device security > Secure Boot, a green, yellow, or red badge reflects the current condition, with progressively more guidance and system notifications rolling out from May 2026 onward. This is intended for end users on personal devices, but it is also a useful sanity check on managed endpoints.

From PowerShell, the practical verification one-liners are:

Confirm-SecureBootUEFI

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

[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes)  -match 'Windows UEFI CA 2023'
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes)  -match 'Microsoft UEFI CA 2023'
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes)  -match 'Microsoft Option ROM UEFI CA 2023'

Get-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update' |
    Select-Object TaskName, State, Enabled

Hyper-V, VMware, and cloud workloads

Virtualized environments deserve specific attention because the trust chain crosses the host and guest boundary, and because long-running VMs carry firmware state from the era in which they were created.

On Hyper-V, only Generation 2 VMs use UEFI and therefore Secure Boot — Generation 1 VMs are out of scope and do not participate in the update. Generation 2 VMs receive certificate updates through the guest Windows installation, exactly like a physical server. A known issue affecting KEK updates on Hyper-V VMs surfaced as Event ID 1795 with the media is write protected message; the fix must be deployed on both host and guest, and is included in Windows updates released on or after 10 March 2026, with the exception of Windows Server 2025 hosts, which require the 14 April 2026 cumulative or later. VMs hosted on Azure receive the resolution through the 2603 security update on the guest.

VMs created before the 2023 firmware era are a separate problem class. Microsoft’s guidance is that an existing Generation 2 VM with an older trust anchor cannot acquire the new Secure Boot CAs in place, regardless of cumulative updates. The recommended path is to create a new Generation 2 VM with current settings, migrate the workload, and decommission the legacy one. This is consistent with the broader principle that virtual firmware state, not Windows servicing state, is the binding constraint for older VMs.

On VMware, the certificate update is delivered as a hypervisor-side virtual firmware update rather than through the guest. Persistent KEK or PK errors on VMware VMs almost always trace back to NVRAM state on virtual machines created years ago, where Platform Key ownership or variable persistence is broken. The pragmatic fix in those cases is to rebuild the VM on a current ESXi version with Secure Boot enabled at creation, rather than attempt manual PK enrollment — which changes platform ownership and frequently triggers BitLocker recovery as a side effect.

Operational safeguards

The certificate rollover touches firmware variables, the Windows boot manager, and TPM-bound protections. Treat it as a production-impacting change with the appropriate guardrails.

Suspend BitLocker before forcing firmware-affecting steps on critical systems, using Suspend-BitLocker -MountPoint C: -RebootCount 3, and confirm recovery key availability beforehand
Apply OEM firmware updates first; they are the foundation that allows the new certificates to be accepted at all
Avoid “restore defaults” or “reset Secure Boot keys” actions in firmware after the rollover has completed — they remove the 2023 trust anchors and block the next boot. Use OEM-supplied recovery utilities if this happens
Verify recovery media (WinPE, OEM recovery partitions) is signed under the 2023 chain or is being refreshed by the vendor; older recovery images may eventually fail to boot on systems migrated to the 2023 trust
Roll out in rings: pilot on a representative set covering each hardware model, firmware revision, hypervisor, and edition, then expand

Conclusions

The 2026 Secure Boot certificate transition is a predictable, well-documented lifecycle event, and the tooling Microsoft has shipped between January and April 2026 is sufficient to drive it to completion across most fleets. The risk is not technical complexity — it is inertia. Devices left on the 2011 trust anchors will continue to boot, which makes the problem easy to defer and easy to under-prioritize until DBX revocations or new boot-level vulnerabilities make the cost visible.

The discipline that matters here is the same that applies to any cryptographic deprecation: inventory before the deadline, validate per platform class, deploy in rings, and monitor with the indicators the platform actually exposes. Treat Windows Server as a separate workstream from Windows client, because the delivery model is different. And treat older virtual machines as candidates for rebuild rather than remediation, because the cost-benefit of forcing variable updates on aging virtual firmware rarely favors the patch path.

#DBS