There’s a deadline most IT teams haven’t put on the calendar yet, and it’s about three weeks out. On June 26, 2026, the Microsoft Secure Boot certificates that have been baked into nearly every x86 PC since 2011 start expiring. The Key Exchange Key (KEK CA 2011) and the third-party UEFI CA (Microsoft UEFI CA 2011) go first. The certificate that signs the Windows boot manager itself — Windows Production PCA 2011 — follows in October 2026.
Here’s the good news up front, because the headlines have been a little breathless: your machines won’t brick on June 27. Nobody’s laptop refuses to POST. The bad news is subtler and, honestly, worse for anyone who takes platform security seriously. Without action, your fleet quietly loses the ability to receive new boot-chain security updates — the very mechanism Secure Boot exists to protect. You end up with a frozen trust anchor on a threat surface that very much keeps moving.
I’ve spent the last couple of weeks digging through Microsoft’s playbook, Red Hat’s guidance, and the OEM FAQs because the vendor docs are each correct and each incomplete. Microsoft tells you about Windows. Red Hat tells you about RHEL. Nobody stitches together the Windows-plus-Linux-plus-VMs-plus-CI picture that an actual platform team has to deal with. So that’s what this is.
What actually expires, and what each piece signs
Secure Boot isn’t one certificate. It’s a small chain of trust stored in your firmware’s NVRAM, and you need to know which link is rotting to know what you’re at risk of losing.
- Microsoft Corporation KEK CA 2011 — the Key Exchange Key. This is what authorizes updates to the signature database (DB) and the forbidden-signature database (DBX). Expires June 2026.
- Microsoft UEFI CA 2011 — the third-party CA that signs non-Windows bootloaders, most notably the Linux
shim, plus option ROMs on add-in cards. Expires June 2026. - Microsoft Windows Production PCA 2011 — signs the actual Windows Boot Manager and boot components. Expires October 2026.
The replacement chain splits responsibilities more cleanly than the old one did. You’re migrating to KEK CA 2023, Microsoft UEFI CA 2023, and Windows UEFI CA 2023. One nice change: Microsoft broke option-ROM signing out into a separate Microsoft Option ROM UEFI CA 2023, so a system that needs to trust an add-in card’s firmware no longer has to also trust every third-party bootloader on earth. That’s a real reduction in blast radius if you care about what your DB actually vouches for.
The key mental model: KEK is the key that lets you update DB and DBX. If your KEK is expired, you can’t enroll new trusted signers and — this is the part that matters — you can’t receive new DBX revocations either. DBX is the bootkit blocklist. When BlackLotus-class malware gets discovered, the fix ships as a DBX update. An expired KEK means that pipeline goes dark.
What breaks vs. what keeps working
Let me be precise here because the panic and the shrug are both wrong.
Keeps working: Any machine that already has the 2011 certs enrolled keeps booting indefinitely. Expiration affects the ability to sign new binaries, not the ability to validate already-signed ones. Your existing Windows Boot Manager, your existing shim — all still trusted, still boot. An expired cert validates a signature made while it was valid.
Breaks (eventually): Three things degrade, on different timelines.
First, no new DBX updates. Your bootkit blocklist freezes at whatever it was on expiry day. That’s the immediate, ongoing security cost.
Second, no new boot-manager updates. Once Windows ships a Boot Manager signed only by the 2023 PCA, a machine that hasn’t enrolled the 2023 trust can’t run it. Microsoft has said boot-critical security servicing for those binaries stops for un-migrated devices.
Third, future OS upgrades. Down the road, full Windows feature updates will expect the EFI system partition signed with the 2023 chain. Microsoft has said the installer will deliberately fail the upgrade rather than leave you with an unbootable box — which is the right call, but it means an un-migrated fleet hits a wall later.
So nothing explodes on the 26th. You just start accumulating a security debt that compounds and eventually blocks upgrades. For a personal machine, meh. For a managed fleet under a compliance regime, that’s a finding waiting to happen.
The 2023 rollout on Windows
For most managed Windows devices, Microsoft wants to handle this for you through a managed update flow, and a lot of PCs built since 2024 already shipped with the 2023 certs. But “Microsoft will handle it” is doing heavy lifting in those sentences, and if you run a fleet you’ll want to drive it deliberately rather than wait and hope.
The mechanism is a registry value that opts the device into the servicing flow. The relevant key:
# Opt the device into the Secure Boot certificate servicing updates
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' `
-Name 'AvailableUpdates' -Value 0x5944That value tells the servicing component which updates to apply (the DB and KEK 2023 enrollment). Then the actual work happens through a scheduled task, and it usually needs more than one reboot to walk through all the stages:
Start-ScheduledTask -TaskName '\Microsoft\Windows\PI\Secure-Boot-Update'
# reboot, then run it again — the update progresses across rebootsTo check where a machine is in the process:
# Servicing status — watch this move toward completion
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' `
-Name 'UEFICA2023Status'
# Sanity checks
Confirm-SecureBootUEFI # is Secure Boot even on?
Get-SecureBootUEFI -Name DB # inspect the signature database contentsAt fleet scale you’d push the registry value and trigger the task through Intune (a proactive remediation or a configuration script), or your MDM of choice — Jamf for the Mac-managing-PC crowd, Tanium, whatever you run. The pattern is the same: set the opt-in, kick the task, reboot, verify UEFICA2023Status, repeat until it reports done, then confirm the 2023 certs landed in DB. Don’t treat it as fire-and-forget. Build the verification into your reporting so you can prove coverage, not assume it.
One genuinely annoying gotcha: machines with a password-protected UEFI/BIOS may refuse the firmware-side update. If your fleet was hardened with firmware passwords (a lot of regulated environments do this), you may need an OEM firmware update or a manual touch. Find that subset now, not in week three.
The hard cases the vendor docs skip
This is where the cross-platform reality bites, and where each vendor’s doc conveniently stops at its own border.
Linux and dual-boot
Linux trusts Microsoft here whether you like it or not. The standard distro shim — the first-stage loader that then loads GRUB and your kernel — is signed by the Microsoft UEFI CA 2011. That’s the third-party CA expiring in June. So Linux is squarely in scope, even though the conversation is framed as a Windows thing.
The reassurance is the same as everywhere: existing installs keep booting. An already-enrolled 2011 shim stays valid for validation. What you need is updated, 2023-signed shims for when you reinstall, re-image, or stand up new hosts. Red Hat has said it’s shipping updated shim builds for RHEL 8, 9, and 10 ahead of the deadline; the other major distros are on the same track. So the action item is patch hygiene — take the shim updates — plus knowing how to check state:
mokutil --sb-state # Secure Boot enabled or not
mokutil --db | grep -A13 '\[key' # what's actually enrolled in DBFor dual-boot machines specifically, watch the ordering. If the Windows-side 2023 enrollment updates the DB/KEK in firmware, and your Linux side is relying on an older shim, you want both sides patched and both sets of signers present in DB. The 2023 update adds trust, it doesn’t yank 2011, so a correctly patched dual-boot box trusts both generations. The failure mode is the half-migrated machine — new firmware DB, stale unsigned-for-2023 loader on one OS — so treat dual-boot hosts as needing both OSes updated, not just whichever one you logged into last.
A sharper edge for the disk-encryption crowd: if you unlock LUKS (or BitLocker) against TPM PCR values, a firmware DB/KEK change can move those PCRs. Reseal your secrets against the new measurements before you reboot into a state where the TPM won’t release the key and you’re typing a recovery passphrase you hopefully wrote down. Red Hat calls this out explicitly and it’s the one thing here that can actually lock you out of your data on the day.
VMs and golden images
Virtual machines have their own Secure Boot NVRAM, and it doesn’t update itself just because the hypervisor did. Each of your Gen2 Hyper-V VMs, your VMware VMs with EFI + Secure Boot, and your cloud marketplace images carries its own copy of the trust store.
On the KVM/QEMU side, the Secure Boot variables live in the OVMF firmware, which means the fix is on the hypervisor: update edk2-ovmf (or your distro’s OVMF package) so newly created VMs get firmware carrying the 2023 certs. Existing VMs may need their NVMRAM template refreshed or the in-guest enrollment run, depending on how your platform wires up per-VM variable stores.
On Hyper-V, there’s a known wrinkle: VMs going through the update have thrown Event ID 1795, and Microsoft scheduled a fix for that earlier in 2026 — so make sure your hosts are current before you push the guest-side update en masse.
The trap that’ll bite you six months from now is golden images. If your base image — the AMI, the VMware template, the Packer output everything clones from — still carries only the 2011 certs, every machine you provision after the deadline is born already behind. Rebake your images with the 2023 chain enrolled and a 2023-signed bootloader. Otherwise you’ve automated the propagation of the exact problem you’re trying to retire.
Self-hosted CI/build runners
This is the one almost nobody’s thinking about, and it’s pure self-inflicted-pain territory if your runners boot with Secure Boot on. Self-managed CI runners — the bare-metal or VM build agents you run for GitHub Actions, GitLab, Jenkins, Buildkite — are typically ephemeral, spun from an image, and completely outside the MDM that’s quietly fixing your laptops. Nothing is managing their Secure Boot state. They inherit whatever the base image had.
So: if your runner images are built on the same stale templates, every fresh runner boots with 2011-only trust, and the day a kernel or shim update assumes the 2023 chain, your builds start failing in ways that look like flaky infrastructure and waste an afternoon to diagnose. The fix folds into the golden-image work above — base your runner images on patched OS images with updated shim/boot components — but it’s a separate inventory line because these hosts don’t show up in your endpoint console. If you don’t run Secure Boot on build agents at all (plenty of teams don’t), you’re fine; just confirm that’s a deliberate choice and not an assumption.
A decision checklist before June 26
Sort your inventory into who-acts-now versus who-can-wait:
- Act now: managed Windows fleet (push the opt-in and verify, don’t wait passively), firmware-password-protected machines (find the OEM update path), TPM/LUKS-encrypted hosts (plan the PCR reseal), golden images and CI runner templates (rebake), and any dual-boot machines you care about.
- Can wait, mostly: consumer/unmanaged Windows PCs that’ll get the managed update over time, and Linux hosts whose only job is to keep booting an already-enrolled shim — though “take the patches anyway” still applies.
- Verify, always:
Confirm-SecureBootUEFIandUEFICA2023Statuson Windows,mokutil --sb-stateandmokutil --dbon Linux. Coverage you can prove beats coverage you assume.
The thing I keep coming back to is that this isn’t really an emergency — it’s a slow-motion maintenance task with one hard date attached and a long tail of edge cases. The machines that bite you won’t be the laptops your MDM is already fixing. They’ll be the unmanaged build runner, the five-year-old appliance with a firmware password nobody remembers, the golden image that quietly keeps cloning 2011 trust into 2027.
Pull your inventory this week. Run Get-SecureBootUEFI -Name DB on a sample of each machine class and see what’s actually enrolled before you trust any dashboard that says you’re covered.