Windows Secure Boot Certificates Expire October 19, 2026: What You Need to Do

The Microsoft Windows Production PCA 2011 certificate expires on October 19, 2026. It signs the Windows Boot Manager (bootmgfw.efi). Your PC will not stop booting that day, because UEFI firmware does not check certificate expiry dates. The real risk is that a device without the Windows UEFI CA 2023 certificate in its Secure Boot db can no longer receive new boot manager updates or dbx revocations. That leaves it exposed to bootkits.

Quick Takeaways

• No boot cliff: Existing signed boot loaders keep working after expiry. Unpatched devices stop receiving boot-level security fixes.
• Home PCs: Keep Windows Update on and Secure Boot enabled. Microsoft delivers the 2023 certificates automatically, usually with a reboot or two.
• Admins: Do not wait for the phased rollout. Verify db and KEK contents, push the registry trigger, and watch for Event IDs 1808 and 1801.
• Old hardware: Some systems need an OEM firmware update before the new KEK can be written.

Which Certificates Are Expiring

Three of Microsoft’s 2011 certificates expire in 2026. Two already expired in June. The third is the one this guide covers.

Microsoft’s 2023 replacements are valid through 2038.

Why an Expired Certificate Doesn’t Brick Your PC

UEFI Secure Boot validates a signature chain: the boot loader’s signature must chain to a certificate stored in db, and must not match anything in dbx. Firmware generally has no trusted clock at that stage, so it ignores the validity dates. A boot manager signed by PCA 2011 keeps booting.

The problem is on the servicing side:

1. Microsoft can no longer sign new boot managers with the expired PCA 2011 key.
2. New boot managers are signed by Windows UEFI CA 2023.
3. A device without that certificate in db cannot trust them.
4. Updates to db and dbx must be signed by a KEK. Without KEK 2K CA 2023, the device cannot accept new revocation lists.

This makes older devices unable to take future boot-level fixes. Microsoft’s revocation work for the BlackLotus class of bootkits also depends on this transition.

Prerequisites

Confirm these before you touch anything:

• UEFI boot mode with Secure Boot enabled. Legacy BIOS/CSM systems are not affected.
• Windows 10 22H2 (with ESU), Windows 11, or Windows Server 2022/2025 with the latest cumulative update installed.
• BitLocker recovery keys backed up to your Microsoft account, Entra ID, or Active Directory.
• Current OEM firmware (BIOS/UEFI). Check your vendor’s support page.
• An elevated PowerShell session.

Step 1: Check Whether Secure Boot Is On

Confirm-SecureBootUEFI

• Returns True when Secure Boot is enabled.
• Returns False when it is disabled.
• Throws Cmdlet not supported on this platform on legacy BIOS.

You can also run msinfo32 and check Secure Boot State and BIOS Mode.

Step 2: Check Which Certificates Your Firmware Trusts

Read the db variable and search for the new CA:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Windows UEFI CA 2023'

• Get-SecureBootUEFI db reads the Allowed Signatures Database from NVRAM.
• .Bytes returns the raw payload.
• -match returns True if the string is present.

Check the KEK the same way:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

Step 3: Check the Servicing Status

Windows tracks the rollout in the registry:

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

• UEFICA2023Status reads NotStarted, InProgress, or Updated.
• UEFICA2023Error holds the last error code. It is absent or 0 on success.

Step 4: Trigger the Certificate Update

Home Users and Unmanaged PCs

Run Windows Update, install every pending update, and restart. Microsoft pushes certificates in phases, so your device may receive them over several weeks. Leave Secure Boot on.

Admins: Force the Update

Set the AvailableUpdates bitmask. This value tells the servicing task which components to deploy:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x5944 -Type DWord
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

• 0x5944 requests every component in one pass.
• Start-ScheduledTask runs the Secure-Boot-Update task immediately instead of waiting for its schedule.

The bitmask breaks down as follows:

Reboot when the task finishes. The boot manager swap needs at least one restart, and the full sequence sometimes takes two.

Enterprise Deployment

Use Intune, Group Policy, or Configuration Manager to set the same registry value across a fleet. Pilot on a small ring first, then widen it. Use the same ring approach as a Windows feature update.

Step 5: Verify the Result

Query the event log for the servicing events:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-TPM-WMI'; Id=1801,1808,1795,1796,1799,1800} | Select-Object TimeCreated, Id, Message | Format-List

Then rerun the db and KEK checks from Step 2. Both should return True.

BitLocker: Avoid the Recovery Screen

Changing Secure Boot variables alters PCR 7 measurements. A device using the default TPM-only BitLocker profile can prompt for the 48-digit recovery key after the update.

manage-bde -status C:
manage-bde -protectors -get C:
Suspend-BitLocker -MountPoint "C:" -RebootCount 2

• manage-bde -status shows protection state.
• -protectors -get lists the recovery key protector.
• Suspend-BitLocker -RebootCount 2 pauses protection for two restarts, then resumes automatically.

Back up recovery keys before doing any of this.

Linux Dual-Boot and Third-Party Loaders

Linux distributions boot through shim, which is signed by the Microsoft UEFI CA. The June expiry affected that chain, not the Windows one.

• Machines that only have the 2011 UEFI CA keep booting existing signed shims.
• Newer shims signed with the 2023 CA will not boot on a machine whose db lacks it.
• Update db through fwupd and LVFS where your vendor supports it:

sudo fwupdmgr refresh
sudo fwupdmgr get-updates
sudo fwupdmgr update

• refresh pulls the latest metadata from LVFS.
• get-updates lists applicable firmware and Secure Boot db updates.
• update applies them.

Verify what Linux sees with mokutil --sb-state and mokutil --db.

Troubleshooting Real-World Scenarios

Scenario 1: Event ID 1801 Never Becomes 1808

Cause: A pending reboot, or the scheduled task has not run.

Fix:

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Restart-Computer

Wait for the task, restart, and check again. Run the pair twice if the first pass only installs db.

Scenario 2: Firmware Rejects the KEK Update

Symptom: UEFICA2023Error is nonzero, or Event ID 1795 or 1796 appears.

Cause: The KEK can only be written if it is signed by the device’s Platform Key (PK). The OEM must provide that signed payload. Older firmware often lacks it.

Fix:

1. Update to the latest BIOS/UEFI from your OEM.
2. Retry the registry trigger.
3. If the OEM publishes no fix, check its Secure Boot advisory page for a stated timeline.

Scenario 3: Virtual Machines

Cause: VMs often use a fixed template with outdated KEK and db contents.

Fix: On Hyper-V, recreate the VM’s firmware variables from an updated template, or update the host and VM configuration version. On VMware and others, follow your hypervisor vendor’s NVRAM update guidance. Test on a clone first.

Scenario 4: Recovery After a Bad Update

Boot from Windows installation media, open a command prompt, and rebuild the boot files:

bcdboot C:\Windows /s S: /f UEFI

• C:\Windows is the source Windows directory.
• /s S: targets the mounted EFI System Partition (assign it with diskpart first).
• /f UEFI writes UEFI boot files.

If the firmware throws a Secure Boot violation, enter setup, restore default Secure Boot keys, and reapply the update.

Who Needs to Act

Fleet Rollout Checklist

1. Inventory: Query Confirm-SecureBootUEFI and the db/KEK checks on every endpoint.
2. Group by firmware: Sort devices by OEM model and BIOS version.
3. Update firmware first on models that need it.
4. Pilot on 5% of devices for one week.
5. Back up BitLocker recovery keys to AD or Entra ID.
6. Deploy AvailableUpdates = 0x5944 in rings.
7. Monitor Event IDs 1808, 1801, and 1795/1796.
8. Refresh recovery media, WinPE images, and deployment boot images.

FAQ

What happens if I don’t update before October 19, 2026?

Your PC keeps booting. It stops receiving boot manager updates and new dbx revocations, which leaves it vulnerable to bootkit attacks that those updates would block. Devices also may not boot newer media signed only with the 2023 CA.

Do I need to disable Secure Boot?

No. Disabling it removes boot-chain protection and is not a fix. Leave it on and update the certificates.

How do I know if my PC already has the new certificate?

Run [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes) -match 'Windows UEFI CA 2023'. A result of True means it is in db. Event ID 1808 confirms a completed update.

Is Windows 10 affected?

Yes. Windows 10 22H2 devices use the same Secure Boot chain. Devices covered by Extended Security Updates receive the certificate updates. Devices outside ESU may not get them through Windows Update.