Your Windows PC has a security deadline in June 2026

A Secure Boot certificate refresh is currently being deployed across supported Windows devices via Windows Update. As we approach June 2026, the Secure Boot certificates that have been integral to Windows since 2011 will begin to expire. In response, Microsoft is introducing a new set of 2023-dated certificates to ensure continued security for users.

The silver lining in this transition is that for most users who keep their PCs updated, minimal action will be required. However, older devices may encounter challenges during this process. While your PC will not cease to function immediately, it may gradually lose access to critical boot-level security protections, potentially leaving it vulnerable without your awareness.

What is Secure Boot, and what’s expiring?

Secure Boot is a feature embedded in the UEFI firmware of nearly every PC sold since around 2012. It operates before Windows begins to load, ensuring that the boot loader and initial boot components are verified as being signed by a trusted entity. If an unauthorized element attempts to infiltrate the boot chain, such as a bootkit, Secure Boot will prevent it from executing.

The essence of this trust lies in cryptographic certificates that are integrated into your motherboard’s firmware. The current certificates, issued in 2011, are nearing their expiration dates. Specifically, three key certificates are involved:

• Microsoft Corporation KEK CA 2011: expires June 24, 2026
• Microsoft UEFI CA 2011: expires June 27, 2026
• Microsoft Windows Production PCA 2011: expires October 19, 2026

In their place, Microsoft will introduce a new set of certificates dated 2023, including the Windows UEFI CA 2023 and Microsoft Corporation KEK 2K CA 2023. According to insights shared by Microsoft engineers during a March 2026 AMA session, these new certificates will remain valid until 2038, with plans for a transition to post-quantum cryptography around 2030 for future hardware.

“Will my computer stop working?”

No, this is a crucial point to understand amidst the swirling rumors. If the deadline arrives and your PC is still operating on the 2011 certificates, Windows will continue to boot, updates will function, and your device will remain operational.

However, the implications of this transition are significant. In Microsoft’s own words, the device “will no longer be able to receive new security protections” for the early boot process. This includes updates to Windows Boot Manager, Secure Boot databases, revocation lists, and mitigations for newly discovered boot-level vulnerabilities.

In simpler terms, while your PC may be safeguarded against current threats, it may become increasingly difficult to protect against emerging risks that could surface in the future. Bootkits, which operate beneath Windows and antivirus software, can disable security measures before they even have a chance to engage.

The BlackLotus problem

A pertinent example of the importance of boot-level security is the BlackLotus bootkit. Emerging on hacking forums in 2022 and confirmed by researchers in early 2023, BlackLotus exploited CVE-2022-21894, known as “Baton Drop,” to bypass Secure Boot on fully patched Windows systems. Once installed, it could disable critical security features like BitLocker and Microsoft Defender before Windows fully loaded.

Although Microsoft addressed the underlying flaw in CVE-2023-24932, rectifying vulnerable boot managers safely remains a complex task. Revoking incorrect boot components can render systems unbootable, prompting Microsoft to implement protections gradually over several years.

The 2026 certificate rollover is a planned lifecycle event, as the expiration of the 2011 certificates was anticipated. However, it also facilitates the broader hardening of Secure Boot in response to vulnerabilities like BlackLotus. With the new trust anchors in place, Microsoft can continue to roll out updated boot components and revoke vulnerable ones as new threats emerge. Devices that do not transition may eventually miss out on these future protections.

How the rollout works

Microsoft has devised a staged rollout strategy to minimize disruption to systems. A scheduled Windows task operates approximately every 12 hours to apply the update in stages:

1. Add the new Windows UEFI CA 2023 to the firmware’s signature database.
2. If the old 2011 third-party certificate remains, add the Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 alongside it.
3. Add the new Microsoft Corporation KEK 2K CA 2023 key.
4. Update the Windows Boot Manager to one signed by the new certificate, with this step deferred until the next natural reboot.

According to Microsoft’s IT guidance, the entire process typically takes around 48 hours and may require one or more restarts to complete. Each step must succeed before the next one can proceed, meaning a device may remain partially through the sequence if it is awaiting a firmware update or scheduled reboot.

For the majority of home users, this transition will occur seamlessly in the background through standard cumulative updates. Starting with the April 2026 Windows update, the Windows Security app will provide updated Secure Boot status information under Device security, indicating whether the new certificates have been successfully applied.

What could go wrong

While most systems are expected to transition smoothly, certain known issues may arise:

• Older PCs with outdated firmware. Some older UEFI firmware implementations may not fully support the new certificates, necessitating a BIOS or firmware update from the manufacturer.
• PCs that bypassed Windows 11 requirements. If Secure Boot was disabled to install Windows 11 through unofficial methods, the new certificates may not be applied correctly.
• Legacy BIOS / CSM systems. Devices utilizing Legacy BIOS (or UEFI with Compatibility Support Module enabled) do not employ Secure Boot, thus falling outside the scope of this update.
• Custom firmware and unusual configurations. Certain custom or atypical firmware setups may trigger a BitLocker recovery prompt following changes to the Secure Boot variables. While BitLocker itself is not being disabled, users should have their recovery keys readily available.

Reports indicate that thousands of PCs with outdated firmware encountered update failures during testing. Microsoft warns that limitations related to firmware, platform, and OEM can hinder the transition. In many cases, Windows Security will alert users with yellow or red status warnings for affected systems.

What home users should do

For the majority of users, the guidance is straightforward:

• Keep Windows fully up to date. Microsoft is distributing the new certificates through regular Windows updates, and most home users will only need to install monthly updates.
• Check your Secure Boot status (the text, not just the color). Navigate to Windows Security > Device security > Secure Boot. A green badge with the text “Secure Boot is on, preventing malicious software from loading when your device starts up.” indicates a successful status. Microsoft cautions that a green checkmark alone does not guarantee the new certificates have been applied.
• If your device is older, check for a BIOS/firmware update from your manufacturer. Some systems may require these updates before the Secure Boot transition can be completed effectively, particularly for PCs manufactured before 2024.
• Don’t disable Secure Boot to “fix” something. Disabling Secure Boot is counterproductive, as it removes protection rather than updating it. Some gaming anti-cheat systems and older applications may request this action.
• Don’t panic about the new SecureBoot folder. The May 2026 cumulative update (KB5089549) creates a folder at C:WindowsSecureBoot containing example PowerShell scripts intended for IT administrators. This is expected behavior and not malware, so there’s no need to delete it.
• Utilize up-to-date, real-time anti-malware protection capable of detecting threats at the OS level, even if some threats manage to bypass Secure Boot.

What IT teams should do

For those managing a fleet of devices, Microsoft has provided extensive guidance, and the process is more involved. Here’s a condensed version:

• Inventory your devices now. Gather details on the manufacturer, model, BIOS version and date, baseboard product, and Secure Boot status across your fleet. Microsoft offers a PowerShell sample script at aka.ms/GetSecureBoot to extract the relevant registry keys and event IDs.
• Monitor Event IDs 1801 and 1808. Event ID 1808 confirms the new certificates are in place, while Event ID 1801 indicates that the device has not completed the update.
• Test before broad rollout. Microsoft recommends testing at least four devices per unique manufacturer/model/firmware combination, as some systems may require an OEM firmware update to accept the new certificates.
• Choose one deployment method per device. Utilize registry keys, Group Policy, WinCS command-line tools, or Intune/ConfigMgr scripts, but avoid mixing methods on the same machine.
• Pay attention to PXE imaging and Hyper-V. SCCM/MECM PXE servers may need a re-signed boot.wim, and Hyper-V hosts may require updates before creating new VMs with the 2023 KEK in the firmware template.
• Document devices that can’t be updated. Older hardware lacking OEM firmware support may need replacement before the deadline or formal acceptance as an exception with compensating controls. While these devices will continue to operate, they may miss future boot-level protections.