Secure Boot certificates expire in June 2026 – What you need to know now
In June 2026, an entire generation of Secure Boot certificates will expire for the first time after more than 15 years. What may sound like a minor technical issue affects virtually every Windows device shipped since 2012—and could, if no appropriate precautions are taken, result in systems continuing to boot up but remaining permanently stuck at the 2011 security level.
What is it about?
Secure Boot ensures that only trusted, digitally signed software is executed when a computer starts up. The chain of trust is based on certificates stored in the UEFI firmware memory. Three of these certificates date back to 2011 and are now expiring in stages:
- Microsoft Corporation KEK CA 2011 (June 24, 2026)
- Microsoft Corporation UEFI CA 2011 (June 27, 2026)
- Microsoft Windows Production PCA 2011 (October 19, 2026)
The 2023 certificates are ready to take their place, and Microsoft has been rolling them out gradually via Windows Updates since 2024. Devices manufactured since 2024 often come with them pre-installed.
What happens if a device does not receive the new certificates?
There is often confusion about this—so let’s start with the most important clarification: Simply letting a certificate expire does not cause a boot error. During startup, UEFI Secure Boot simply checks whether a signature is listed in the allowed database (DB) and not in the blacklist (DBX). Expiration dates are irrelevant in this process.
As long as the Microsoft UEFI CA 2011 remains in the database and has not been added to the DBX file, Windows will continue to boot normally even after June 2026.
The real problem lies elsewhere. Microsoft puts it this way:
Devices that haven’t received the newer 2023 certificates will continue to start and operate normally, but will no longer be able to receive new security protections for the early boot process.
Specifically, this means for devices that haven’t been updated:
- No more DBX updates – the blocklist targeting known bootkits such as BlackLotus (CVE-2023-24932) remains frozen.
- No new boot manager signatures – security vulnerabilities in the bootloader can no longer be patched.
- No trust in newly signed third-party software, if it was signed with the 2023 certificates.
Microsoft refers to this as a “degraded security state”—the system is still running, but it is permanently out of date in terms of security and no longer compliant in regulated environments.
And the DBX lock on the old certificates?
A valid concern: Will Microsoft eventually actively block the old 2011 certificates via DBX—and thereby cause boot bricks? Answer: Yes, but with a deliberate delay. Microsoft strictly separates these two steps:
- First rollout of the 2023 certificates.
- Only then (and only if the telemetry shows sufficient coverage) the DBX lock on the 2011 model.
There is currently no fixed deadline for the DBX rollback. However, this is a critical point for unprepared devices: as soon as the 2011 CA is added to the DBX and there is no 2023 CA stored in the UEFI, the system will no longer boot.
For all experienced readers—our step-by-step guide shows exactly what you should do next
Microsoft Microsoft has published its own Secure Boot Playbook for the 2026 certificate renewal. Here is an overview of the key steps:
1. Take inventory
Before the certificate status of individual devices can be checked, a more fundamental question must be answered: What devices does the company actually have? In practice, many organizations lack a complete overview of their inventory—legacy devices, home office laptops, production machinery, or forgotten systems at remote locations do not appear clearly in any inventory. It is precisely these blind spots that are critical: A device that IT is unaware of cannot be checked for its Secure Boot status or provided with the new 2023 certificates.
The first step, therefore, is reliable inventory tracking—the automatic detection of all devices on the network. A complete hardware inventory is not just a “nice-to-have,” but an essential prerequisite for a comprehensive rollout. Anyone who leaves gaps in this process risks having devices overlooked during a subsequent DBX lockdown, which would then prevent them from booting up.
Then check across the entire company:
- Is Secure Boot even enabled?
- What is the value of the
UEFICA2023Statusregistry key? The expected value isUpdated. - Is there a
UEFICA2023Error-key? If so, there is an error.
In the next part of this blog series, we’ll show you how to use Ivanti Neurons and Ivanti Endpoint Manager to specifically collect, process, and analyze these and other relevant metrics.
2. OEM firmware updates first
This is the point that is often overlooked: Windows-side certificate delivery can only work if the UEFI is ready to accept them. OEM BIOS/firmware updates take precedence over Windows certificate updates. HP, Lenovo, Dell, and others provide the necessary updates.
3. Pilot rollout
Select a small, representative group of devices—especially those with unusual hardware—and test the update process before rolling it out to the entire fleet.
4. Verification
Success can be measured in two ways:
- Event ID 1808 in the System Event Log – Update successfully applied.
- Event ID 1801 – error during application
UEFICA2023Status=Updated
Important: Secure Boot must be enabled
One detail that is often overlooked: Windows can only write DB/DBX updates to the firmware if Secure Boot is enabled. On devices where Secure Boot was disabled from the start and remains disabled, this certificate update simply never takes place. This is initially not critical during normal operation: With Secure Boot disabled, the firmware checks neither DB nor DBX at startup, so the system boots regardless of the certificate status.
The real problem arises only when you want to enable Secure Boot at a later date, for example because it is required for Windows 11, BitLocker, certain compliance requirements, or security features. This is exactly where a chicken-and-egg situation arises.
The bootloader on the disk is still signed with the old Microsoft UEFI CA 2011 certificate because the update was never installed. If the 2011 certificate had already been added to the DBX (blocklist) at that time, the firmware will reject this signature when Secure Boot is enabled. The device will then no longer boot and, in the worst case, will immediately encounter a Secure Boot violation error or enter recovery mode.
The solution is not simply to disable Secure Boot again and leave it at that, but to update the trust chain retroactively before the DBX lock takes effect. Specifically, for such devices, Secure Boot should be enabled in a timely manner, while the 2011 certificate is still valid, so that Windows can download the 2023 certificates and a currently signed boot manager during operation. Only then is the device protected against the subsequent DBX revocation.
The key takeaway for this group of devices is therefore: If you leave Secure Boot permanently disabled, you are merely postponing the problem—and risking that enabling it later, after the DBX revocation, will result in a system that can no longer boot, because the firmware will then consistently reject the old, locked bootloader.
Conclusion
The 2026 certificate renewal is the first global “Chain of Trust” renewal since the introduction of Secure Boot—and it is proceeding at a deliberately gradual, telemetry-driven pace. On well-maintained Windows 11 clients, most of this process runs automatically in the background. The critical points are:
- Windows Server (no automatic rollout – manual action required)
- Devices with outdated OEM firmware
- Offline/air-gapped systems
- Systems on which Secure Boot is disabled
This is precisely where the real challenge lies: you need to know which devices in your environment have already received the 2023 certificates, which ones still have the old version of the boot manager, and where Secure Boot is even enabled. Without reliable reporting, you’re left in the dark—and you won’t discover non-bootable systems until the DBX revocation has already taken effect.
In the next part of this series, we’ll show you how to use our Ivanti tools to achieve exactly this level of transparency: from comprehensive reporting on certificate and Secure Boot status to the controlled, secure rollout of new certificates – ensuring that no device is left behind.
Do you have any questions? Just get in touch—we’ll take care of it.
Never miss news again?
