Tonight at 18:51 UTC a CA in your servers expires
Pull Microsoft's own copy of the certificate and ask it when it dies:
curl -sSL -o pca2011.crt https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt
openssl x509 -inform DER -in pca2011.crt -noout -subject -enddate
subject=C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Windows Production PCA 2011
notAfter=Oct 19 18:51:42 2026 GMT
That is today. Microsoft Windows Production PCA 2011 signs the Windows boot manager, and it has been sitting in the Secure Boot db of most x86 hardware since 2011. Probably yours too. It is the last of three 2011 certificates to go. The KEK CA 2011 expired on June 24 and the Microsoft UEFI CA 2011, the one that signs Linux shims, followed on June 27. Microsoft lists all three in its Secure Boot certificate expiration overview (KB5062710).
You will not get paged tonight. Nothing will go down. And that is the part you should worry about.
Firmware ignores expiry dates, and that is the trap
On port 443, expiry is loud. The cert runs out and browsers throw a full-page error. Ten minutes later somebody has opened a bridge call. We complain about that. We shouldn't. The failure forces the fix. (Why certificates expire at all is its own discussion.)
UEFI firmware does not check validity dates. It can't trust its own clock at boot, so it just ignores notAfter. Fedora's explainer from June 11 puts it plainly: machines "will continue to boot long after June is over as long as the current public keys are not removed from the firmware database." Steve McIntyre, who maintains Debian's shim, wrote the day after the June expiry that the world "doesn't seem to have ended yesterday" (his post, HN discussion).
So boot keeps working. The catch: after tonight Microsoft can't sign anything new with that key. Microsoft's wording for a device that never got the 2023 certificates: it "will no longer be able to receive new security protections for the early boot process, including updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities."
Read that list again. Revocation lists. The next BlackLotus-class bootkit gets a DBX update, and your un-migrated box can't apply it. The box looks fine. It stays open to a bootkit you'll read about on the news, and none of your monitoring will say a word. I'd take a loud outage over that any day.
The trust store you can't push with Ansible
If this were a CA bundle on disk you'd ship a new one and move on. You've fought trust stores in containers before. This is worse.
The db and KEK live in firmware NVRAM. Adding Windows UEFI CA 2023 to db needs an update signed by a valid KEK. Adding the new Microsoft Corporation KEK 2K CA 2023 to KEK needs a payload signed by your hardware vendor's platform key. If the vendor never shipped that for your model, Windows can't finish the job. Microsoft's troubleshooting guide has an event for exactly this: 1803, "Missing OEM PK-signed KEK payload."
The same guide lists firmware that overwrites db when it should append to it. The old certificates vanish and the machine won't boot. It also lists BitLocker recovery prompts after the update, and repeated ones on machines that have PXE first in the boot order. That's firmware for you. Every vendor implemented the same spec slightly differently, and you find out which one you got when the update lands.
Check a Windows fleet
The quickest yes/no is the check Microsoft gives in its CVE-2023-24932 guidance. Run it elevated:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
True means the new CA is in db. False means this machine's early-boot security stopped moving forward today.
If you manage the rollout yourself, the registry key documentation has you set AvailableUpdates to 0x5944 and watch the servicing status:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' `
-Name 'AvailableUpdates' -Value 0x5944 -Type DWord
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' |
Select-Object UEFICA2023Status, UEFICA2023Error
UEFICA2023Status goes from NotStarted to InProgress to Updated. The \Microsoft\Windows\PI\Secure-Boot-Update scheduled task does the work and runs every 12 hours, and you may need a reboot before it finishes. If AvailableUpdates sits at 0x4004, the KEK step is stuck, and you're back to event 1803 and a firmware ticket with your hardware vendor.
Don't do this across the whole estate on a Friday. Start with one machine per hardware model. Reboot it and make sure it comes back without asking for a BitLocker key.
Check your Linux servers
Linux boxes went through their version of this in June, because the UEFI CA 2011 signs shim. Look at what your firmware trusts:
sudo mokutil --sb-state
sudo mokutil --db | grep -o 'CN=[^,]*'
sudo mokutil --kek | grep -o 'CN=[^,]*'
You want Microsoft UEFI CA 2023 in the db output next to Microsoft Corporation UEFI CA 2011. If only the 2011 one is there, you're fine today and stuck later. Red Hat's RHEL guidance says it directly: systems with the 2011 CA "will continue to boot after June 27, 2026," but a future bootloader signed only with the 2023 key may not boot on a machine that lacks it.
The distros are covering for this with dual-signed shims for now. Red Hat scheduled them for RHEL 9 and 10 in May 2026 and for RHEL 8 in June. Check which signatures your shim actually has with pesign -S -i on the binary under /boot/efi/EFI/, and let fwupdmgr update push the db and KEK updates where your vendor supports it through LVFS.
Dual signing buys you time. That's all it does. At some point a shim ships with only the 2023 signature, and the boxes still running 2011-only firmware are the ones you'll be fixing by hand.
Your VMs are stuck on the day you created them
This is the part most teams miss, and it's the same blind spot as the internal certificate that took down GitHub Actions: nobody looks there.
A KVM guest with OVMF gets its own copy of the UEFI variable store when it's created, a per-VM NVRAM file built from the hypervisor's template. Updating edk2-ovmf on the host fixes the template, so new VMs get the 2023 certificates. Red Hat names the minimum versions: edk2-ovmf-20241117-2.el10 on RHEL 10 and edk2-ovmf-20231122-6.el9 on RHEL 9. Your existing guests keep the db they were born with until something inside them updates it.
Hyper-V has its own twist. Microsoft's troubleshooting guide says host and guest both need the March 2026 updates, and event 1795 in a guest means the host is the one missing it. Your golden images and VM templates count too. A template built in 2023 still produces 2011-only VMs today.
The other shoe: PCA 2011 goes into the DBX
Expiry was the gentle part. The CVE-2023-24932 page, last updated September 30, 2026, describes an enforcement phase where "the 'Windows Production PCA 2011' certificate will automatically be revoked by being added to the Secure Boot UEFI Forbidden List (DBX) on capable devices." It still has no date. The page says only "no earlier than January 2026."
Revocation is the one firmware does enforce. Once PCA 2011 is in a machine's DBX, anything signed under it won't boot there. That covers the installation ISO in your PXE server, the recovery USB in the drawer, and the WinPE image your imaging pipeline built in 2024. If you've read what actually happens when a TLS cert gets revoked, you know TLS revocation mostly fails open. DBX revocation fails closed. And it hits exactly the media you only pull out during an incident.
Rebuild your boot media now, on machines that already run the 2023 boot manager. Right now it's a ticket. After enforcement it's a 3 a.m. problem.
Put June 13, 2035 somewhere that will still exist
Here's the replacement's validity, from Microsoft's own download:
curl -sSL -o winuefica2023.crt 'https://go.microsoft.com/fwlink/?linkid=2239776'
openssl x509 -inform DER -in winuefica2023.crt -noout -subject -enddate
subject=C = US, O = Microsoft Corporation, CN = Windows UEFI CA 2023
notAfter=Jun 13 19:08:29 2035 GMT
The other 2023 certificates, the Microsoft UEFI CA, the Option ROM CA and the KEK 2K CA, run until 2038. The Windows one is first, in less than nine years.
Whoever planned for these certificates in 2011 was long gone by 2026. Expect the same in 2035. Your certificate inventory almost certainly stops at things with a hostname and a port. The certs that age badly sit in firmware, HSMs, code-signing setups and appliance trust stores, where expiry doesn't fail loudly and a dashboard won't help. Write those down too, with an owner and a date, in a system that will outlive your current job title.
Frequently asked questions
Will my servers fail to boot after October 19, 2026?
No. UEFI firmware does not check certificate expiry dates, so a machine that boots today will boot tomorrow. What stops is Microsoft's ability to sign new Windows boot manager, db and DBX updates for machines that only trust the 2011 certificates, so those machines stop receiving early-boot security fixes.
Is the Linux shim affected by the Windows Production PCA 2011 expiry?
Not directly. Shim is signed under the Microsoft UEFI CA, whose 2011 version expired on June 27, 2026. Linux machines need Microsoft UEFI CA 2023 in their db to boot future shims that carry only the 2023 signature, which mokutil --db will show you.
Do I need to update Secure Boot certificates on cloud VMs?
It depends on who owns the firmware variables. On self-run KVM, each guest keeps the variable store copied at creation, so updating edk2-ovmf on the host only helps new VMs. On public clouds the provider controls the virtual firmware, so check your provider's own Secure Boot guidance, as Microsoft publishes for Linux on Azure VMs.
Why does the KEK update fail on some older hardware? Adding the 2023 KEK requires a payload signed by the device maker's platform key, and not every vendor has published one for every model. Windows logs event 1803 when that payload is missing, and the only fix is a firmware or KEK update from the vendor.
When will Microsoft add PCA 2011 to the DBX? Microsoft has not announced a date. Its CVE-2023-24932 guidance, last updated September 30, 2026, says only that the enforcement phase will come no earlier than January 2026, so rebuild boot and recovery media now and don't wait for the announcement.
