Secure Boot Expiration 2026: Risks and Support
In 2026, nothing "visible" to most users changes. The computer turns on, Windows loads, everything seems the same. But underneath, something important changes: the foundation upon which the system decides what to trust at startup.
This isn't a typical update or just another patch. What's expiring are certificates that are part of the boot chain of trust. To put it more simply: the firmware will no longer rely on references that were previously valid.
That doesn't break the equipment, but it does change the verification level. And that kind of change is easy to overlook because it doesn't generate obvious errors.
Secure Boot acts before the operating system has a chance to intervene. It checks digital signatures using keys stored on the platform itself (PK, KEK, db, dbx). As long as these keys are up to date, the filter works. When they become outdated, the system still boots… but with less certainty.
The problem isn't immediate, but rather gradual. The system doesn't become insecure overnight, but it loses its ability to detect modifications to boot components. And that opens up a vulnerability that isn't typically monitored by traditional tools.
What actually changes with the expiration of certificates
The certificates issued in 2011 —as Microsoft Corporation KEK CA 2011 or UEFI CA 2011— they have an expiration date. In this cycle, that limit falls between June and October 2026.
This doesn't mean the system stops working. What happens is more subtle: if those authorities aren't updated, the validation stops relying on a current chain.
Microsoft already considered this scenario with a new authority (2023 Microsoft Windows PCA) which is distributed via Windows Update on compatible computers. Under normal conditions, the process is automatic.
The differences begin with the equipment that is not within that "normal flow": unsupported systems, altered configurations, or firmware that does not easily accept new keys.
There's no clear warning there. The equipment is still working, but the validation is no longer equivalent to what it was before.
Not all teams are in the same situation
At first glance it may seem like a general problem, but in reality it depends quite a lot on the context.
There are cases where it's worth looking at this more closely:
- Equipment that is still in daily use but no longer receives Microsoft updates.
- Systems where Secure Boot is disabled due to previous decisions (compatibility, custom installations).
- Environments where secure boot is part of security control (companies, critical data).
And others where the urgency is considerably lower:
- Old equipment that no longer performs critical functions.
- Isolated systems or systems with very limited use.
It's not that there's no risk in these cases, but the priority changes. Not everything requires immediate intervention.
Check the status: quick and sufficient to decide
Before thinking about changes, the most useful thing is to know where you stand.
With msinfo32In the system summary, you can see the Secure Boot status. That's all you need for an initial assessment.
If it appears enabled and the system receives updates, the transition will most likely occur without intervention.
If it appears disabled or the system no longer updates, then it's worth stopping to think about what to do.
That simple piece of information is usually enough to separate what is normal maintenance from what requires attention.
The decision is not technical, it is operational.
This is where the approach changes. It's not just about knowing how Secure Boot works, but about deciding whether it's worth intervening.
There are clear situations where taking action makes sense:
- Equipment that remains in active use and handles relevant information.
- Configurations where Secure Boot is disabled but could be enabled without breaking compatibility.
- Systems that no longer receive automatic updates.
Conversely, forcing changes to older or non-critical equipment may be unnecessary. Sometimes it's more sensible to keep them isolated or plan for their replacement.
Furthermore, modifying firmware is not a trivial matter. Changing Secure Boot can affect booting if there are incompatible drivers or configurations. It's not complex, but it's also not something to do without checking beforehand.
More than a specific date, this is a checkpoint. If everything is in order, there's no urgency. If it's not, it's best to know before it becomes obvious.
For technical details and specific dates, you can consult the official documentation on the Secure Boot Certificate Expiration and CA Updates.
