Finished reading? Continue your journey in Tech with these hand-picked guides and tutorials.
Boost your workflow with our browser-based tools
Share your expertise with our readers. TrueSolvers accepts in-depth, independently researched articles on technology, AI, and software development from qualified contributors.
TrueSolvers is an independent technology publisher with a professional editorial team. Every article is independently researched, sourced from primary documentation, and cross-checked before publication.
Microsoft's 2011 Secure Boot certificates begin expiring in June 2026 — and the update that replaces them is also the fix for the BlackLotus bootkit, the first malware confirmed to bypass Secure Boot on fully patched Windows 11. Here's what the deadline actually means, why your antivirus can't substitute, and how to verify the update genuinely landed.
Most computer users think of security as software: antivirus programs, firewalls, and Windows Defender catching threats as they arrive. That mental model fails completely at the firmware level. Windows Defender, SmartScreen, and User Account Control all share a fundamental constraint — they only function after Windows has finished loading. A threat that executes before Windows starts is architecturally invisible to every one of them.
Bootkits exploit exactly this window. By embedding themselves in the UEFI boot sequence, they run before the operating system loads a single security component, bypassing OS defenses entirely and remaining hidden to any tool that depends on the OS being in control first. Microsoft's documentation on securing the Windows boot process states directly that bootkits are capable of starting before Windows, completely bypassing OS security, and remaining hidden — and this is not a limitation of any specific product. It is a structural property of how operating system security works.
Secure Boot exists to close this gap. Introduced with Windows 8, it uses cryptographic verification at the firmware level to confirm that each component in the boot sequence is signed by a trusted authority before it is permitted to run. The trust chain flows downward through a hierarchy baked into the device's firmware: the Platform Key (owned by the hardware manufacturer) authorizes the Key Enrollment Key, which in turn authorizes updates to the Signature Database (DB) — the list of trusted boot components — and the Revocation Database (DBX), which blocks known-bad entries.
When a bootkit manages to get past this system, the consequences extend beyond what users typically imagine. When Microsoft investigated the BlackLotus campaign, the company's analysis found that BlackLotus could turn off HVCI, BitLocker, and Microsoft Defender Antivirus by deploying a malicious kernel driver before OS security tools ever initialized. By the time Windows loaded, the attacker's code was already running at kernel level with the ability to disable every software-based defense on the machine.
Microsoft's Secure Boot playbook explicitly describes the 2023 certificates as the security measure for CVE-2023-24932 — the BlackLotus bootkit — which means missing the June 2026 deadline is not a maintenance lag but a permanent inability to apply the specific fix for the first confirmed in-the-wild Secure Boot bypass. The two goals of this certificate transition are inseparable: replacing the aging 2011 infrastructure and closing the attack path that BlackLotus used to exploit it. Coverage that frames this as a routine certificate rotation and coverage that frames it as a security emergency are both missing half the picture.
ESET researchers confirmed that BlackLotus ran successfully on fully patched Windows 11 systems with Secure Boot enabled, exploiting a vulnerability in older signed boot managers that Secure Boot trusted. The underlying vulnerability had been patched over a year before BlackLotus appeared in the wild — but the patch only blocked new, vulnerable binaries. Old boot managers signed with the 2011 certificate infrastructure remained trusted by Secure Boot until Microsoft added their hashes to the DBX revocation list. The 2023 certificate transition, combined with DBX revocations, is what permanently closes that attack path. A device still running on 2011 certificates after June 2026 cannot receive those revocations — not because it loses access to Windows Update in general, but because the trust chain that authorizes boot-security updates specifically expires. The DBX, the Boot Manager, and every future firmware-layer mitigation require the 2023 trust anchor to land.
For most Windows 11 users on supported hardware with automatic updates enabled, the transition happens without intervention. The picture changes for specific groups. Devices running unsupported Windows versions — including Windows 10 without Extended Security Updates enrollment, given that Windows 10 mainstream support ended October 14, 2025 — will not receive the new certificates at all. Those machines will continue to boot and operate after June 2026, but they enter a progressively worsening security position: every new boot-level vulnerability, every updated revocation list, and every future Boot Manager security fix becomes unreachable. The damage is not immediate boot failure — it is a permanently open ceiling at the one layer of the stack where software security tools cannot intervene.
The certificate expiry is one of several significant Windows platform changes arriving in 2026. For context on what else Microsoft is delivering — and what the actual delivery timeline looks like on non-Insider hardware — Windows 11's 2026 performance roadmap is worth understanding alongside the security changes.
The 2011-era Secure Boot infrastructure consists of four certificates with distinct roles. Microsoft's KB5062710 documents the full expiration table: the Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011 both begin expiring in June 2026; the Microsoft Windows Production PCA 2011, which specifically signs the Windows bootloader, expires in October 2026. A fourth certificate — the Microsoft Option ROM UEFI CA 2011, used for option ROM firmware on hardware add-in cards — also expires in June 2026.
Each certificate serves a different layer of the firmware trust chain. The KEK sits above the signature databases and controls who is authorized to make updates to them. The UEFI CA covers third-party boot loaders including the Linux shim that most distributions use on Secure Boot systems. The Windows Production PCA covers the Windows Boot Manager itself. When Microsoft renewed the UEFI CA for 2023, it split the old single certificate into two — one for third-party bootloaders and one for option ROMs — giving system administrators finer control over exactly what their firmware trusts.
A device that hasn't received the 2023 certificates when the 2011 versions expire stops being able to receive updates to any of these components. No updated Windows Boot Manager. No new DBX revocations. No mitigations for boot-level vulnerabilities discovered after the expiry date. The Windows Security app surfaces this status using a badge system that begins rolling out starting May 13, 2026 for Windows 10 and May 16, 2026 for Windows 11. A green badge combined with text that specifically reads "Secure Boot is on and all required certificate updates have been applied" indicates a complete transition — a green badge alone does not.
A green Secure Boot badge in Windows Security and a completed Windows Update and an applied certificate update are three different things — Microsoft's troubleshooting documentation confirms that firmware can reject the certificate write from Windows entirely, leaving the device in a degraded state that looks compliant from inside the OS. This is the failure mode most coverage omits: the Secure Boot certificate update involves two distinct layers, and success at one layer does not guarantee success at the other.
Windows delivers the new certificates through a scheduled task that writes the certificate data to the UEFI firmware's variable databases. If the UEFI firmware on the device hasn't been updated to accept that write — or if the firmware implementation blocks it for compatibility reasons — the task logs the failure and retries every 12 hours. Meanwhile, from inside Windows, Secure Boot appears to be on and functional. The Microsoft Secure Boot playbook documents the specific Event IDs that distinguish between these states: Event ID 1801 in the Windows System Event Log means the certificate update has not yet been applied; Event ID 1795 means Windows attempted the firmware write but the firmware rejected it, typically requiring an OEM firmware update to resolve; Event ID 1808 confirms the update completed successfully. The registry key UEFICA2023Status reading "Updated" is a complementary confirmation.
Open Event Viewer (Windows Logs > System) and filter for source "Microsoft-Windows-UEFI-SecureBoot." Event ID 1808 is what you need. If 1801 appears, the update is pending — keep Windows Update running. If 1795 appears, visit your device manufacturer's support page and check for a BIOS or UEFI firmware update specific to your model. On a custom-built PC, check the motherboard manufacturer's website directly.
One side effect worth knowing about: the April 2026 cumulative updates KB5082063 and KB5083769 triggered BitLocker recovery key prompts on devices with a specific Group Policy configuration that explicitly includes PCR7 in the BitLocker validation profile. Microsoft's troubleshooting guide documents this as a one-time event on most devices: after entering the recovery key, firmware reports the updated Secure Boot values correctly on subsequent boots and the prompt does not recur. This is the security model working as designed, not evidence that something went wrong. If the recovery prompt appears on every reboot, a more specific configuration issue is likely involved — typically PXE (network) boot configured ahead of the local disk.
The risk profile varies significantly depending on hardware age, operating system support status, and boot configuration. Understanding which category applies to your situation determines what action is actually required.
Windows 10 users without Extended Security Updates enrollment face the sharpest exposure. These machines are permanently excluded from the certificate update path and will not receive future DBX revocations or Boot Manager security fixes. This is not immediately catastrophic — the devices continue to function — but they are falling behind an active threat landscape at the one layer where software-based defenses cannot compensate. The scale of this population is not publicly quantified by Microsoft; how that translates to real-world risk depends on factors including hardware age and what targeted threats emerge after June 2026.
Older hardware — particularly consumer systems from 2017 and earlier — faces a different risk: the UEFI firmware may not accept the certificate write even when Windows is current and supported. When Windows attempts the handoff and firmware blocks it, the device remains in a degraded state regardless of what Windows Update reports. OEM firmware updates are the resolution, but for older or budget hardware, those updates may no longer be available. For these systems, the appropriate question is whether a firmware update exists for the specific model — not whether Windows Update has run.
For users on newer hardware running current Windows 11 with automatic updates enabled, the transition is largely automatic. ESET researchers found in January 2025 that CVE-2024-7344 — a Secure Boot bypass discovered in an application signed with the same UEFI CA 2011 certificate now expiring — affected the majority of UEFI-based systems, demonstrating that the 2011 certificate infrastructure continues to be a high-value target for security researchers and attackers alike. Completing the transition to 2023 certificates removes the system from that particular risk surface.
Dual-boot Linux users have a narrower concern. Existing Linux installations that successfully boot today will continue to boot after June 2026 — the certificate expiry affects the ability to sign new boot components, not the ability to run already-trusted ones. The situation that requires attention is updating to a new Linux shim signed with the 2023 certificate: that update should follow, not precede, the Windows-side certificate transition, since the new shim depends on the 2023 certificates being present in the firmware's trusted database before it can boot.
Three conditions determine whether a Windows PC is genuinely protected at the firmware layer as June 2026 approaches. First, the Windows Security app should show a green badge with text confirming that all required certificate updates have been applied — not just that Secure Boot is on. Second, the Windows System Event Log should contain Event ID 1808 for the Secure-Boot-Update task, or the registry key UEFICA2023Status should read "Updated." Third, if the device is running Windows 10, it should be enrolled in the Extended Security Updates program; if it is not, the certificate update will not reach it regardless of other Windows Update activity.
A device that satisfies all three conditions has completed the transition. A device that does not should check for an OEM firmware update before assuming the problem lies with Windows Update. How aggressively Microsoft will enforce DBX revocation of the 2011 certificates beyond their expiry date — and on what timeline — is not definitively specified in current public documentation, but the practical direction is clear: the update path that remains open today will not remain open indefinitely, and the threats that have been targeting the 2011 certificate infrastructure are not going away.
The Windows Security app displays two distinct warning states for Secure Boot certificate status, and they represent different problems. A yellow badge indicates that the automated certificate update is blocked by a hardware or firmware limitation on the device. Windows has attempted the update and cannot complete it without changes to the firmware. The resolution is an OEM firmware update for your specific model, not additional Windows updates. A yellow badge does not mean your device is currently compromised — it means the automated path to completing the transition is blocked and manual firmware intervention is required.
A red badge indicates something more serious: a specific boot-level security vulnerability has been discovered that cannot be patched on your device because it hasn't received the updated certificates. According to Microsoft's guidance on the Windows Security app certificate status, this state could appear as early as June 2026 when the first 2011 certificates begin to expire. The red badge is the more urgent state: it signals that a known vulnerability exists and the mechanism to deliver its mitigation is unavailable on that device.
Not necessarily. The BitLocker recovery prompt that some users encounter after the April 2026 Secure Boot updates appears, in most cases, to reflect expected behavior rather than a failed update. When Secure Boot's trust chain changes — because Windows has switched to the new 2023-signed Windows Boot Manager — the TPM's PCR7 register, which measures Secure Boot state, detects a platform integrity change. If BitLocker is configured to include PCR7 in its validation profile, it treats this as a potential tamper event and requires proof of legitimacy before proceeding. This appears to be the expected behavior of the TPM measurement system responding to a legitimate change in the boot chain.
Microsoft's Secure Boot Troubleshooting Guide documents this as a one-time event on most devices: after entering the recovery key, firmware reports the updated Secure Boot values correctly on subsequent boots and the prompt does not recur. If the recovery prompt appears on every reboot, a more specific configuration issue is likely involved — typically PXE (network) boot configured ahead of the local disk in the firmware boot order, which causes the firmware to measure two different signing chains in a single startup cycle. Changing the boot order to prioritize local storage resolves this scenario.
On custom-built systems, the UEFI firmware lives on the motherboard, and updates come from the motherboard manufacturer — not from Microsoft or Windows Update. Locate your motherboard's exact model and revision number (usually printed on the board itself or visible in BIOS settings) and visit the manufacturer's support page to find the latest UEFI firmware download for that specific model.
Before flashing a firmware update, back up your BitLocker recovery key if BitLocker is enabled — firmware updates change PCR measurements and will trigger a recovery event on the first reboot afterward. Follow the manufacturer's flashing instructions precisely; an interrupted firmware flash can require a hardware recovery procedure. After the firmware update is applied and the system reboots cleanly, the Microsoft Secure Boot playbook recommends confirming success by checking the Windows System Event Log for Event ID 1808 — this confirms that Windows has successfully written the 2023 certificates into the updated firmware. If Event ID 1795 appears instead, it means the firmware update did not resolve the compatibility issue and further OEM guidance is required.