# Windows Secure Boot certificate expiration: What IT teams must do before the deadline ![Author](https://www.manageengine.com/ems/images/tools/employee/raghav-dp.png) **Raghav S** Last Updated: 14 May, 2026 8 Min Read June 2026 is not a soft deadline. The Secure Boot certificate expiration 2026 event marks the end of life for the foundational certificates that underpin boot-level trust on every Windows device deployed before 2025. When these certificates expire, affected endpoints lose the ability to receive Secure Boot security updates permanently. It also shuts down the window for orderly migration. This isn't a routine Windows update. It's a change to the firmware-level trust infrastructure your devices rely on every time they boot. Missing this doesn't mean that you're just behind on a patch. You're leaving your fleet exposed to bootkit malware, third-party software trust failures, and compounding security debt with no clean path back. By the end of this article, you'll understand exactly what's expiring, which systems are affected, and what the consequences look like for organizations that don't act in time. ## What is actually expiring and why it matters To understand the urgency, you need a working map of how Secure Boot's trust chain functions. Secure Boot uses a hierarchy of keys stored in UEFI firmware: - At the top sits the Platform Key (PK), which authorizes the Key Enrollment Key (KEK). - The KEK in turn signs updates to two critical databases: the Allowed Signature Database (DB), which lists trusted boot signatures, and the Forbidden Signature Database (DBX), which blocks known-bad ones. - When a device boots, firmware checks the bootloader's signature against the DB. If it matches and isn't in the DBX, the system proceeds. To understand in detail about these secure boot keys and their chain, you can refer to [Microsoft's documentation](https://techcommunity.microsoft.com/blog/windows-itpro-blog/updating-microsoft-secure-boot-keys/4055324). According to Microsoft's June 2025 advisory, four certificates that anchor this chain are reaching end of life in 2026: | Expiring Certificate | Expiry | Replacement | Location | Purpose | |---|---|---|---|---| | Microsoft Corporation KEK CA 2011 | June 2026 | Microsoft Corporation KEK 2K CA 2023 | KEK | Signs updates to DB and DBX | | Microsoft Corporation UEFI CA 2011 | June 2026 | Microsoft UEFI CA 2023 | DB | Signs third-party OS and hardware driver components | | Microsoft Corporation UEFI CA 2011 | June 2026 | Microsoft Option ROM UEFI CA 2023 | DB | Signs third-party option ROMs | | Microsoft Windows Production PCA 2011 | October 2026 | Windows UEFI CA 2023 | DB | Signs the Windows boot loader | The first three hit the wall in June 2026. The fourth certificate, that directly signs the Windows boot loader itself, follows in October 2026. This is not a routine patch cycle. The migration involves firmware prerequisites, registry triggers, and a staged, multi-reboot process per device. Every endpoint in your fleet is a separate transaction, and the execution involves more than just setting a single registry key. ## Which systems are at risk The scope is broad. Affected systems include: - Windows 10 and Windows 11 on physical hardware - Windows Server 2012 through Windows Server 2025 - Virtual machines running any of the above VMs require emphasis, since they're commonly overlooked in firmware-level security conversations. However, Secure Boot applies equally to virtual machines with UEFI firmware enabled. Hyper-V Generation 2 VMs and VMware VMs with Secure Boot active are in scope alongside physical endpoints. ## What happens if you miss the deadline The consequences of inaction are documented in [Microsoft's support knowledge base (KB5062710)](https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e) and compound over time. This isn't a single event — it's a cascade. - **Loss of Secure Boot update capability:** After June 2026, devices still running the 2011 certificates cannot receive Secure Boot security updates. - **Third-party software trust failures:** Devices without the 2023 certificates may face trust issues with third-party bootloaders and BitLocker hardening. - **No Windows Boot Manager security fixes after October 2026:** After October 2026, devices without the updated certificates will no longer receive security fixes for the Windows Boot Manager. - **BlackLotus / bootkit exposure:** Microsoft has explicitly linked this certificate update to [CVE-2023-24932 (BlackLotus)](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-24932), describing updated certificates as "the latest security measure to address the BlackLotus UEFI bootkit vulnerability." Devices that miss the update lose access to these mitigations. **Note** None of these risks resolve on their own after the deadline. They compound as time passes and remediation options narrow. ## The migration is more than a registry key Understanding the risk is the starting point. Acting on it at fleet scale is a different problem entirely. The migration sequence has hard prerequisites — OEM firmware must be updated in some cases before migrating the certificates. Devices must be running UEFI firmware (not Legacy BIOS), Secure Boot must be enabled, and each device must meet a capability threshold before the migration trigger does anything useful. After triggering, the process requires at least one reboot, often two, with monitoring to confirm completion rather than assuming it. Without a systematic approach, organizations end up with a fragmented migration state: some devices complete, others stalled mid-migration, others never triggered at all — and no reliable view of which is which. For teams managing hundreds or thousands of endpoints, manual execution and point-in-time audits aren't a viable path to the June deadline. This is where a solution like [ManageEngine DEX Manager Plus](https://www.manageengine.com/digital-employee-experience/?utm_source=DEXMP&utm_medium=article-secure-boot) gives fleet-wide visibility into Secure Boot status and certificate migration readiness. It checks and surfaces the list of devices that are eligible for migration, which have prerequisite gaps, and which are already done — without manual querying per endpoint. Its [SecureBoot Upgrade workflow](https://www.manageengine.com/digital-employee-experience/extensions.html?page=secureboot_upgrade) automates the execution sequence: readiness validation, registry trigger, reboot sequencing, error monitoring, and per-device completion confirmation. The result is a live compliance view rather than a guess. ## The deadline is real, and the window is closing June 2026 is months away and the migration process is extensive. With multiple steps like firmware prerequisites, capability checks, registry triggers and reboot coordination, it is a time consuming process. In a real enterprise environment with mixed hardware generations, OEM firmware gaps, and legacy BIOS devices, this deadline becomes pretty tight. [ManageEngine DEX Manager Plus](https://www.manageengine.com/digital-employee-experience/?utm_source=DEXMP&utm_medium=article-secure-boot) gives IT teams fleet-wide Secure Boot visibility and automated migration execution — enabling organizations to discover non-compliant endpoints well before the deadline hits them. ## Meet the author ![Author Image](https://www.manageengine.com/ems/images/tools/employee/raghav-dp.png) ### Raghav S Raghav is a product marketer at ManageEngine, specializing in UEMS. With experience in enterprise marketing and a focus on digital employee experience, he explores how endpoint performance, user experience, and proactive IT help teams resolve issues before they impact users — improving productivity and reducing digital friction.