How-to Windows Security Updates & Patching

Secure Boot Certificate Expiry 2026: Check and Update to 2023 CAs

Microsoft Secure Boot 2011 certificates expire in 2026. Check UEFICA2023Status and events 1801/1808, trigger the 2023 CA update with AvailableUpdates 0x5944, and fix common errors.

Published 6 Oct 2026 9 min read By srvScripts team

Short answer: Microsoft’s 2011 Secure Boot certificates expire during 2026: KEK CA 2011 on June 24, UEFI CA 2011 on June 27, and Windows Production PCA 2011 on October 19, 2026. Devices without the 2023 replacements keep booting, but can no longer receive new boot-level security fixes. Check a machine with Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing (UEFICA2023Status should be Updated) and System event 1808; to trigger the update on an IT-managed device, set AvailableUpdates to 0x5944 under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot and let the Secure-Boot-Update task and a restart finish the job.

Applies to Windows with Secure Boot, Server 2012 and later; tested on Windows Server 2025 and Windows 11 Pro

We ran these commands on 6 October 2026 on a Windows Server 2025 Standard domain controller (build 26100.33438, September 2026 update, Windows PowerShell 5.1) and a Windows 11 Pro member PC in our lab domain contoso.com. Where the lab result differed from the documentation, the page says so.

Which certificates expire, and what happens

Every Secure Boot capable Windows device since 2012 ships with the same Microsoft certificates in its UEFI firmware. Microsoft’s KB5062710 lists the expiry dates and replacements:

Expiring certificate	Expires	Replacement (2023)	Stored in	Used for
Microsoft Corporation KEK CA 2011	June 24, 2026	Microsoft Corporation KEK 2K CA 2023	KEK	Signing updates to DB and DBX
Microsoft Windows Production PCA 2011	October 19, 2026	Windows UEFI CA 2023	DB	Signing the Windows boot loader
Microsoft UEFI CA 2011	June 27, 2026	Microsoft UEFI CA 2023	DB	Third-party boot loaders and EFI apps (Linux shim, some tools)
Microsoft UEFI CA 2011	June 27, 2026	Microsoft Option ROM UEFI CA 2023	DB	Third-party option ROMs (RAID, NIC, GPU firmware)

Microsoft is explicit about the impact: a device that has not received the 2023 certificates continues to start and run normally, and normal Windows updates still install. What it loses is the ability to receive new protections for the early boot process: Windows Boot Manager updates, DB/DBX revocation updates and mitigations for new boot-level vulnerabilities. Over time that weakens BitLocker hardening and anything else that relies on Secure Boot trust.

In other words, this is not a “servers stop booting” event, but it is a security debt that grows with every boot-level vulnerability published after the expiry dates. With the Windows Production PCA 2011 date only days away (as of this writing), devices that are not yet Updated need attention now.

Check one machine

All checks run in an elevated PowerShell session. First, confirm Secure Boot is on at all. If this returns False or throws an error (legacy BIOS boot), none of the rest applies:

Confirm-SecureBootUEFI

Our lab server is a KVM virtual machine with Secure Boot off. Confirm-SecureBootUEFI returned False, Get-SecureBootUEFI db failed with “Variable is currently undefined: 0xC0000100”, and the System log showed event 1796 for every certificate: “The Secure Boot update failed to update KEK 2023 with error Secure Boot is not enabled on this machine”, followed by 1801. That is expected on a machine without Secure Boot and is not a fault to fix, unless you plan to turn Secure Boot on.

Then read the servicing status that Windows maintains for this update (the registry values exist on systems with updates from November 11, 2025 or later):

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

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' |
    Select-Object AvailableUpdates, HighConfidenceOptOut, MicrosoftUpdateManagedOptIn

UEFICA2023Status	Meaning
`NotStarted`	The update has not run on this device
`InProgress`	Running, or stuck: check `UEFICA2023Error`
`Updated`	All new certificates and the 2023-signed boot manager are in place

You can also check the firmware databases directly. This is the check Microsoft uses in its boot manager guidance; True means the certificate is in DB:

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

Finally, look at the Secure Boot events from the TPM-WMI source in the System log. Event 1808 means the device is fully updated; 1801 means the new certificates and boot manager have not been applied yet:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 1032, 1795, 1796, 1801, 1808 } -MaxEvents 50 -ErrorAction SilentlyContinue |
    Where-Object ProviderName -like '*TPM-WMI*' |
    Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap

How the update reaches devices

Microsoft offers several routes. Pick one per device and avoid mixing them:

Automatic, high-confidence buckets. Microsoft groups devices by hardware and firmware attributes. When a bucket has enough successful updates, the monthly cumulative update applies the certificates automatically. This is on by default; HighConfidenceOptOut = 1 turns it off. The device’s bucket status is in ConfidenceLevel (for example High Confidence, Under Observation, No Data Observed – Action Required, Temporarily Paused, Not Supported – Known Limitation).
Controlled Feature Rollout. Opt in with MicrosoftUpdateManagedOptIn = 1; requires diagnostic data. Microsoft says organizations cannot rely on this alone.
Registry trigger. Set AvailableUpdates = 0x5944 yourself (next section). Works on all Windows versions that support Secure Boot, Server 2012 and later included.
WinCS. The Windows Configuration System command-line tools and PowerShell module for domain-joined clients and servers.
Group Policy and Intune. Microsoft documents these in its IT-managed devices guidance; the AvailableUpdatesPolicy value is how they signal the device, and you should not edit it by hand.

Servers in “No Data Observed” or “Under Observation” buckets, which covers a lot of older server hardware, will not be updated automatically. Those are the ones to handle yourself.

Trigger the update with the registry key

Test on a few devices of each hardware model first (Microsoft recommends four or more per model), and have the BitLocker recovery keys for those devices to hand before you start. Check for and install the vendor’s latest BIOS/UEFI firmware first: some firmware needs an update before it accepts the new KEK.

Microsoft’s test sequence for a single device, run as administrator:

# 1. Request all certificate and boot manager updates
reg add HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f

# 2. Run the task that processes the request now (normally every 12 hours)
Start-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update'

# 3. Watch AvailableUpdates: bits clear as each step succeeds
(Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot).AvailableUpdates.ToString('X')

When AvailableUpdates reaches 0x4100, restart the device and run the task again. The boot manager is then replaced with the one signed by Windows UEFI CA 2023 and the value becomes 0x4000. UEFICA2023Status should then read Updated and event 1808 appears.

For a fleet, push the same AvailableUpdates value with your management tool (GPO registry preference, Intune remediation, RMM) to a pilot group, then widen it. Setting the value never forces a restart by itself; the process waits for normal restarts, such as monthly patching.

Hyper-V and other virtual machines

Generation 2 Hyper-V VMs, VMware VMs with EFI firmware and cloud VMs have virtual Secure Boot databases that need the same update. Microsoft describes two paths: the hypervisor vendor ships new templates/firmware with the 2023 certificates (for new VMs), and long-running VMs are updated from inside Windows like physical machines, if the virtual firmware supports it.

Hyper-V KEK update fails with event 1795, “The system firmware returned an error: The media is write protected”. A known issue fixed in Windows updates from March 10, 2026 (April 14, 2026 for Windows Server 2025). The fix must be installed on both the Hyper-V host and the guest.
Azure Trusted Launch VMs, AVD and Windows 365 may log 1795 during the KEK step; Microsoft lists this as a known issue with no customer action required and a fix to come through updates.
VMware, Proxmox and others: follow the hypervisor vendor’s guidance for the virtual firmware variables, then update from inside the guest.

Common problems

Event 1032: “The Secure Boot update … was not applied due to a known incompatibility with the current BitLocker configuration.” Suspend BitLocker for two restarts as Microsoft documents (manage-bde -protectors -disable C: -RebootCount 2), restart twice, then confirm protection is back with manage-bde -status.
Event 1795: the system firmware returned an error while writing DB, DBX or KEK. Usually firmware. Update the BIOS/UEFI from the OEM; on Hyper-V see the known issue above.
Event 1796: “The Secure Boot update failed to update … with error …” A generic failure; Windows retries at the next restart.
Event 1800: “A reboot is required before installing the Secure Boot update”. Normal on devices with virtualization-based security: restart and run the task again.
Status stuck at InProgress with UEFICA2023Error non-zero. Read UEFICA2023ErrorEvent for the matching event ID and check Microsoft’s Secure Boot DB and DBX update events article.
Old recovery, WinPE or PXE media will not boot. This happens once the Windows Production PCA 2011 is added to DBX (event 1037, a separate revocation step): any boot application signed only with that certificate is no longer trusted. Rebuild boot media from current, 2023-signed Windows sources. Do not disable Secure Boot as a permanent fix; see Invalid signature detected: Secure Boot policy.

Check that it worked

UEFICA2023Status is Updated and UEFICA2023Error is 0 or absent.
The DB check for Windows UEFI CA 2023 and the KEK check for Microsoft Corporation KEK 2K CA 2023 both return True.
Event 1808 is present in the System log, and there are no new 1801, 1795 or 1796 events after it.
The device still boots normally with BitLocker protection on (manage-bde -status shows Protection On).

Official documentation: Windows Secure Boot certificate expiration and CA updates (KB5062710) · Registry key updates for Secure Boot (KB5068202) · Secure Boot DB and DBX variable update events · Known issues for Secure Boot certificate updates (KB5085790)

Frequently asked questions

Will my server stop booting when the 2011 certificates expire?

No. Microsoft says devices without the new certificates continue to start and run, and normal Windows updates continue to install. They can no longer receive new boot-level security updates.

Do Windows Server machines get the new certificates automatically?

Only if they fall into a high-confidence device bucket, which is applied through monthly cumulative updates. Many servers will not, so check UEFICA2023Status and trigger the update yourself where needed.

What does AvailableUpdates 0x5944 do?

It tells Windows to add the 2023 certificates to DB, add the new KEK and install the boot manager signed by Windows UEFI CA 2023. Each bit clears as its step completes.

Do I need a BIOS update?

Not always, but some firmware rejects the KEK or DB update. If you see event 1795, check the OEM for a newer BIOS/UEFI first.

Does this affect Linux dual-boot or Linux VMs?

Linux shim loaders are signed through the Microsoft UEFI CA. The update adds Microsoft UEFI CA 2023 on devices that already trust the 2011 UEFI CA. Keep distribution shim packages current and follow your distribution guidance.

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by: srvScripts editorial team
Supported versions: Windows with Secure Boot, Server 2012 and later; tested on Windows Server 2025 and Windows 11 Pro
Last full review: 6 Oct 2026
Next review: 4 Jan 2027
Sources: support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e
support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d
support.microsoft.com/en-us/topic/secure-boot-db-and-dbx-variable-update-events-37e47cf8-608b-4a87-8175-bdead630eb69
support.microsoft.com/en-us/topic/known-issues-and-resolutions-for-secure-boot-certificates-updates-5813673d-2577-4718-ad28-2554a9178e40