Secure Boot Certificate Rollover 2026: Plan Now to Safeguard UEFI Boot

Microsoft has warned that the cryptographic roots underpinning UEFI Secure Boot on Windows devices will begin to expire in June 2026, forcing a global certificate update that every IT team and many end users must plan for now to avoid boot-level insecurities and loss of updateability.

Background / Overview​

Secure Boot is the firmware-level trust anchor that helps ensure a PC boots only with code signed by a trusted authority. For more than a decade, Windows systems shipped with a set of Microsoft-managed certificate authorities (CAs) stored in UEFI variables (KEK, DB, DBX). Those certificate authorities have finite lifetimes, and Microsoft has announced that the certificates introduced in 2011 will start expiring in June 2026. That expiration affects the ability of affected systems to accept future Secure Boot updates and to receive fixes for pre-boot components, including the Windows Boot Manager.
This is a planned, large-scale key rollover: Microsoft and OEM partners will distribute newer 2023-suffixed CAs (for example, KEK CA 2023, Windows UEFI CA 2023, and UEFI CA 2023 variants) to replace the 2011-era certificates. The process requires coordination between firmware vendors (OEMs), Microsoft, and device operators to ensure keys are added to the platform databases in the right order and that firmware and recovery components are compatible with the new signing certificates.
Key dates you must note now:

• June 2026 — Major Secure Boot CAs (KEK CA 2011 and Microsoft UEFI CA 2011) begin expiring.
• October 2026 — Additional expiry for the Windows Production PCA 2011 (affecting the Windows bootloader signature trust) becomes critical.

These expirations mean that, if a device still only trusts 2011-era certificates after those dates, it may no longer receive Secure Boot updates or trust components signed with the new certificates — in short, that device risks being left exposed to boot-time attacks and unable to receive fixes for pre-boot components.

---

What is expiring and why it matters​

The certificates and where they sit​

Secure Boot uses a small number of certificate authorities kept in UEFI variables. The important roles are:

• Platform Key (PK) — root trust, normally managed by the OEM.
• Key Exchange Keys (KEK) — authorize updates to the signature databases.
• DB (Allowed signatures) — certs and hashes for components allowed to execute during boot (EFI binaries, drivers, option ROMs).
• DBX (Revoked signatures) — lists of signatures that are explicitly blocked.

The certificates Microsoft shipped in 2011 that live in KEK and DB are approaching or reach end-of-life (expiration). Microsoft’s replacement certificates (2023 series) are designed to:

• Split certain signing roles for better granularity (for example, separating option ROM signing from bootloader signing).
• Provide continuity for Secure Boot so that new vendor-signed boot components and Windows bootloader updates are trusted going forward.

Practical consequences of expired CAs​

If a device lacks the new certificates after the 2011 CAs expire:

• It will lose the ability to install Secure Boot security updates for UEFI/boot components.
• It may refuse to trust new third-party OS components signed by the 2023 CAs (affecting Linux shims, recovery media, option ROMs).
• It may not receive fixes for Windows Boot Manager once the Windows Production PCA 2011 expires in October 2026.
• Devices can become susceptible to bootkits and persistent pre-OS malware, which are notoriously difficult to detect and remediate once established.

---

Who is affected​

• Physical machines and virtual machines (VMs) running supported versions of:
• Windows 10 (supported versions) and Windows 11
• Windows Server branches including Long-Term Servicing Channel releases dating back to 2012 (Windows Server 2012 / 2012 R2 through Windows Server 2022 and 2025 where applicable)
• Virtual machines whose virtual firmware relies on Microsoft-signed keys (Hyper-V, VMware, cloud VM images).
• Many third-party OSes (notably Linux distributions that rely on Microsoft-signed shims) may be affected if firmware does not get updated to include the new CA certs.
• Microsoft indicated that Copilot+ PCs released in 2025 are not affected by the 2011 CA expiry timelines; however, device-specific assurances should be confirmed with the OEM.

Notably, devices where Secure Boot is disabled will not automatically receive the required Secure Boot variable updates from Windows — Secure Boot enabling/disabling and the active variable state matter for whether Windows can update those variables automatically.

---

The threat landscape: why this is urgent​

Boot-level compromises are among the most dangerous forms of system compromise. A successful bootkit can:

• Run before the OS and system defenses, evading endpoint protection.
• Persist across reboots and potentially across reinstallation if pre-boot components stay infected.
• Disable or circumvent protections such as BitLocker, HVCI, and antivirus, and protect its own kernel components from removal.

BlackLotus is a high-profile example of a UEFI bootkit that exploited pre-boot vulnerabilities to subvert Secure Boot and deploy persistent modules that disable OS defenses. The existence of BlackLotus and similar techniques demonstrates that unpatched or otherwise uncompromised boot paths are attractive targets for attackers — and losing the ability to receive updates strengthens their window of opportunity.
If firmware or platform key databases cannot be updated because CAs are expired and the device lacks the new CA entries, organizations risk being unable to remediate newly discovered pre-boot exploits or to block malicious boot components via DBX revocations.

---

Microsoft’s recommended approach (what they say to do)​

Microsoft’s public guidance sets out a combination of managed update and enterprise management options:

• Let Microsoft manage device updates for Secure Boot. This is the path of least resistance for many: Microsoft plans to roll the updated certificates through Windows Update for a large portion of devices.
• Ensure devices are set to allow Microsoft to manage Secure Boot updates by enabling the required diagnostic telemetry/opt-in. There is a registry-based opt-in value:
• Registry path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
• Key name: MicrosoftUpdateManagedOptIn (DWORD)
• Recommended DWORD value: 0x5944 (this value indicates the device is opted in to Windows-managed Secure Boot updates)
• Use Group Policy or MDM systems (for example, Microsoft Intune) to opt devices into Microsoft-managed Secure Boot updates at scale.
• Apply any available OEM firmware updates first. Firmware updates are foundational — Windows’ Secure Boot updates depend on compatible firmware that accepts new KEK/DB entries.
• For enterprises not sending diagnostic data to Microsoft, send at least the required level of diagnostic data or follow Microsoft’s guidance for independent update management (Microsoft has published instructions, tools, and a readiness survey).

Microsoft’s timeline and rollout will be phased; they plan to group devices with similar firmware profiles so updates are rolled out in a controlled manner.

---

Practical, prioritized action plan (for IT and power users)​

Start now — don’t wait until 2026. A practical, prioritized plan:

• Inventory and classify devices (next 2–4 weeks)
• Identify all physical endpoints, servers, and VMs that use Secure Boot.
• Record OEM, model, firmware/BIOS version, Windows build, and whether Secure Boot is enabled.
• Check and install OEM firmware updates (weeks 1–8)
• Contact OEMs and check firmware update availability; prioritize devices without recent firmware support.
• Apply firmware updates in test, then in staged rollouts.
• Validate Secure Boot is enabled and healthy (weeks 2–6)
• On Windows: confirm Secure Boot status and UEFI variable accessibility.
• If Secure Boot is disabled, consider enabling it (test carefully — enable only on devices known to be compatible).
• Opt devices into Microsoft-managed Secure Boot updates (weeks 2–12)
• For managed fleets, use GPO or MDM to set MicrosoftUpdateManagedOptIn = 0x5944, or rely on Microsoft update management as directed.
• For unmanaged consumer devices, enable the “Send diagnostic data” setting if you accept Microsoft-managed updates.
• Refresh recovery media and boot tools (weeks 4–12)
• Rebuild recovery USBs/install media using updated tooling so they’re signed by the new Windows UEFI CA 2023 where necessary.
• Ensure any custom pre-boot tools are re-signed with compatible certificates.
• Test end-to-end recovery and upgrade scenarios (weeks 8–16)
• Validate firmware + Secure Boot updates + recovery media in lab before mass rollout.
• Test BitLocker/TPM recovery flows (suspend BitLocker when applying firmware).
• Monitor and iterate (ongoing)
• Track rollout telemetry and OEM firmware releases.
• Keep an issue/troubleshooting runbook for devices that fail to accept new certificates or fail to boot.

Important operational cautions:

• Suspend BitLocker and backup recovery keys before applying firmware or changing Secure Boot variables; updates may cause BitLocker recovery if TPM policies or signatures change.
• Don’t attempt manual Secure Boot variable editing on production fleets without a tested rollback plan — a botched change can render a device unbootable.
• Devices with Secure Boot disabled will not receive automatic variable updates — enable Secure Boot first if the device and firmware support it.

---

Special considerations: virtualization, Linux, macOS, and cloud​

• Virtual machines: Hypervisors that expose UEFI to guests (Hyper-V, VMware, cloud providers) must be updated to make new CA trust available to guest firmware. Coordinate with hypervisor vendor/cloud provider for their planned rollouts and any required guest-image changes.
• Linux: Many distributions rely on a shim signed by Microsoft’s UEFI CA so they can boot with Secure Boot enabled. If firmware doesn’t get the new CA or shim is not re-signed appropriately, Linux boot behavior may be affected. Distributors and users should confirm shim and signed-kernel workflows and ensure firmware embraces the new CA entries.
• macOS: Devices using Apple’s firmware stack are outside Microsoft support. Dual-boot Mac owners relying on Microsoft-signed components should verify with Apple and relevant boot tooling.
• Cloud providers: For IaaS VMs, cloud vendors control the underlying platform firmware. Confirm status with providers (Azure, AWS, GCP) for how and when guest-level Secure Boot certificates will be updated.

---

Risk analysis — strengths and weak points of Microsoft’s plan​

Strengths​

• Centralized roll-out: Letting Microsoft manage the update via Windows Update simplifies deployment for many admins and users, reducing manual UEFI variable edits.
• Phased, telemetry-informed deployment: Microsoft intends to group devices by firmware profile, lowering the risk of a one-size-fits-all change causing mass failures.
• Separation of signing roles: The newer 2023 certificates add finer granularity (option ROM vs. bootloader signing), which improves security posture moving forward.

Weak points and risks​

• Firmware dependence: The process depends heavily on OEM firmware updates. Older hardware or devices from smaller OEMs may never receive a compatible firmware version, leaving them permanently at risk or requiring manual intervention.
• Diagnostic data opt-in mechanism: Microsoft’s managed update path relies on devices sending diagnostic data or registry opt-in. Organizations with strict telemetry policies or privacy concerns may delay accepting Microsoft-managed updates.
• Complexity and tooling mismatch: Large, heterogeneous fleets (various OEMs, OEM BIOS versions, custom images) are at higher risk of edge-case failures; this requires more rigorous testing.
• Potential for unbootable devices: Incorrectly applying Secure Boot fixes or mixing new and old recovery tools can cause BitLocker prompts or unbootable devices if not managed carefully.
• Third-party OS compatibility: Linux and other OS providers must coordinate re-signing or compatibility work. If not coordinated, dual-boot or alternative OS deployments can break.

---

For administrators: a concrete checklist and policies to implement​

• Security inventory policy:
• Maintain a sortable asset inventory with firmware version fields and Secure Boot status.
• Update policy:
• Apply OEM firmware updates proactively in a test-staging-production pipeline.
• Telemetry policy:
• Decide and document whether devices will opt into Microsoft-managed Secure Boot updates; if not, prepare for manual management.
• Backup and recovery policy:
• Ensure BitLocker keys are escrowed centrally.
• Rebuild rescue media with updated signed components and test recovery.
• Testing policy:
• Require two-stage validation for any device-type before mass rollouts: automated tests plus manual sanity checks.
• Communication policy:
• Notify end users of scheduled firmware/boot updates and educate on BitLocker recovery expectations.

---

Troubleshooting, fallback, and incident readiness​

• If a device fails to boot after an update:
• Use updated recovery media that is known to trust the new Windows UEFI CA 2023.
• Have out-of-band tools for restoring firmware variables or re-imaging.
• If a device won’t accept new KEK/DB entries:
• Check OEM firmware compatibility; rollback to prior firmware may be the only immediate option.
• Contact OEM support with device model and firmware logs.
• If BitLocker prompts for recovery:
• Verify BitLocker recovery keys from your key escrow and follow documented recovery steps.
• Use documented procedures to re-enable/suspend BitLocker before firmware changes in the future.

---

What consumers and small businesses should do​

• Check Windows Update and OEM support pages for firmware and Secure Boot notices.
• If comfortable, enable diagnostic data per Microsoft guidance to allow automatic management (understand privacy implications).
• Recreate recovery media using the latest official Microsoft recovery creation tools.
• If you run Linux or dual-boot, verify with your distribution for shim updates or community guidance.
• For older devices without firmware updates from the OEM, consider hardware replacement planning or isolating the device from sensitive networks.

---

Timeline and recommended cadence​

• Immediate (today — within 1 month)
• Inventory devices and firmware versions.
• Identify high-risk machines (no recent firmware, legacy OEM).
• Short term (1–3 months)
• Test firmware updates and Secure Boot updates in a pilot group.
• Configure registry/MDM opt-ins where appropriate.
• Update and test recovery media.
• Mid term (3–9 months)
• Roll out firmware and certificate updates to production groups after testing.
• Track telemetry and failure rates; maintain rollback plans.
• Long term (ongoing, through June–Oct 2026)
• Maintain firmware and OS updates, monitor Microsoft’s rollout notices.
• Reassess devices that cannot be updated and plan replacement or isolation.

---

Final analysis and practical verdict​

This Secure Boot certificate rollover is a rare, high-impact infrastructure task that intersects firmware, OS, and vendor ecosystems. Microsoft’s approach to managing the renewal via Windows Update and telemetry-guided rollouts reduces the burden for many organizations, but it introduces dependencies on OEM firmware updates and on opting devices into Microsoft-managed flows.
For defenders, the core choices are clear:

• Treat this as a firmware and identity lifecycle event, not just a Windows update.
• Start inventory, testing, and firmware update campaigns now.
• Protect the recovery path (recovery media, BitLocker keys) before making any changes.

If handled proactively, the certificate replacement should preserve Secure Boot’s protections and even strengthen them through more granular signing semantics. If mishandled or ignored, however, it will create a window where devices cannot receive pre-boot security fixes, exposing them to bootkits and persistent threats — a scenario with potentially costly operational and security consequences.
The immediate imperative is operational: build a test-and-rollback-capable program, coordinate with OEMs and vendors, and ensure recovery tools are updated and tested. With that foundation in place, the June 2026 and October 2026 milestones become manageable maintenance events rather than crisis points.

---

Source: The Windows Club Secure Boot Certificates going to expire in June 2026