Secure Boot expired in June and nothing broke. That is the problem

On 24 June and 27 June, two certificates that had underpinned secure boot on practically every x86 PC and server in the world since 2011 expired. Absolutely nothing happened. Not one machine failed to start, not one ticket, not one phone call. Which is why, six weeks later, hardly anyone has looked at it. And the awkward part is that nothing happening was exactly the plan: this change does not fail by switching machines off, it fails by quietly no longer protecting the ones that stay on.

We are writing this from the side that maintains other people's estates. We look after client Windows machines, our own Linux servers and virtual machines on Proxmox VE with Ceph storage, and all three eat from the same trust tree. And the question is not theoretical: a freshly delivered laptop can arrive without the new certificate, because that is decided by the firmware the vendor shipped, not by the date on the invoice. This article is what we put in order to answer it across a whole estate — with the exact commands, and with the part almost no coverage mentions: virtual machine templates.

Three certificates, three dates, three different things

The first thing worth undoing is the headline. "Secure Boot" is not expiring: three specific certificates are, each with its own date and its own job, and conflating them is why a lot of people have filed this away as solved. Per Microsoft's own documentation:

• Microsoft Corporation KEK CA 2011 — expired on 24 June 2026. It signs updates to the DB and DBX databases. Replaced by Microsoft Corporation KEK 2K CA 2023.
• Microsoft UEFI CA 2011 — expired on 27 June 2026. It signs third-party boot loaders and option ROMs; in other words, Linux booting and the firmware of a great many cards. Replaced by Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023.
• Microsoft Windows Production PCA 2011 — expires on 19 October 2026. It signs the Windows boot loader. Replaced by Windows UEFI CA 2023. That date has not arrived yet: seventy-two days from the day we publish this.

The correct mental model fits in one sentence: an expired certificate does not invalidate what it already signed. Everything already signed still validates and still boots. What ends is the ability to sign new things. Get that distinction straight and the rest of this article is arithmetic.

What does not happen, and why that is worse

Microsoft says it flatly, and it deserves quoting in full because it is the reassuring half: if your device reaches the expiration date without the new certificates, it "will still start and operate normally", and Windows updates will keep installing. Nobody is left unable to boot. Anyone selling you the opposite panic is selling you something else.

The other half is the one that matters, and it comes from the same page: those devices "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". Translated into estate terms: the day the next bootkit shows up and Microsoft publishes a DBX revocation, those machines will not get it. Not because they fail, but because nobody can sign the delivery for them any more.

Here is our opinion, and it is an uncomfortable one for the trade: an expiry that breaks nothing is operationally worse than one that breaks something. Had a third of all laptops failed to start on 24 June, it would have been fixed across Spain by Thursday the 25th. Because nothing fell over, there is no ticket to kick off the work, no user to complain, and — this is the part that is hard to admit — no standard monitoring template that watches whether a machine's DB contains a particular string. We monitor plenty, and with judgement, and this was not there. It is a check that now belongs in the template.

It is the same pattern we wrote about this very week over two kernel flaws: the advisory tells you the problem exists, not whether your particular machine has already dealt with it. The difference is that there, uname -r was enough. Here you have to go and ask the firmware.

Two minutes on a Windows box

In PowerShell as an administrator. You read the UEFI variable and look for the certificate name inside it. It returns True or False, no ambiguity:

Confirm-SecureBootUEFI

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Windows UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Microsoft UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Microsoft Option ROM UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

The first line confirms Secure Boot is on; if it returns False, the next four are moot and you have a different conversation pending. The other four are the ones that count: four True results are a pass. A False on the KEK marks the future, not the present: Microsoft applies the DB certificates before the KEK, authorised by the 2011 KEK the machine already holds, so that box can still receive the update. What it will not receive are the next ones: the KEK 2K CA 2023 has to be authorised by the vendor's Platform Key — at that point it is your hardware supplier deciding, not Microsoft.

To see it at scale rather than machine by machine, the state lives in the registry under the HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing subkey: the UEFICA2023Status value moves from NotStarted to InProgress and ends at Updated, with any failure code left in UEFICA2023Error. Mind the path, because it is not the same one as in the next section: the switches hang off SecureBoot and the state off SecureBoot\Servicing. That is an inventory, and an inventory can be collected from whatever management tool you already run without touching a single machine.

The managed-estate switch (and how not to use it)

On IT-managed devices the rollout does not happen by itself: you have to ask for it. Microsoft documents two values under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot. AvailableUpdates set to 0x5944 tells Windows to run the key update and, on top of that, to install the boot manager signed with Windows UEFI CA 2023. MicrosoftUpdateManagedOptIn set to 1 hands the rollout to Microsoft — and the value alone is not enough, because Microsoft also requires that the device be allowed to send required diagnostic data: in an estate with telemetry blocked by policy, the switch does nothing. The scheduled task \Microsoft\Windows\PI\Secure-Boot-Update runs every twelve hours and clears the bits of 0x5944 as it completes each one; kicking off the deployment does not force a restart, though one may be needed to finish.

And now the advice that cuts against temptation: you do not push that value to a whole estate at once. You are writing into the UEFI variables of machines from several manufacturers, some running years-old firmware. The order we follow is boring and it works: measure first, then vendor firmware on the models that need it, then a pilot ring per hardware model — not per department, because what varies here is the board — and only then the rest. A silent rollout that broke nothing in June does not deserve to be turned noisy by you in August.

Your Linux servers eat from the same certificate

This is the point that falls out of almost every write-up, because they were all written from the desktop. The shim — the small loader that lets Linux boot with Secure Boot enabled — is signed by Microsoft with the Microsoft UEFI CA 2011, the one that expired on 27 June. A machine with Secure Boot off does not even notice. What gets hard is deploying new shims signed only with the 2011 key onto machines that cannot receive UEFI database updates.

The distributions moved early. Red Hat shipped shims signed with both keys, 2011 and 2023, so they boot whether the machine has one or the other enrolled: shim-x64 16.1-4 on RHEL 10, 16.1-7 on RHEL 9 and 16.1-2 on RHEL 8. To find out where you stand, three commands:

mokutil --sb-state                          # is Secure Boot enabled?
mokutil --db | grep -A13 "\[key"            # which certificates are in the database
pesign -S -i /boot/efi/EFI/redhat/shimx64.efi   # which keys your shim is signed with

And a warning we endorse word for word: Red Hat explicitly asks you not to force-install db updates and to always follow vendor guidance. On HP and Fujitsu machines you need the full firmware update before touching the database separately; the supported path is usually fwupdmgr update, not a hand-written variable. Poking certificates into a UEFI variable by hand is exactly the kind of shortcut that works ninety-nine times.

The one nobody looks at: your virtual machines

A UEFI-booting virtual machine has its own DB and KEK too. They do not live on a board: they live in a file, the EFI disk, created from a hypervisor template. And that is where the fundamental difference from physical hardware shows up: an old board falls behind once; an old template falls behind every time you clone it. Red Hat's own guidance says it in a line hardly anyone has quoted: update the edk2-ovmf package on your hypervisors so new virtual machines inherit the updated certificates.

On Proxmox VE, which is what we run daily, the default EFI variables template includes the 2023 certificates from pve-edk2-firmware 4.2025.05-1 onwards. EFI disks created before that carry only the 2011 ones, and they do not update themselves. Proxmox VE 9.2, released on 21 May 2026, added a check on every boot of a virtual machine with pre-enrolled keys, and the warning is literal: WARN: EFI disk without 'ms-cert=2023k' option, suggesting that not all UEFI 2023 certificates from Microsoft are enrolled yet. To fix an existing machine, with the VM shut down:

qm enroll-efi-keys <vmid>

Proxmox's documentation describes the command as enrolling "important updated certificates to the EFI disk with pre-enrolled-keys — currently, these are UEFI 2023 certificates from Microsoft", and warns it must be run with the VM shut down. Here comes the part you only learn from a scar, and it is not ours but Proxmox's: in November 2025 they tried to enrol the new certificate automatically on the next start of affected Windows VMs (qemu-server 9.0.28). They had to back it out because the change sent Windows 11 virtual machines to the BitLocker recovery screen. Since then the operation is manual and explicit.

So the order in a virtualised environment is this one and no other: have the BitLocker recovery key to hand before running anything, temporarily disable the protectors with manage-bde -protectors -disable C: — they re-enable themselves on the next reboot — and only then enrol. And fix the template first. If you start with existing machines while your golden template keeps minting 2011-era EFI disks, you are bailing water with the hose still running. We maintain Windows and Linux provisioning templates for clients, and that is the place to start.

When this is not your problem

Two cases, and we say them because honesty saves work. First: if you have Secure Boot disabled, none of this affects you. That is not good news — it means you have gone years without the protection this article is about — but you have no urgency this week. The second is more awkward: some machines are never going to receive this. Microsoft notes that certain systems require vendor firmware updates, and if that vendor never publishes a version carrying the 2023 certificates for a 2016 model, no amount of patching fixes it. That stops being a maintenance conversation and becomes a replacement one, with its own budget and calendar.

It is the same hole we described writing about exposed BMCs and IPMIs: firmware is the layer nobody has inventoried, nobody monitors and nobody has in the contract. And that layer has just acquired an expiry date. If you also have Windows 10 in the estate, this is not the only clock running this autumn: the ESU toll also falls due in October, and both decisions are best taken by the same person on the same day, because the answer may well be the same machine.

What we would do this week

• Measure, do not assume. The four PowerShell lines on a sample of each hardware model, and UEFICA2023Status collected from your management tool for the rest. Without that number there is no conversation to have with the client.
• Vendor firmware first on the models that require it, following their guidance and without forcing hand-written UEFI variables.
• Pilot ring per board model, not per department. And read the status afterwards — that is what it is there for.
• VM templates first, existing VMs afterwards, with the BitLocker recovery key in front of you and the protectors disabled during the operation.

None of this is hard. It is, once again, work that does not show: inventory, a window, and somebody who reads the vendor documentation to the end. It is exactly what we do when we take on a company's digital workplace and its day-to-day operations, and it is the kind of task that only shows up on the invoice for the month when nothing happened. If you would like us to tell you how many machines in your estate already carry the 2023 certificates — and how many never will — get in touch.

And the question we close on, which is the one we asked ourselves: if an urgent revocation for a bootkit is published tomorrow, how many of your machines could receive it? Not how many are patched. How many can be.