Secure Boot certificates expire this year and the fleet has not noticed
Fifteen year old certificates, staged expiry from June, and a failure mode that does not announce itself at boot.
The certificates underpinning Secure Boot on Windows were issued in 2011. Certificates expire, and these are now doing so in stages between June and October 2026.
This one is unusual in how quietly it fails, which is why it is worth attention it is not getting.
What is expiring
Three certificates matter: the Microsoft Corporation KEK CA 2011, the Microsoft Windows Production PCA 2011, and the Microsoft Corporation UEFI CA 2011. They sit in device firmware and establish what the machine trusts at boot.
The affected population is essentially everything: physical machines and virtual machines across Windows 10, Windows 11, and Windows Server from 2012 through 2025, including LTSC builds.
What actually happens, and what does not
This is the part that gets reported badly, so it is worth being precise.
Machines will not stop booting. A device with the 2011 UEFI CA already enrolled continues to boot after the expiry. The expiry affects the ability to sign new binaries, not the validity of ones already trusted.
What breaks is the future. A device that has not received the 2023 certificate update can no longer apply new Secure Boot updates, and loses trust in newly signed third party components. The machine works today and slowly becomes unable to accept anything new.
That is a much worse failure shape than a machine that will not start. A machine that will not start gets fixed on Monday. A machine that silently stops accepting updates gets discovered in an audit eighteen months later, by which point it is a fleet wide problem with no single moment to point at.
The remediation
Get the 2023 CAs onto devices before the 2011 CAs expire. For most estates the supported route is letting Microsoft manage the Windows updates that carry the certificate changes, and hardware manufactured since 2024 largely ships with the 2023 certificates already present.
The complications are where they always are. Devices that have been offline for long periods. Machines on restricted update rings. Virtual machines with firmware templates that were built once and cloned since. Anything where firmware updates are controlled separately from Windows updates.
How I am approaching it
Three questions, in order:
- Which devices already have the 2023 certificates? This is a reporting problem before it is a remediation problem, and the answer partitions the fleet into the part you can stop worrying about and the part you cannot.
- Which devices cannot receive them through the normal update path? Restricted rings, air gapped machines, appliances, anything where firmware is vendor controlled. These need individual plans and they are the ones that will still be outstanding in December.
- Which devices are being retired anyway? A Windows 10 machine due for replacement before its ESU coverage ends does not need this work. The Secure Boot timeline and the Windows 10 timeline overlap, and treating them as one refresh decision rather than two projects saves real effort.
Why it is being missed
No user reports it. There is no ticket, no error dialog, no failed login. It produces nothing that shows up in the queue, which means it competes for attention against things that do, and loses every week.
The problems that reach you are not the important ones. They are the ones with a symptom.
Root of trust expiry has no symptom until it does. That is the argument for scheduling the work rather than waiting for it to become visible.