Check and Update Your Secure Boot Certificates: A Step-by-Step Guide

Microsoft’s original 2011 Secure Boot certificates are reaching end of life. The Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011 expire in June 2026. The Microsoft Windows Production PCA 2011 follows in October 2026. Your machine will not refuse to boot the moment a date passes, because UEFI firmware does not enforce certificate expiry. But devices that never receive the 2023 replacements lose the ability to get future boot-level security fixes. This guide shows how to check your current state and deploy the new certificates on Windows, Linux, and virtual machines.

Quick Takeaways

• Existing installs keep booting after expiry. The risk is a device stuck without future Boot Manager, DBX (revocation list), and shim updates.
• Three 2011 certificates are being replaced by 2023 equivalents in the KEK and db firmware variables.
• On Windows, check with Confirm-SecureBootUEFI and the Servicing registry key. On Linux, use mokutil and fwupdmgr.
• Suspend BitLocker and update your BIOS/UEFI firmware before forcing the certificate change.

Prerequisites

Before touching any firmware variables, complete this checklist:

1. Back up the BitLocker recovery key. Run manage-bde -protectors -get C: and store the 48-digit key off the machine.
2. Update your OEM BIOS/UEFI firmware. The KEK update must be signed by your hardware vendor’s Platform Key (PK). Old firmware may reject it.
3. Install the latest cumulative Windows update. The certificate servicing logic ships through Windows Update.
4. Create bootable recovery media (Windows installation USB or a Linux live USB).
5. Open an elevated shell: PowerShell as Administrator on Windows, sudo on Linux.

How Secure Boot Trust Works

Secure Boot uses four firmware databases, each stored as an EFI variable:

The chain runs top-down. Microsoft’s 2011 KEK lets Microsoft push db and dbx updates. Once it expires, Microsoft cannot sign new db entries with it. Devices need the 2023 KEK, which is delivered through an OEM-signed update.

Firmware doesn’t check certificate timestamps. Binaries signed before expiry continue to validate. New binaries, such as a future Boot Manager or a fresh Linux shim, will be signed only with the 2023 CAs. A machine without those CAs in db will reject them.

Step 1: Check Your Secure Boot Status on Windows

Confirm Secure Boot is enabled

Confirm-SecureBootUEFI

True means enabled. False means disabled. A “Cmdlet not supported on this platform” error means legacy BIOS/CSM boot, where this guide doesn’t apply.

You can also run msinfo32 and read Secure Boot State and BIOS Mode (should be UEFI).

Check whether the 2023 certificates are already present

# Is the new Windows UEFI CA 2023 in db?
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

# Is the new KEK present?
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

• -match returns True if the certificate string exists in the variable.
• Get-SecureBootUEFI reads the raw variable and requires elevation.

Read the servicing status

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

Key names and values can shift between Windows builds. Confirm against Microsoft’s current Secure Boot servicing documentation for your version.

Read the event log

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-TPM-WMI'} -MaxEvents 30 |
  Where-Object { $_.Id -in 1795,1796,1799,1801,1808 } |
  Format-Table TimeCreated, Id, Message -Wrap

• 1801 means updated certificates are available but not yet applied.
• 1808 means the update completed successfully.
• 1795/1796 indicate firmware returned an error while writing a variable.
• 1799 means the Boot Manager signed with the 2023 CA was installed.

Step 2: Update the Certificates on Windows

Option A: Let Windows Update handle it (recommended)

Microsoft is rolling the update out in stages through cumulative updates. Install all pending updates, reboot twice, and re-run the checks above. Managed fleets can control the rollout through Group Policy, Intune, or the registry.

Option B: Trigger it manually

Suspend BitLocker for two reboots first:

Suspend-BitLocker -MountPoint "C:" -RebootCount 2

Then set the update flag and start the servicing task:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
  -Name "AvailableUpdates" -Value 0x5944 -Type DWord

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

• AvailableUpdates = 0x5944 is a bitmask that requests all steps: add the 2023 CAs to db, add the new KEK, and install the 2023-signed Boot Manager.
• Secure-Boot-Update is the built-in scheduled task that processes the flag.

Reboot, wait a minute, reboot again, then verify:

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

Expected result: Updated.

Option C: Enterprise deployment

For managed fleets, use your management tooling (Intune, Configuration Manager, Group Policy) and pilot on one hardware model per OEM. Firmware behavior varies widely by vendor and model. Stage in rings: pilot, 10%, 50%, 100%.

Step 3: Check and Update Secure Boot Certificates on Linux

Linux boots through shim, signed by the Microsoft UEFI CA. Your distribution’s shim, GRUB, and kernel chain depends on the firmware trusting that CA.

Check Secure Boot state

mokutil --sb-state

You should see SecureBoot enabled.

Inspect the db and KEK contents

sudo mokutil --db  | grep -E "Subject:|Not After"
sudo mokutil --kek | grep -E "Subject:|Not After"

Look for Microsoft UEFI CA 2023 or Microsoft Corporation UEFI CA 2011 in db and Microsoft Corporation KEK 2K CA 2023 in kek. The alternative, from the efitools package:

sudo efi-readvar -v KEK
sudo efi-readvar -v db

Update through fwupd and LVFS

Many vendors distribute KEK and db updates through the Linux Vendor Firmware Service:

sudo fwupdmgr refresh --force
sudo fwupdmgr get-devices
sudo fwupdmgr get-updates
sudo fwupdmgr update

• refresh --force pulls fresh LVFS metadata.
• get-devices lists devices, including the UEFI KEK and UEFI db pseudo-devices where supported.
• update applies pending updates and prompts for a reboot.

Update shim and GRUB packages

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade shim-signed grub-efi-amd64-signed

# RHEL/Rocky/Alma/Fedora
sudo dnf upgrade shim-x64 grub2-efi-x64

Distributions will ship shims signed with the 2023 CA. Install them after the firmware trusts the new CA, or confirm your distro handles both signatures during the transition.

Step 4: Verify the Result

Comparison: Update Methods

Troubleshooting and Real-World Scenarios

Scenario 1: UEFICA2023Error is non-zero, or Event 1795/1796 appears

The firmware rejected the variable write.

1. Update BIOS/UEFI to the latest OEM release.
2. Check the vendor’s advisory. Some models need a specific firmware revision before they accept the KEK update.
3. Retry the task: Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update".
4. If it still fails, the PK may be a test or custom key. Contact the vendor.

Scenario 2: BitLocker asks for the recovery key after reboot

Changing boot variables alters TPM PCR 7 measurements. Enter the recovery key, then run:

Suspend-BitLocker -MountPoint "C:" -RebootCount 1
Resume-BitLocker -MountPoint "C:"

This re-seals the key to the new measurements. Always suspend protection before manual updates.

Scenario 3: Linux fails with “bad shim signature” or “Verification failed: Security Violation”

The firmware does not trust the CA that signed the shim you are booting.

1. Boot a live USB with Secure Boot temporarily disabled, or use a 2011-signed shim.
2. Chroot into the install and reinstall shim-signed or shim-x64.
3. Update firmware keys through fwupdmgr, then re-enable Secure Boot.

Scenario 4: Virtual machines (Hyper-V, VMware, KVM)

VM templates created years ago carry old NVRAM with 2011 keys only.

• Hyper-V: use current Hyper-V host updates, which provide updated Secure Boot templates for new VMs. Existing Generation 2 VMs may need the KEK updated through the host.
• VMware: check Broadcom’s guidance for updating the NVRAM template or regenerating the VM’s NVRAM file.
• KVM/QEMU: use a recent OVMF package, then recreate the VM’s NVRAM variable store from the new template.

Scenario 5: Dual-boot Windows and Linux

Update Windows first, confirm Updated status, then update Linux shim packages. Keep a live USB in reach.

Scenario 6: Secure Boot disabled on a gaming PC

Anti-cheat software increasingly requires Secure Boot. Re-enable it in firmware and confirm the system boots in UEFI mode with a GPT disk. If msinfo32 shows BIOS Mode Legacy, convert with mbr2gpt /validate /allowFullOS, then mbr2gpt /convert /allowFullOS.

Revocation Is a Separate Step

Adding the 2023 certificates is not the same as revoking the 2011 Boot Manager. Revocation (adding the old PCA to dbx) permanently blocks older boot media, including Windows installation USBs and recovery discs built on the 2011 chain. Do not apply revocations until you have updated recovery media. Follow Microsoft’s published enforcement guidance and test on pilot machines first.

Fleet Audit Script

Run this across machines for a quick compliance report:

$sb   = try { Confirm-SecureBootUEFI } catch { $false }
$db   = [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
$kek  = [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes)
[pscustomobject]@{
  Computer       = $env:COMPUTERNAME
  SecureBoot     = $sb
  WinUEFICA2023  = $db  -match 'Windows UEFI CA 2023'
  UEFICA2023     = $db  -match 'Microsoft UEFI CA 2023'
  KEK2023        = $kek -match 'KEK 2K CA 2023'
}

Pipe the output to Export-Csv and collect results centrally.

FAQ

What happens if I don’t update my Secure Boot certificates?

Your PC keeps booting existing, already-signed software. But it can’t receive new boot-level security updates, DBX revocations, or newly signed Linux shims. Over time, the device falls behind on boot-chain protection and may fail to boot newly signed media.

Will my computer stop booting when the certificates expire?

No. UEFI firmware does not validate certificate expiration dates during Secure Boot checks. Problems appear later, when software signed only with the 2023 CAs hits a machine that lacks them.

How do I check if my Secure Boot certificates are updated?

On Windows, run Confirm-SecureBootUEFI, then search the db and kek variables for Windows UEFI CA 2023 and KEK 2K CA 2023 with Get-SecureBootUEFI. On Linux, run sudo mokutil --db and sudo mokutil --kek. Check UEFICA2023Status in the Servicing registry key for a summary on Windows.

Is it safe to update Secure Boot certificates manually?

Yes, with preparation. Back up your BitLocker recovery key, update the BIOS first, suspend BitLocker, and keep recovery media available. Test on one machine before rolling out broadly.