Secure Boot Certs Expire June 2026: IT Prep for Windows

7 min read

Starting in June 2026, Microsoft’s Secure Boot certificates issued in 2011 will expire. Windows devices that haven’t installed the 2023 certificate update will no longer be able to apply new Secure Boot updates and will lose trust in newly signed third-party software. IT teams have roughly two months left to complete inventory assessments, testing, and deployment. Those who wait until June to begin will be too late.

Key Takeaways

• Microsoft has announced the retirement of Secure Boot certificates in use since 2011, effective June 2026. The validity of the Microsoft Corporation KEK CA 2011, Microsoft Windows Production PCA 2011, and Microsoft Corporation UEFI CA 2011 certificates will expire in stages between June and October 2026.
• Devices without the updated 2023 certificates will be unable to install new Secure Boot updates after expiration and will no longer trust third-party software signed after the cutoff date.
• Windows PCs shipped since early 2024 already include the 2023 certificates preinstalled. All older devices must be actively updated.
• Status verification is done via a registry entry: UEFICA2023Status must be set to “updated.” Microsoft provides PowerShell commands for inventory checks (aka.ms/GetSecureBoot).
• Older hardware lacking OEM firmware support may never receive the update. For these devices, organizations face a risk assessment-or replacement.

What Specifically Expires in June 2026

Secure Boot is a UEFI mechanism that verifies at system startup whether the loaded firmware, bootloader, and operating system originate from a trusted source. This chain of trust relies on cryptographic signatures issued by so-called Certificate Authorities (CAs). In 2011, Microsoft established three central CAs: the Microsoft Corporation KEK CA 2011 for the Key Exchange Key database, the Microsoft Windows Production PCA 2011 for signed Windows components, and the Microsoft Corporation UEFI CA 2011 for third-party software.

These three certificates will expire starting in June 2026. The transition isn’t an abrupt failure but a phased process extending through October 2026. Microsoft introduced their successors in 2023 and has been gradually deploying them to existing devices via Windows Updates. PCs shipped since early 2024 include the 2023 CAs preinstalled-a strategic advantage for organizations with newer hardware fleets, but a risk for all others.

The change is driven by both technical and regulatory considerations. The 2011 certificates date from an era when SHA-1 was still widely used and Secure Boot involved far fewer manufacturers than today. By migrating to the 2023 CAs, Microsoft aligns its cryptographic practices with current standards and shortens certificate lifetimes to a duration better suited for production environments.

Which Devices Are Affected

The simple rule is this: anything produced before 2024 requires an active update. In practice, this affects the majority of devices in a typical enterprise, as the average laptop lifespan ranges from four to six years-and desktops often remain in service even longer. Servers are also impacted, though virtualization hosts and VMs are handled differently.

Physical Windows devices receive the 2023 certificates through standard Windows Update channels. However, deployment isn’t automatic in the sense that “every computer is guaranteed to get it.” Microsoft rolls out updates in phases. Certain device classes are still awaiting OEM approvals. Dell, HP, Lenovo, and Fujitsu each follow different timelines for firmware updates that embed the CA changes at the hardware level. IT teams must verify the status per device model and cannot assume Windows Update alone will resolve the issue.

Virtual machines represent a special case. Hyper-V, VMware, and KVM all support Secure Boot, but certificate updates here are managed through virtualized firmware-not the guest operating system. VMware has published guidance for transitioning vSphere environments, while Microsoft delivers Hyper-V updates via host patches. For Linux-based KVM environments, the process is more complex and often requires manual intervention on each VM host.

Particularly tricky are older devices that have reached end-of-service from the OEM’s perspective. For such hardware, there may no longer be compatible firmware available that anchors the 2023 CAs. Microsoft and manufacturers likely won’t support all legacy devices. In an analysis published in late March 2026, XDA Developers noted that some pre-2020 Windows PCs probably won’t ever receive the fix. For IT teams, this means those devices should be inventoried, prioritized, and either replaced early or operated in isolated network segments with reduced privileges.

The Inventory Check: PowerShell and Registry

Good news for IT teams: a device’s status can be verified with minimal effort. Microsoft provides two methods. The first is a registry entry located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\UEFICA2023Status. This entry should ultimately read “updated.” Other values, such as “NotStarted” or “InProgress,” indicate that deployment is still underway.

The second method is a PowerShell query published by Microsoft on its Tech Community blog. It lists the currently installed Secure Boot database entries and enables automated comparison against the desired state. For fleet-wide inventory, combining this approach with Microsoft Intune, Configuration Manager, or a comparable endpoint management tool-capable of querying the registry value across all devices-is strongly recommended. Manually checking hundreds of devices is simply impractical.

It’s crucial to distinguish between “certificate installed” and “certificate active.” A device might have the 2023 certificate present in its UEFI database without actually using it. Only when the status shows “updated” and the firmware actively uses the 2023 CAs to validate bootloaders is the device truly prepared. Completing the full transition typically requires multiple reboots and, in some cases, manual UEFI configuration. Therefore, IT teams should thoroughly test the process on a small set of pilot devices per model before launching a fleet-wide rollout.

The Update Process in Four Steps

Microsoft recommends a structured approach that IT teams can implement over the next six to eight weeks. The process consists of four sequential steps that build logically on one another and cannot be run in parallel:

What Happens If the Update Isn’t Applied in Time

The consequences of missing this update aren’t catastrophic in the sense of a total system failure, but they are technically inconvenient and organizationally burdensome. Windows devices without the 2023 CAs remain functional-they continue to boot, can be operated normally, and run applications. However, two key changes occur.

First: New Secure Boot revisions released by Microsoft after the cutoff date will no longer be trusted for installation. This primarily affects updates designed to counter emerging classes of boot-level malware, such as BlackLotus or CoSign-based attacks. Devices without the update gradually lose protection against threats targeting the Secure Boot chain. While not an immediate danger, this represents a slowly growing risk.

Second: Third-party software signed with the new 2023 CAs after the cutoff date will no longer be recognized as trustworthy by older devices. This includes Linux bootloaders like Shim and GRUB, which are frequently re-signed, as well as specialized security tools that include their own kernel components. IT teams managing mixed environments or specialized applications will encounter issues very quickly.

From a compliance standpoint, this matters because regulations like the EU’s NIS2 Directive and standards such as ISO/IEC 27001 require up-to-date security patches and robust vulnerability management. Auditors reviewing endpoint security architecture will not overlook questions about Secure Boot certificate status. Organizations unable to demonstrate a documented, compliant state risk not only technical complications but also regulatory non-compliance.

Special Case: Linux Dual-Boot and RHEL Environments

Organizations running Linux environments or dual-boot devices must account for an additional step. Red Hat published official guidance for RHEL environments in early 2026 outlining the transition to the 2023 CAs. The key point: the Red Hat Shim bootloader is signed by Microsoft using the UEFI CA 2011. Once this CA expires, RHEL and Fedora systems on non-updated devices will no longer boot securely. Red Hat provides new Shim versions signed with the UEFI CA 2023-but these require the corresponding CA to already be present on the target device.

For dual-boot devices running both Windows and Linux, this creates a clear sequence of actions. First, Windows must install the 2023 CAs via its update mechanism. Next, the UEFI firmware must anchor these new CAs into the trust chain. Only then can a RHEL or Fedora Shim signed with the 2023 CA boot successfully. Reversing this order won’t work-a failed update could render the Linux partition unbootable. Affected teams should defer RHEL updates until the Windows-side transition is complete.

Six-Point Checklist for IT Teams

For the remaining weeks until June 2026, six concrete action steps can be prioritized:

1. Begin inventory. Use centralized endpoint management to check all Windows devices for UEFICA2023 compliance. Document results in an Excel list or dashboard, categorized by device class and location.
2. Verify firmware updates. For each device class, contact the manufacturer to confirm whether current BIOS versions support the 2023 certificate authorities (CAs). Dell, HP, Lenovo, and Fujitsu have published support articles listing compatible firmware versions.
3. Set up a pilot. Update five to ten devices per model in a pilot group, verify status, and document any issues. Reserve a timeframe through the end of April.
4. Create a rollout plan. Divide the fleet-wide deployment into two or three waves, coordinating with operations and business units. Define weekly targets rather than daily ones, and allocate buffer time for unexpected issues.
5. Coordinate with Linux and virtualization environments. Consult with Linux administrators and virtualization teams to determine if dependent systems are affected. Establish an update sequence and create backward-compatible snapshots.
6. Maintain a risk list for legacy devices. Document separately all devices without available fixes. Options include replacement, network isolation, or reducing the attack surface via restrictive software whitelists. Secure executive approval at the CISO level.

Conclusion

The Secure Boot transition isn’t a regulatory requirement with a vague deadline-it’s a hard technical cutoff with a fixed date. Organizations that complete the update by June 2026 won’t face immediate disruption. Those who miss the deadline will be left with devices that gradually stop trusting new Secure Boot updates and newly signed software-precisely at a time when boot-level attacks from groups like BlackLotus are on the rise.

The work is manageable, but it demands priority. Taking inventory is the most critical first step, as it forms the foundation for every subsequent decision. After that comes a structured rollout that clearly separates pilot, testing, and production phases. For IT teams, this means: start the inventory this week, deploy pilot devices next week, update all standard devices by end of April, and tackle edge cases in May. Teams that stick to this plan will enjoy a stress-free June.

Frequently Asked Questions

Can we deploy the update centrally via Intune or Configuration Manager?

Yes, both tools support deployment. Microsoft provides specific deployment rings distributed through Windows Update for Business or WSUS. Intune also offers compliance policies that monitor UEFICA2023Status and trigger alerts if deviations are detected. For Configuration Manager, Microsoft recommends combining an inventory task sequence with automated rollouts per device group. Manual intervention is only required for devices with custom UEFI settings or locked firmware.

What happens to devices that already have Secure Boot disabled?

For devices where Secure Boot was disabled for compatibility reasons, nothing changes in the short term. The expiring certificates only affect active Secure Boot functionality. However, IT teams shouldn’t consider these devices “done.” Disabling Secure Boot poses a security risk that should no longer be acceptable by 2026. The certificate transition is therefore an ideal opportunity to audit existing Secure Boot deactivations and re-enable them wherever possible.

How can I tell whether my hardware vendor still provides the update?

The easiest source is the manufacturer’s support website. Dell, HP, Lenovo, and Fujitsu have published lists of supported devices. For devices not listed there, contact the vendor’s support team directly. If even that inquiry yields no positive response, the device is considered end-of-service from the OEM’s perspective and will no longer receive the fix. Microsoft also maintains a dedicated landing page at aka.ms/GetSecureBoot featuring a collection of tools and vendor references.

What does this mean for our virtualization environment?

Hyper-V VMs on Windows Server receive the update automatically via host patches. VMware vSphere requires ESXi firmware updates provided directly by VMware. KVM-based environments on Linux hosts are more complex, as the OVMF firmware must be updated separately. For production virtualization platforms, we recommend a separate rollout wave ahead of the deadline, distinct from client updates. Using test VMs as pilots helps identify edge cases early.

Is there a way to force the update if Windows Update doesn’t offer it?

Microsoft rolls out the 2023 CAs gradually to avoid overloading production systems. A manual override is possible using the registry key MicrosoftUpdateManagedOptIn, which accelerates rollout for a specific device. Set the value to 0x5944 for individual pilot devices. This method is primarily useful for dedicated test machines and compliance audits-not for broad-scale deployment.

Will the deadline be extended?

Microsoft has not announced any extension and, on the contrary, signaled through its playbook publication that the deadline is firm. Planning should therefore strictly target the June cutoff date. Even if Microsoft were to introduce a grace period at the last minute, the benefits of completing the rollout on time are significant enough that teams shouldn’t rely on potential leniency. Treat the deadline as fixed.

Source, cover image: Pexels / panumas nikhomkhai

About the author: Tobias Massow

More articles by Tobias Massow