Plan Your Secure Boot Certificate Rollovers as 2011 CAs Expire (2026)

Microsoft has warned that several of the Secure Boot certificates baked into Windows devices a decade ago will begin to expire in mid‑2026, forcing a coordinated certificate rollover that every PC owner and IT team should plan for now to avoid loss of pre‑boot updates, compatibility problems, and elevated boot‑level security risk.

Background / Overview​

Secure Boot is the UEFI‑level mechanism that ensures a PC only runs firmware and boot components signed by trusted authorities. Its trust model relies on a small set of cryptographic trust anchors stored in UEFI NVRAM variables: the Platform Key (PK), Key Exchange Keys (KEK), the allowed signatures database (DB), and the revoked signatures database (DBX). When those certificates expire, the platform must be given updated trust anchors; otherwise it may refuse updates or new boot components.
Microsoft has documented a planned, multi‑step transition in which older certificate authorities issued in 2011—commonly referenced as “2011‑era CAs” such as Microsoft Corporation KEK CA 2011, Microsoft UEFI CA 2011, and Microsoft Windows Production PCA 2011—will be replaced by a newer 2023 family of CAs (for example, Microsoft Corporation KEK CA 2023, Windows UEFI CA 2023). The earliest expirations begin in June 2026, with another critical expiry for the Windows Production PCA in October 2026. Devices that remain trusting only the 2011 CAs after those dates risk losing the ability to receive Secure Boot updates or to trust components signed by the new certificates.

---

Why this matters: security, compatibility, and patchability​

Secure Boot protects the pre‑OS environment. If the platform cannot accept new signing certificates and related updates, three core problems emerge:

• Security updates stop flowing for pre‑boot components. The Windows Boot Manager, pre‑boot recovery components, and firmware‑level mitigations are delivered with signatures that must chain to trusted CAs; if trust anchors are expired, those updates cannot be accepted and applied.
• Compatibility gaps with third‑party OSes and tools. Many Linux distributions use a Microsoft‑signed shim to enable Secure Boot compatibility on x86/x64 systems. If firmware does not accept the new 2023 CA entries, newly signed shims or bootloaders may be refused, creating boot or install failures for dual‑boot or Linux‑only users.
• Increased exposure to boot‑level attacks. Without the ability to update the boot chain or revoke compromised components, platforms become more attractive for persistent bootkits and firmware‑level malware — threats that are extremely difficult to detect and remediate.

These are not abstract concerns: Microsoft’s rollout guidance stresses that certificate updates should be applied well before the June/October 2026 expirations to maintain continuity of trust and updateability.

---

What exactly is expiring — the key dates and certificates​

The most important timelines and items to track:

• June 2026 — Major Secure Boot CAs issued in 2011 (for example, Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011) will reach end‑of‑life. Devices still trusting only these CAs at that point may stop accepting updates and new signatures.
• October 2026 — Windows Production PCA 2011 is scheduled to expire. This CA has a central role in trusting Windows bootloader signatures; its expiry is therefore particularly critical for Windows updateability.

Microsoft’s response is to publish replacement CAs (2023 family) and to deliver a staged update consisting of OS‑side packages (SSU/LCU/KB packages) and OEM firmware updates that allow the new certificates to be accepted by UEFI variables. The sequence matters: add the new CA into the DB/KEK first, then deploy a boot manager signed by the new CA, and only after that consider revoking or DBX‑listing the old CA to prevent rollbacks. Some of these steps (especially DBX revocations) are effectively permanent when accepted by a device.

---

Who is affected​

The rollout affects a wide range of platforms:

• Consumer PCs and laptops running supported builds of Windows 10 and Windows 11 that still include the 2011 CA chain in firmware.
• Windows Server platforms, including Long‑Term Servicing Channel (LTSC) releases dating back several generations, where firmware and update paths rely on the same CA roots.
• Virtual machines whose virtual firmware or host hypervisor uses Microsoft‑supplied signing keys (Hyper‑V, VMware, and many cloud VM images). A VM can be affected if its virtual firmware does not include the new CAs.
• Linux distributions and other OSes that rely on Microsoft‑signed shims for Secure Boot compatibility; these can fail to boot if firmware lacks the updated trusted CAs.
• Air‑gapped, highly restricted, or firmware‑locked systems where OS‑initiated writes to UEFI variables are blocked; these will require offline, OEM‑coordinated procedures.

Note: Devices that have Secure Boot disabled are not automatically updated via the Microsoft‑managed flow and may need manual intervention depending on management policies and firmware behavior.

---

Microsoft’s delivery model and recommended actions​

Microsoft’s published guidance explains a multi‑channel delivery model and recommended approaches depending on device management model:

• Microsoft‑managed rollouts (preferred for many consumer and corporate devices): Windows Update will push the certificate updates and the updated boot manager in a staged fashion where diagnostic/telemetry and update channels permit. This reduces manual work for most users.
• IT‑managed rollouts: Enterprises should coordinate with OEMs to confirm firmware versions that allow DB/KEK variable updates and sequence firmware updates before applying OS‑side certificate changes. Tools like WSUS, Configuration Manager, and Windows Update for Business are supported for staged deployments.
• Air‑gapped / heavily restricted systems: These require bespoke offline procedures and closer OEM coordination; Microsoft has documented offline workflows and registry opt‑in mechanisms but the steps are delicate.

Important operational knobs and guidance items that administrators should note:

• Microsoft published an opt‑in registry DWORD: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\MicrosoftUpdateManagedOptIn with the value 0x5944 to indicate devices may be updated via Microsoft’s managed flow. This is intended for IT scenarios that permit Microsoft‑managed variable updates; consult policy before changing telemetry or registry settings.
• Microsoft packages the required updates as combined SSU (Servicing Stack Update) + LCU (Latest Cumulative Update) to ensure correct installation sequencing and to reduce partial‑install states. Administrators should test SSU+LCU packages in pilot rings before broad rollout.

---

Practical checklist — what to do today (consumer and IT)​

Apply this checklist in pilots and move to staged rollouts; it’s intentionally prescriptive and ordered:

• Inventory and identify
• Run msinfo32 → check Secure Boot State to see whether Secure Boot is enabled.
• Record OEM, model, and firmware/BIOS version for representative systems and critical assets.
• Confirm update channels
• Ensure devices that can be Microsoft‑managed are receiving Windows Update and are not blocking the delivery of SSU/LCU packages.
• For managed fleets, evaluate whether the MicrosoftUpdateManagedOptIn registry approach fits policy and privacy requirements; test on a pilot group first.
• Apply servicing stack and test recovery
• Install the recommended SSU+LCU pilot packages (Microsoft has included related servicing stack updates in recent cumulative updates) and verify recovery scenarios (Reset this PC, cloud recovery, Intune RemoteWipe) behave correctly on test devices. Known KBs and pilots have been suggested in Microsoft’s guidance.
• Coordinate OEM firmware updates
• Contact OEMs or check support pages for firmware releases that add the 2023 CA entries or otherwise enable OS‑initiated variable updates.
• Prioritize firmware‑ready devices for early rollout rings; older firmware may require manual or OEM intervention.
• Update golden images and offline images
• For imaging and air‑gapped scenarios, include necessary SSU+LCU payloads in your golden images using DISM /Add‑Package or offline MSU workflows. Verify images boot and recover correctly.
• Test cross‑platform boot scenarios
• If you run dual‑boot setups or support Linux clients, validate boot behavior with vendor‑provided firmware updates. Test newly signed shims and recovery media against updated firmware.
• Prepare rollback and reimaging plans
• Some DBX revocations and SVN updates are effectively non‑reversible; document reimaging procedures and maintain fresh images for recovery should a device accept a change that leaves it unbootable.

---

Deep dive: the technical sequencing and non‑rollbackable steps​

The certificate transition is intentionally multi‑step to avoid a broken trust chain. The safe sequence commonly described is:

• Add the new 2023 certificates to the DB/KEK so platforms can verify new signatures.
• Deploy updated Windows Boot Manager and other pre‑boot components signed by the 2023 CA.
• Optionally add the 2011 CA to DBX (revoke) and apply a Secure Version Number (SVN) update to prevent an attacker from rolling the boot manager back to an older (and potentially vulnerable) version.

Each of these steps must be validated on representative hardware. Crucially, DBX entries and certain SVN settings are effectively permanent on devices that accept them — unintentional acceptance on an untested device could leave it unable to boot using older recovery media. That makes thorough testing in pilot rings essential.

---

Edge cases and operational unknowns: where risk concentrates​

• Firmware readiness from OEMs is the largest operational unknown. Some older or vendor‑specific firmware may refuse OS‑initiated writes to KEK/DB/DBX, requiring firmware updates or out‑of‑band procedures.
• Virtual environments can be affected if the host firmware or hypervisor does not include the updated CAs; cloud images and VM templates should be validated.
• Air‑gapped or security‑restricted environments that cannot enable Microsoft‑managed updates will require complex offline certificate update procedures and careful coordination with OEMs.
• Some user reports and early telemetry in prior update rolls have revealed regressions in recovery flows when servicing stack changes interact with certain OEM recovery partitions; this is why Microsoft packages SSU+LCU together and recommends pilot tests. Administrators must assume there will be environment‑specific issues and plan rollback/reimage strategies accordingly.

---

Risks of inaction and the defensive upside of prompt action​

If an organization or user does nothing and leaves devices on expired CAs:

• They may stop receiving security fixes for pre‑boot components after June/October 2026, depending on the certificate that expires first.
• Newly signed boot components (including updated shims or bootloaders) may be refused by firmware that still trusts only the legacy 2011 CAs.
• The environment’s resilience against bootkits and pre‑OS attacks will degrade because Microsoft will be unable to push cryptographic protections and revocations to such devices.

The upside of prompt, tested updates is clear: devices remain able to receive future pre‑boot updates, revocations can be applied when needed, and rollback protections (SVN) reduce the risk of attackers substituting older vulnerable boot components.

---

Recommendations by audience​

For home users and enthusiasts​

• Keep Windows Update enabled and allow recommended updates to install.
• Check msinfo32 → Secure Boot State and confirm Secure Boot is enabled if your device shipped with it.
• Before experimenting with experimental firmware modding or disabling Secure Boot, recognize that doing so may prevent automatic certificate updates and complicate future updates.

For IT administrators and defenders​

• Build an inventory that maps devices to OEM firmware levels, Secure Boot state, and management channel.
• Run pilot rings with SSU+LCU packages and test device recovery scenarios comprehensively.
• Coordinate with OEMs for firmware that accepts OS‑initiated KEK/DB updates; schedule firmware updates before broad OS‑side certificate changes.
• Update imaging processes and WSUS/SCCM catalogs (Products = Windows 11, Classifications = Security Updates) to ensure offline/air‑gapped devices can be prepared.

For virtualization and cloud operators​

• Validate that host hypervisors and cloud images include or will accept the new CA entries.
• Update VM templates and cloud images so that guests inherit a firmware configuration that trusts the 2023 family where appropriate.

---

What to watch next (timeline and signals)​

• Microsoft’s FAQ and KB entries have been updated with canonical guidance; administrators should use the KB references published by Microsoft for exact package names and KB numbers and watch for firmware advisories from OEMs.
• Expect staged Windows Update rollouts for many consumer devices; telemetry opt‑ins and diagnostic settings may influence whether a particular device is included in an automated update wave.
• OEM firmware availability and documented compatibility matrices will be the decisive signal for enterprise rollout timing; track OEM support pages for firmware that explicitly references the Secure Boot 2023 CA entries.

---

Final assessment: strengths, tradeoffs, and hard truths​

Microsoft’s planned rollover is a necessary, security‑positive step: updating trust anchors and enabling SVN/DBX workflows strengthens the platform against rollback attacks and allows Microsoft to sign future pre‑boot fixes. Packaging required changes as SSU+LCU and offering Microsoft‑managed rollouts reduces operational friction for many users. These are clear strengths.
However, the program’s success depends heavily on firmware vendor cooperation, accurate inventorying, and disciplined pilot testing. The primary risks are:

• Firmware that refuses OS‑initiated updates, leaving devices stranded.
• Unintended acceptance of irrevocable DBX/SVN changes on test devices, which can complicate recovery if not validated.
• Compatibility gaps for Linux and virtualization workloads if the chain of trust is only partially updated.

These tradeoffs mean organizations must treat the certificate rollover as a major, multi‑quarter operational program — not a routine monthly update.

---

Maintaining the integrity of the boot chain is one of the most consequential security tasks administrators face in the next 12–18 months. Begin inventory and pilot work today, coordinate with OEMs for firmware readiness, and use Microsoft’s managed rollout where policy permits. The technical complexity and non‑rollbackable steps demand careful testing, but the alternative — leaving devices unable to receive pre‑boot fixes or to trust future boot components — is a much greater long‑term risk.

---

Source: Neowin Windows Secure Boot certificates are expiring, here is everything you need know