On October 19, 2026, the Microsoft Windows Production PCA 2011 certificate expired, the last of the three 2011 Secure Boot certificates most Windows machines trust. Your VMs keep booting, because UEFI firmware does not check certificate dates, but a server that only carries the 2011 keys can no longer take new boot manager, DB or DBX revocation updates. Microsoft doesn’t roll the replacement certificates out to Windows Server on its own, so you have to update Secure Boot certificates yourself, and on Proxmox VE the Windows half stalls.
This guide covers both halves. You enroll Windows UEFI CA 2023 and the new KEK from the host with qm enroll-efi-keys, then finish the boot manager update inside Windows Server and read the TPM-WMI events that show where it stopped. We ran the whole procedure both ways, host first and Windows first, in October 2026 on a Windows Server 2022 VM on Proxmox VE 8.4 with Secure Boot and a vTPM left on, so no step below turns Secure Boot off.
Certificates that expired in 2026
Three Microsoft certificates from 2011 sit in the UEFI variables of almost every Windows server, physical or virtual, and all three expired in 2026. Each one has a 2023 replacement that Windows cumulative updates already carry, but they only stage the new certificates. On a server, nothing writes them into the firmware until an administrator or a policy asks for it (KB5062710):
| Expiring certificate | Store | Expired | Replacement | What it signs |
|---|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | KEK | 2026-06-24 | Microsoft Corporation KEK 2K CA 2023 | Updates to the DB and DBX |
| Microsoft UEFI CA 2011 | DB | 2026-06-27 | Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 | Third-party boot loaders (Linux shim) and option ROMs |
| Microsoft Windows Production PCA 2011 | DB | 2026-10-19 | Windows UEFI CA 2023 | The Windows boot manager |
The risk is not a VM that refuses to boot tomorrow. It is a VM that quietly stops receiving boot-level security fixes. Microsoft says a device without the 2023 keys cannot take new boot manager, DB, DBX or revocation updates, which is exactly where the next BlackLotus-style fix would land. On a Proxmox VM the quickest way to see where you stand is to read the certificates straight out of the UEFI variables. Paste this function into an elevated PowerShell session; it walks each EFI signature list and prints the subject and expiry date of every certificate in it:
function Get-EslCerts([byte[]]$b) {
$o = 0
while ($o -lt $b.Length) {
$type = [guid]::new([byte[]]$b[$o..($o+15)])
$lsz = [BitConverter]::ToUInt32($b, $o+16); $hsz = [BitConverter]::ToUInt32($b, $o+20); $ssz = [BitConverter]::ToUInt32($b, $o+24)
$p = $o + 28 + $hsz
while ($p -lt $o + $lsz) {
if ($type -eq [guid]'a5c059a1-94e4-4aa7-87b5-ab155c2bf072') {
$c = [Security.Cryptography.X509Certificates.X509Certificate2]::new([byte[]]$b[($p+16)..($p+$ssz-1)])
[pscustomobject]@{ Subject = ($c.Subject -replace '^.*CN=([^,]+).*$','$1'); NotAfter = $c.NotAfter.ToString('yyyy-MM-dd') }
}
$p += $ssz
}
$o += $lsz
}
}Then list the platform key, the KEK and the DB:
foreach ($v in 'PK','KEK','db') { "== $v"; Get-EslCerts (Get-SecureBootUEFI $v).bytes | Format-Table -AutoSize -HideTableHeaders | Out-String -Width 200 }Our Server 2022 VM, cloned from a template with a Proxmox EFI disk created before the 2023 keys existed, still booted with Secure Boot on and showed only the 2011 certificates. The platform key and the first KEK entry are a Debian key, which is what Proxmox’s pre-enrolled OVMF variables ship with, and that detail decides how the rest of this goes:
If your DB already lists Windows UEFI CA 2023 and your KEK lists Microsoft Corporation KEK 2K CA 2023, the firmware side is done and only the Windows checks near the end of this guide apply to you.
The KEK step Windows cannot finish on Proxmox
Windows can add certificates to the DB by itself. Our VM accepted all three DB updates while its only Microsoft KEK was the expired 2011 one, because UEFI does not check validity dates and that KEK still verifies the signed payload. The KEK is different: an update to the KEK has to be signed by the platform key, and Microsoft only holds signed KEK payloads for platform keys that hardware vendors registered with it. Proxmox’s OVMF variables carry a Debian platform key, so Windows has nothing it can apply.
We ran Microsoft’s documented trigger on the 2011-only VM first, to see exactly where it stops. The DB certificates went in, the 2023 boot manager installed after one reboot, and the KEK step failed on both passes with event 1803. The servicing status then sits at InProgress with no further retries that can succeed:
Read AvailableUpdates as a bit mask of steps still to do. 0x4004 means everything except bit 0x0004, the KEK, has been processed, and 0x4000 is a modifier bit that is never cleared. That is why a VM can look fine to anyone who only checks the DB, while Windows keeps logging 1801 every time the task runs.
Event 1803: “A PK-signed Key Exchange Key (KEK) cannot be found for this device”
On a Proxmox VM this error is expected, not a fault in your guest. The full event text names the firmware as FirmwareManufacturer:Proxmox distribution of EDK II, and Microsoft’s troubleshooting guidance has no in-guest fix for it. The KEK has to come from outside the guest, which on Proxmox means qm enroll-efi-keys on the host. The recovery section further down walks through it.
Proxmox packages that can enroll the 2023 keys
The host-side fix lives in qemu-server, and older builds either do not have it or only enroll part of the set. Proxmox added the command in stages, so check the exact version before you plan a maintenance window (qemu-server changelogs for Proxmox VE 9 and Proxmox VE 8):
- Proxmox VE 9 runs qemu-server 9.1.5 or later. 9.0.30 added
qm enroll-efi-keyswith only Microsoft UEFI CA 2023, 9.1.4 added Windows UEFI CA 2023, and 9.1.5 added the KEK 2K CA 2023, the last of the three thatms-cert=2023kstands for. - Proxmox VE 8 runs qemu-server 8.4.6 or later, the backport that introduced
ms-cert=2023k(we tested 8.4.10). - The
python3-virt-firmwarepackage is installed, becauseqm enroll-efi-keyscalls itsvirt-fw-varscode to edit the EFI disk. pve-edk2-firmwareis 4.2025.05-1 or later (4.2025.05-1~bpo12+1on Proxmox VE 8). Per the Proxmox docs, new EFI disks then start out with the 2011 and 2023 certificates; we did not create one to check.
Check what the node has now:
pveversion -v | grep -E '^(qemu-server|pve-edk2-firmware)'Our lab node reported these versions after the upgrade:
pve-edk2-firmware: 4.2025.05-1~bpo12+1
qemu-server: 8.4.10Our node started on qemu-server 8.4.1, where qm enroll-efi-keys returned “unknown command”. If yours is behind too, update from your configured Proxmox repository (the no-subscription repository works if you don’t have a subscription). Use a full upgrade, which is what Proxmox recommends because a plain apt upgrade can leave a node partly upgraded. A new kernel it installs only takes effect at the next host reboot, which this procedure doesn’t need. It also brings the pve-manager build with the web UI button (8.4.18 on Proxmox VE 8):
apt update
apt full-upgradeOn our shared lab node we pulled only the three packages we needed instead, with apt install qemu-server pve-edk2-firmware python3-virt-firmware. That also updated libpve-common-perl and libpve-access-control, restarted no running VMs, and was enough for every step below, but it left pve-manager on its old version.
Running VMs keep using the QEMU process they started with, so nothing changes for them until their next cold start. That next start is also where the new code begins warning you. One more thing to plan for: Proxmox VE 8 reached end of life in August 2026 (Proxmox FAQ), and 8.4.10 is the latest qemu-server build for it. The enrollment works there, but the node itself needs the move to 9, and our Proxmox VE post-install checklist covers the repository setup on the new version.
Warning: “EFI disk without ‘ms-cert=2023k’ option”
After the update, every start of a VM whose EFI disk has pre-enrolled keys but lacks the marker prints this in the task log (templates and disks without pre-enrolled keys stay silent). It’s the first sign most admins see, and it also tells you about BitLocker:
EFI disk without 'ms-cert=2023k' option, suggesting that not all UEFI 2023
certificates from Microsoft are enrolled yet. The UEFI 2011 certificates expire
in June 2026! The new certificates are required for secure boot update for Windows
and common Linux distributions. Use 'Disk Action > Enroll Updated Certificates'
in the UI or, while the VM is shut down, run 'qm enroll-efi-keys 110' to enroll
the new certificates.
For Windows with BitLocker, run the following command inside Powershell:
manage-bde -protectors -disable <drive>
for each drive with BitLocker (for example, <drive> could be 'C:').
This is required for each drive with BitLocker before proceeding with enrollment.
Otherwise, you will be prompted for the BitLocker recovery key on the next boot.The VM still starts normally. The warning is there because the next steps change measured boot values, and that is what trips BitLocker.
VMs that still need the 2023 keys
Only EFI disks created with pre-enrolled-keys=1 can be updated this way, and the marker on efidisk0 tells you which ones already were. Only 2023k means complete: the Proxmox docs say the older ms-cert=2023 and 2023w markers, left by earlier Proxmox VE 9 builds, may mean partial enrollment, so the loop below counts them as needing it. A short loop over the VM configs on each node sorts them into three groups without touching any VM. Create it on the node:
vim /root/efi-cert-audit.shAdd the loop. The sed stops at the first snapshot section, so only the current config is read:
for conf in /etc/pve/qemu-server/*.conf; do
vmid=$(basename "$conf" .conf)
efi=$(sed '/^\[/q' "$conf" | grep '^efidisk0:')
[ -z "$efi" ] && continue
case "$efi" in
*ms-cert=2023k*) state="2023k" ;;
*pre-enrolled-keys=1*) state="needs-enroll" ;;
*) state="no-pre-enrolled-keys" ;;
esac
echo "$vmid $state"
doneRun it:
bash /root/efi-cert-audit.shBefore we enrolled VM 110, our lab node had one VM already marked (created after the firmware update by another lab user), six that still need enrolling and one EFI disk without pre-enrolled keys:
110 needs-enroll
112 needs-enroll
237 needs-enroll
245 needs-enroll
246 needs-enroll
3150 2023k
4002 no-pre-enrolled-keys
8845 needs-enrollThe script only reads the configs on the node it runs on, so run it on each node of a cluster. Templates show up too (112 here is a Windows template), and they matter most, because every clone inherits the old variables. A no-pre-enrolled-keys disk has no Microsoft keys to update, so qm enroll-efi-keys skips it. Replacing that EFI disk with a pre-enrolled one turns Secure Boot on for a guest that never had it, so an unsigned boot loader stops booting, and the Proxmox docs warn it resets any custom OVMF menu settings such as the boot order. Treat that as a planned change per VM, not part of this rollout.
Error: “VM 113 is a template”
qm enroll-efi-keys refuses a template outright, and a template never prints the start warning either, so it can stay on the old keys unnoticed. We hit this on a converted copy of our Windows template:
VM 113 is a templateThe fix is to rebuild the template from an enrolled copy. Full-clone the template to a free VM ID, enroll the clone, then convert the clone into the new template. pvesh get /cluster/nextid prints the next free ID in the cluster. Set both IDs first:
TPL=113
NEWTPL=114Then clone, enroll and convert:
qm clone $TPL $NEWTPL --full --name win2022-template-2023
qm enroll-efi-keys $NEWTPL
qm template $NEWTPL
qm config $NEWTPL | grep -E 'efidisk|^template'The new template keeps the marker, and a full clone we made from it came up with ms-cert=2023k already set, so new VMs skip the host enrollment. Each one still needs the Windows steps further down:
efidisk0: zfs-pool:base-114-disk-0,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=1M
template: 1Clones made from the old template earlier still need enrolling on their own. Linked clones keep using the old template’s base disks, so the old template can’t be deleted until they are gone; enroll those VMs individually and retire the old template last.
Host-side enrollment with qm enroll-efi-keys
Do this before you touch the Windows side. With the 2023 KEK already in the firmware, Windows never hits event 1803 and finishes in one reboot. Set the VM ID once so the commands below work as written:
VMID=110If the guest uses BitLocker, suspend the protectors inside Windows first, for every encrypted drive. Skip this and a boot after the key change asks for the recovery key, which on a remote server is a console session or a support ticket. A plain -disable resumes protection after the very next restart, and this procedure has at least two boots (the start after enrollment and the restart for the boot manager), so give it a reboot count. Microsoft’s own example for DB updates uses 2 (KB5016061); we’d use 3 to leave one spare. Our lab VM had no BitLocker, so this is not something we ran:
manage-bde -protectors -disable C: -RebootCount 3The enrollment only works on a stopped VM, so shut it down cleanly:
qm shutdown $VMIDTake a snapshot while it’s down, so the disk inside it is clean rather than crash-consistent. The EFI disk and the TPM state are part of a Proxmox snapshot, so a rollback puts the old variables back if the guest misbehaves. We used exactly that to replay both orders on the same VM. On ZFS, a rollback only goes to the newest snapshot, so don’t stack other snapshots on top before you know the update held. If your storage can’t snapshot, a backup to Proxmox Backup Server does the same job:
qm snapshot $VMID before-2023-keysDon’t run the next block now. Keep it for later. If anything goes wrong, including a BitLocker recovery prompt you can’t answer, stop the VM and go back to this point. The rollback restores the old EFI variables and TPM state together:
qm stop $VMID
qm rollback $VMID before-2023-keysWith the snapshot in place, enroll the keys:
qm enroll-efi-keys $VMIDIt took under two seconds on our VM. The output shows it keeping both 2011 DB certificates, adding Microsoft UEFI CA 2023 and Windows UEFI CA 2023 to the DB and the KEK 2K CA 2023 to the KEK, then setting ms-cert=2023k on the disk:
Two details in that output matter. The 2011 certificates stay, so Linux guests whose shim is still signed by Microsoft UEFI CA 2011 keep booting. And it doesn’t add Microsoft Option ROM UEFI CA 2023; Windows adds that one itself in the next step. In the web UI the same action is Hardware > EFI Disk > Disk Action > Enroll Updated Certificates (Proxmox VE docs), added in pve-manager 8.4.18 on Proxmox VE 8, and on Proxmox VE 9 the UI suggests it from pve-manager 9.1.7. We used the CLI and did not test the button. Start the VM again:
qm start $VMIDThe task log no longer prints the ms-cert=2023k warning. Templates need the rebuild from the previous section instead, because the command refuses them.
Update Secure Boot certificates inside Windows Server
The firmware now trusts the 2023 certificates, but Windows is still booting a boot manager signed by PCA 2011, and its servicing state does not know anything changed. The registry key below tells the built-in Secure-Boot-Update task to process every step, and starting the task runs it now instead of at the next 12-hour interval. These registry keys exist on Windows Server 2016, 2019, 2022 and 2025, and on 2012 and 2012 R2 with ESU, once an update from November 11, 2025 or later is installed (KB5068202); our VM was on the September 2026 update. In an elevated PowerShell session:
reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"Give the task about a minute, then read the bit mask and the servicing status:
"AvailableUpdates: 0x{0:X}" -f (Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot).AvailableUpdates
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot\Servicing | Format-List UEFICA2023Status, UEFICA2023ErrorEvent, WindowsUEFICA2023Capable0x4100 means every certificate step is done and only the boot manager (0x0100) is left. The error event 1800 here is a reboot request, not a failure:
AvailableUpdates: 0x4100
UEFICA2023Status : InProgress
UEFICA2023ErrorEvent : 1800
WindowsUEFICA2023Capable : 1The System log explains each step. This query asks for only the TPM-WMI event IDs that belong to the certificate update, so the boot-time TPM events that pile up on a long-running server can’t push them out of the result, and lists them in the order they were written:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-TPM-WMI'; Id=1032,1036,1043,1044,1045,1795,1796,1797,1799,1800,1801,1802,1803,1808} | Sort-Object RecordId | Format-Table Id, LevelDisplayName, @{n='Message';e={($_.Message -split "`r?`n")[0]}} -WrapAfter the host enrollment, Windows only had one certificate left to add, the Option ROM CA, so the first pass logged just that plus the reboot request:
Id LevelDisplayName Message
-- ---------------- -------
1044 Information Secure Boot DB update to install Microsoft Option ROM UEFI CA 2023 certificate applied successfully
1800 Warning A reboot is required before installing the Secure Boot update. Reason: Boot Manager (2023)
1801 Error Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware. Review the published guidance to complete the update and maintain
full protection. This device signature information is included here.Each event ID tells you which step ran, so you can tell a stall from a pending reboot:
- Events 1036, 1044 and 1045 mean a 2023 certificate was written to the DB.
- Event 1032 means BitLocker blocked the update, so the protectors were not suspended.
- Event 1800 means the next step waits for a restart.
- Event 1803 means the KEK could not be applied, which on Proxmox means the host enrollment is missing.
- Event 1799 means the 2023-signed boot manager is on the EFI partition.
- Event 1808 means every step is done.
Event 1801 at this point only means “not finished yet”. Restart the server, because the boot manager swap waits for a fresh boot:
Restart-ComputerOnce it is back, run the task a second time and wait another minute:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"Rerun the two status lines and the event query. The mask drops to 0x4000, the status reads Updated, and the log ends on 1799 (2023 boot manager installed) and 1808, the event that means this device is fully updated:
WindowsUEFICA2023Capable at 2 means the certificate is in the DB and the machine boots the 2023-signed boot manager. Microsoft documents that value as informational only. Treat UEFICA2023Status and event 1808 as the result. With a few servers, this manual path is fine. For a fleet, Microsoft’s Group Policy setting Computer Configuration > Administrative Templates > Windows Components > Secure Boot > Enable Secure Boot certificate deployment starts the same deployment without touching each server, once your Group Policy store has the current Windows Server Administrative Templates (.admx) that contain it. On Proxmox guests it still needs the host enrollment first, or every server ends up stuck on 1803.
Recovery for a VM where Windows ran first
If someone already set 0x5944 or a policy pushed it, the VM is in the state from the 1803 screenshot above: DB updated, 2023 boot manager installed, KEK missing, mask stuck at 0x4004. Nothing in the guest moves it forward, and it doesn’t need rolling back either. Run the same sequence as the host-side section: suspend BitLocker with a reboot count, qm shutdown $VMID, qm snapshot $VMID before-2023-keys, qm enroll-efi-keys $VMID, then qm start $VMID. On that VM the enrollment found both 2023 DB certificates already present and added only the KEK:
efidisk0: enrolling Microsoft UEFI CA 2023
INFO: reading raw edk2 varstore from /dev/zvol/zfs-pool/vm-110-disk-0
INFO: var store range: 0x64 -> 0x40000
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftCorporationUEFICA2011.pem
INFO: certificate already present, skipping
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftUEFICA2023.pem
INFO: certificate already present, skipping
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftWindowsProductionPCA2011.pem
INFO: certificate already present, skipping
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/WindowsUEFICA2023.pem
INFO: certificate already present, skipping
INFO: add KEK cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftCorporationKEK2KCA2023.pem
INFO: writing raw edk2 varstore to /dev/zvol/zfs-pool/vm-110-disk-0
successfully updated efidiskAfter that start, one more run of the Secure-Boot-Update task cleared the KEK bit, with no extra Windows restart. The status read Updated, and these are the last lines of the event query, ending on 1808 like the host-first order:
1803 Error A PK-signed Key Exchange Key (KEK) cannot be found for this device. Check with the device manufacturer for proper key provisioning.
1799 Information Boot Manager signed with Windows UEFI CA 2023 was installed successfully
1801 Error Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware. Review the published guidance to complete the update and maintain
full protection. This device signature information is included here.
1808 Information This device has updated Secure Boot CA/keys. This device signature information is included here.The old 1803 and 1801 entries stay in the log, so read the last line, not the first error you see.
Checks that prove the update held
Event 1808 is Windows reporting its own view. Check the firmware variables directly too, especially before you tell anyone a fleet is done. Both lines must print True:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'Running the Get-EslCerts loop from the first section again shows the full picture. Our updated VM ended with three KEK entries and five DB certificates, the 2011 ones kept alongside the 2023 set:
== PK
Debian UEFI Secure Boot (PK/KEK key) 2029-07-05
== KEK
Debian UEFI Secure Boot (PK/KEK key) 2029-07-05
Microsoft Corporation KEK CA 2011 2026-06-24
Microsoft Corporation KEK 2K CA 2023 2038-03-02
== db
Microsoft Windows Production PCA 2011 2026-10-19
Microsoft Corporation UEFI CA 2011 2026-06-27
Windows UEFI CA 2023 2035-06-13
Microsoft Option ROM UEFI CA 2023 2038-10-26
Microsoft UEFI CA 2023 2038-06-13Note the dates: Windows UEFI CA 2023 is valid until 2035, three years before the other 2023 certificates. The platform key stays Debian’s, which is fine, because nothing in this update needs it changed.
Get-AuthenticodeSignature still reports PCA 2011
Don’t use Get-AuthenticodeSignature on the EFI partition’s boot manager to confirm the switch. On our updated VM it reported the file as signed by Microsoft Windows Production PCA 2011, which looks like a failed update. It isn’t: the cmdlet returns the Windows catalog signature, not the signature embedded in the EFI binary that the firmware checks:
SignatureType : Catalog
Status : Valid
Issuer : Microsoft Windows Production PCA 2011Parsing the embedded signatures of \EFI\Microsoft\Boot\bootmgfw.efi and \EFI\Boot\bootx64.efi on the same partition showed Windows UEFI CA 2023 as the only signer. To confirm which boot manager is installed, trust event 1799, not the cmdlet.
Secure Boot certificate audit checklist
Run through this per VM, and per node for the first two items. A VM passes only when every line holds:
- The node runs qemu-server 9.1.5 or later on Proxmox VE 9, or 8.4.6 or later on Proxmox VE 8.
- The audit script lists every Windows VM as
2023k, and each Windows template was rebuilt from an enrolled clone. - The VM start task log no longer shows the
ms-cert=2023kwarning. - BitLocker protectors were suspended with a reboot count before enrollment on every encrypted guest, and
manage-bde -status C:shows protection on again afterwards. AvailableUpdatesreads0x4000andUEFICA2023StatusreadsUpdated.- The newest certificate event in the System log is 1808, with no 1803 after it.
- Both firmware checks for KEK 2K CA 2023 and Windows UEFI CA 2023 print
True. - The
before-2023-keyssnapshot is gone (qm delsnapshot $VMID before-2023-keys) once the VM has booted cleanly a few times, so it does not pin old disk blocks.
The protector step is the one we could not test, so do it by the book on encrypted servers: suspend with a reboot count, enroll, boot, run the task, then turn protection back on with manage-bde -protectors -enable C: if it hasn’t resumed by itself. We left out the optional DBX revocation of PCA 2011 (bit 0x80) on purpose. It blocks every boot medium still signed by the old certificate, including older install ISOs, so plan it as a separate change once your recovery media are rebuilt. Building a fresh template with the Windows Server 2022 template guide or the Server 2025 version on a current node gives you new EFI disks that already carry the 2023 keys.
