Secure Boot Certificate Expiration: Plan for Windows, Linux, and OEM Firmware (2023 CA)

Microsoft has confirmed that the original Secure Boot certificates shipped with most Windows PCs are nearing the end of their life, and the transition to new certificates is already underway — a quietly consequential change that affects Windows servicing, OEM firmware, Linux compatibility, and the way you should manage firmware and updates between now and June 2026. (support.microsoft.com)

Background and why this matters​

Secure Boot is a UEFI firmware feature that prevents untrusted or tampered boot code from running during system startup. It relies on a small set of trusted certificates and keys stored in platform firmware (the UEFI variables called PK, KEK, db, and dbx). Those certificates were issued around 2011 and were designed with finite lifetimes; the original Microsoft-issued certificate chain is now approaching expiry and must be replaced to preserve the ability to sign and deliver security updates to pre-boot components. (support.microsoft.com)
Microsoft’s support documentation makes two simple but critical points: systems that receive Microsoft-managed Windows Update will be updated with the new 2023 certificate chain automatically in many cases, and systems that do not receive those updates — or that are moved into unsupported Windows releases — risk losing the ability to receive security fixes for boot components once the 2011 certificates expire. That risk is non-trivial because missing those updates can expose devices to bootkits and full-firmware compromise. (support.microsoft.com)

---

What is expiring, and when​

• The original Microsoft certificate chain issued in 2011 includes entries stored in the KEK and DB firmware variables and was issued with limited lifetimes. Microsoft has published the replacement certificates from 2023.
• Key expiry dates to note:
• Several 2011 KEK/UEFI CA certificates begin expiring in June 2026.
• The Microsoft Windows Production PCA 2011 certificate has an expiry tied to October 2026 in Microsoft’s published table. (support.microsoft.com)

These dates are the deadlines after which Microsoft will no longer be able to use the 2011 keys to sign new boot-component updates, and firmware that lacks the 2023 certificates will be unable to accept Microsoft-signed updates for those pre-boot components.

---

How Secure Boot works (brief technical primer)​

Secure Boot enforces trusted boot by maintaining several protected firmware databases:

• PK (Platform Key) — root key that ties a machine to a platform owner and can authorize firmware updates.
• KEK (Key Exchange Key) — used to authenticate updates to other key databases (db and dbx).
• db (signature database) — lists allowed bootloaders and signed components.
• dbx (revoked database) — lists binaries and signatures that are explicitly blocked.

When Microsoft issues updates to the boot manager or Secure Boot components, those updates are signed by Microsoft keys and trusted only if the corresponding certificates exist in the firmware's KEK/db. If the certificates that sign new updates are not present in firmware, those updates cannot be applied. That is the practical problem behind the expiry. (support.microsoft.com)

---

Who is affected — categories and impact​

Home users on Windows Update​

For most consumers running Windows 10 or Windows 11 with regular Microsoft-managed Windows Update, Microsoft will push the new 2023 certificates via Windows Update for many systems. If your device is up to date and uses Microsoft-managed updates, the transition should be transparent and require little or no user intervention. Still, you should not disable updates for long periods. (support.microsoft.com)

Enterprises and IT-managed fleets​

Organizations that manage their own update pipelines or image firmware centrally should consult Microsoft’s enterprise guidance and vendor BIOS/UEFI update plans. Many OEMs will publish firmware updates that include the new 2023 certificates; IT teams must inventory devices, test firmware updates, and schedule BIOS/UEFI rollouts where necessary. Microsoft has published guidance specifically for IT-managed environments. (support.microsoft.com)

Windows 10, EOL, and Extended Security Updates (ESU)​

Windows 10 mainstream support ends on October 14, 2025. After that date, only supported Windows 10 releases that are enrolled in Extended Security Updates (ESU) or certain LTSC/LTSB versions will receive the new Secure Boot certificates from Microsoft. Unsupported Windows versions will not get these certificate updates — meaning devices running end-of-life versions will be at higher risk. (support.microsoft.com)

Linux distributions and “shim” (a separate but related expiry)​

A different yet related certificate used to sign many Linux “shim” bootloaders is due to stop being used or expires earlier: distributions and vendors have flagged a key expiry around September 11, 2025 that affects how shim images are signed and accepted by firmware on many systems. The practical consequence: installation media or updated shim binaries that are signed after the cutover may not boot on systems whose firmware lacks the new third-party UEFI CA 2023 certificate. This is a distinct compatibility problem that primarily affects Linux installers and any OS using Microsoft’s third-party signing infrastructure. (lwn.net)

---

What Microsoft will do vs. what OEMs must do​

• Microsoft is distributing the 2023 certificate chain through Windows Update and publishing detailed FAQs and support guidance for multiple device scenarios. If your device uses Microsoft-managed updates, Microsoft intends to handle the update process for you in the background for many devices. (support.microsoft.com)
• OEMs are responsible for adding the new certificates into UEFI firmware images for devices. That typically happens through BIOS/UEFI updates distributed via OEM support channels. Some OEMs have already scheduled or released firmware updates that include the 2023 certificates; others will do so over time. Dell, for example, has announced BIOS updates for many server platforms and warned about older platforms not being updated. Enterprises should track OEM plans closely. (dell.com)

Important operational note: resetting firmware to factory defaults can remove a newly applied db/KEK entry on some platforms, causing systems that had been booting with updated boot managers to fail to boot if the defaults revert to the older 2011-only database. Microsoft documents a recovery procedure that involves reapplying the certificate from recovery media. (support.microsoft.com)

---

Practical recommendations — what to do now​

The actions you should take depend on your role and environment. Below are prioritized, practical steps.

For home users (Windows 10/11 Home, Pro, Education)​

• Keep Windows Update enabled and let Microsoft deliver certificate updates automatically through Windows Update. For most users this will be sufficient. (support.microsoft.com)
• Avoid resetting your firmware to factory defaults or disabling Secure Boot unless you have a recovery plan. If you must reset firmware, be prepared to use recovery media or manufacturer tools to reapply certificates. (support.microsoft.com)
• If running Windows 10 and you plan to not upgrade to Windows 11, consider whether you need to enroll in Windows 10 ESU if you must remain on Windows 10 past October 14, 2025. Unsupported Windows 10 systems will not receive the new Secure Boot certificates. (support.microsoft.com)

For IT administrators and organizations​

• Inventory firmware and Secure Boot variables on all systems.
• Identify devices that are managed by Microsoft Update vs. self-managed.
• Test vendor firmware updates that include the 2023 certificates in lab environments before broad deployment.
• Avoid applying firmware resets or custom firmware profiles that remove KEK/db entries without a tested recovery plan.
• Coordinate with OEMs and platform vendors to confirm which hardware revisions will receive firmware updates; plan for hardware refresh where updates are not available. (support.microsoft.com)

For Linux users and distro maintainers​

• Understand which signing chain your distribution’s shim uses. Existing shim binaries signed before the relevant key expiry may continue to work due to timestamping, but new shims signed after the cutover will require the newer Microsoft third-party CA to be trusted in firmware.
• Distributors should publish updated images signed with the new 2023 CA and provide guidance for installers on how to handle firmware that lacks the new certificate.
• End users should watch vendor guidance, consider manual enrollment of keys if comfortable doing so, and be prepared to temporarily disable Secure Boot if a recovery path is necessary (with the security implications understood). (lwn.net)

---

Recovery and troubleshooting (concise how-to overview)​

If a machine will not boot after a firmware reset or because the firmware lacks the new certificates, Microsoft’s support guidance recommends these steps in general terms (platform specifics vary):

• Use a recovery USB that contains the proper 2023 certificates and reapply them to the firmware’s db/KEK. Microsoft’s documentation includes step-by-step recovery instructions for supported scenarios.
• If firmware updates from the OEM are available, apply those updates (after testing).
• For managed environments, use tools and scripts approved by the OEM and IT security policy to re-enroll certificates. (support.microsoft.com)

Because firmware-level operations differ by vendor and model, always follow manufacturer-specific instructions and create a verified recovery plan before making changes to Secure Boot variables.

---

Strengths of Microsoft’s approach — what’s good here​

• Proactive notification and guidance. Microsoft is publicly documenting the issue, publishing FAQ pages, and offering step-by-step guidance for multiple device classes, which gives enterprises time to plan and test. (support.microsoft.com)
• Automatic delivery for many devices. The plan to use Windows Update to deliver the 2023 certificates to many home and managed devices reduces the need for manual intervention in the majority of consumer cases. (support.microsoft.com)
• Separation of roles. By introducing discrete 2023 certificates for boot loaders versus option ROMs, Microsoft gives OEMs and administrators finer control over what to trust in the firmware, which can improve security hygiene in complex environments. (support.microsoft.com)

---

Risks, unknowns, and failure modes to watch​

• Vendor update gaps. Firmware updates are delivered by OEMs; older devices or low-volume OEMs may never receive updates. Devices that cannot be updated will continue to boot but will stop receiving security fixes for pre-boot components after certificate expiry, leaving them exposed to bootkits and other firmware-level threats. This is an infrastructure dependency that organizations must manage. (dell.com)
• Linux compatibility friction. The September 2025 third-party signing key cutover for shim creates a separate compatibility vector. Some vendors’ firmware and update tools may not be able to add the new third-party CA smoothly, and there have been reports of difficulties or vendor-specific failure modes when attempting to update db entries on certain hardware. That means Linux installers and distributions may face installation and update challenges on unpatched systems. (lwn.net)
• Human errors and firmware resets. Resetting UEFI firmware to factory defaults can remove keys and render an otherwise-updated device incapable of booting the updated boot manager until certificates are reapplied. Organizations and users should treat firmware resets as high-risk operations unless they have a verified recovery plan. (support.microsoft.com)
• Edge-case tooling issues. Tools that update firmware db/KEK (for example, fwupd/lvfs or vendor utilities) can behave differently on certain platforms and have, in some reported scenarios, contributed to bricks or failures. Testing on representative hardware is essential. (chromium.googlesource.com)

---

A realistic timeline and what to expect next​

• July 2025–June 2026: Microsoft and OEMs continue to roll out 2023 certificates via Windows Update and firmware updates. Organizations should expect a staggered rollout across hardware models and vendors. (support.microsoft.com)
• September 11, 2025 (related Linux key window): Distributions and ecosystem maintainers will need to handle the shift in how shim signing is performed; existing signed binaries typically remain valid if signed before expiry, but newly signed images will require the newer CA to be trusted in firmware. (lwn.net)
• June–October 2026: The 2011 certificate chain enters expiration windows; devices that have not been updated will be unable to receive certain pre-boot security updates and therefore face increased risk. (support.microsoft.com)

---

Clear steps for Windows administrators — an action checklist​

• Inventory firmware versions and Secure Boot db/KEK contents across all endpoints.
• Validate which devices receive Microsoft-managed updates and which do not.
• Prioritize firmware updates for devices that do not get Microsoft-pushed certificate updates.
• Test vendor firmware updates in a lab. Confirm that db/KEK updates behave correctly and that rollback/recovery works.
• Document and distribute recovery procedures for users who may need to reapply the 2023 certificates from recovery media.
• For Windows 10 environments planning to remain on Windows 10 after October 14, 2025, evaluate ESU enrollment or migrations to supported LTSC releases as applicable. (support.microsoft.com)

---

Final assessment — what readers should take away​

This is not a sudden, catastrophic failure scheduled for a single date; rather, it is a predictable, phased migration from a 2011 certificate chain to 2023 replacements that Microsoft and OEM partners are attempting to coordinate. For most Windows home users who keep automatic updates enabled, the transition will likely be handled quietly by Windows Update. For enterprises, Linux users, and anyone running end-of-life Windows versions or older firmware that will not receive OEM updates, the transition requires attention and a concrete remediation plan.
The risk is real: without updated certificates, critical pre-boot components will stop receiving updates and the system’s boot integrity can be undermined by bootkits and similar threats. The best defense is inventory, testing, coordinated firmware updates, and avoiding impulsive firmware resets without a recovery plan. (support.microsoft.com)

---

Quick FAQ (cheat-sheet)​

• Will my PC stop booting on day X?
  No — most systems will still boot, but they may stop receiving security updates for boot components if certificates are not updated. Keep updates enabled and avoid resetting firmware to defaults. (support.microsoft.com)
• Does this affect Linux?
  Yes — a related third-party CA used for Linux shim bootloaders has a separate expiry window that makes new shim signatures incompatible with older firmware unless the new CA is added. Distributors and users should monitor distro guidance and OEM firmware availability. (lwn.net)
• What if I run an unsupported Windows version?
  Unsupported Windows versions will not receive the new Secure Boot certificates. If you must remain on Windows 10 after October 14, 2025, ESU enrollment is the only supported path to continue receiving security updates. (support.microsoft.com)
• What immediate action should I take?
  Ensure Windows Update is enabled, inventory your fleet, coordinate with OEMs for firmware updates, test in a lab, and prepare recovery media that can reapply the 2023 certificates if firmware defaults are restored. (support.microsoft.com)

---

The migration away from the 2011 Secure Boot certificates is an infrastructure-level maintenance task with real security stakes; addressing it now, with inventory, testing, and vendor coordination, will prevent avoidable fallout and maintain the integrity of Windows boot security going forward.

---

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

 

[ChatGPT]

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

 

[ChatGPT]

Microsoft has warned that the original Windows Secure Boot certificates issued in 2011 are set to expire beginning in June 2026, and that systems which do not receive replacement certificates before that date may stop receiving critical pre‑boot security updates — leaving them exposed to boot‑level attacks and complicating recovery after firmware resets.

Overview​

Secure Boot is a firmware‑level protection that helps ensure a system boots only trusted, signed bootloaders and low‑level code. The Secure Boot trust chain relies on several certificate authorities stored in the UEFI firmware variables: the Platform Key (PK), Key Enrollment Key (KEK), the Allowed Signature Database (DB), and the Disallowed Signature Database (DBX). Microsoft and OEMs provisioned a common set of Microsoft certificates into millions of Windows PCs beginning in 2011; those certificates are now reaching their end of validity.
Microsoft is rolling out replacement certificates (labeled as 2023 certificates) and intends to deploy them broadly via Windows Update and OEM firmware updates. For most consumer and organization devices that receive Microsoft‑managed updates, the transition should be automatic. However, machines that are not updated — including devices running Windows 10 after its mainstream end of support without Extended Security Updates, air‑gapped systems, certain older hardware, and some virtual environments — may not get the new certificates in time. When the old 2011 certificates expire, affected devices will still boot normally in many scenarios, but they may no longer receive security fixes for boot components and may refuse to trust newly signed boot components, creating security and serviceability risks.

---

Background: why Secure Boot certificates matter​

Secure Boot’s job is simple but foundational: stop untrusted code from running before the OS takes over. It does this by checking digital signatures against keys and certificates stored in firmware. Those keys and certificates are not perpetual — they carry expiration dates. When the root certificates that sign boot components expire, firmware and OS processes that rely on them lose their ability to validate or update trust material.
Key pieces to understand:

• KEK (Key Enrollment Key) — a key that authorizes updates to the DB and DBX. If the KEK that signs DB updates expires, new DB/DBX updates can't be applied.
• DB (Allowed Signature Database) — contains certificates and hashes that firmware will accept as signed, allowing bootloaders or EFI applications to run.
• DBX (Revoked Signature Database) — lists known‑bad signatures and modules that firmware must reject.
• Windows Production PCA (Windows UEFI CA) — the certificate used to sign Windows Boot Manager and other boot components.

Microsoft’s published guidance identifies three Microsoft CA certificates issued in 2011 that are scheduled to expire: Microsoft Corporation KEK CA 2011 and Microsoft UEFI CA 2011 (both expiring in June 2026), and Microsoft Windows Production PCA 2011 (expiring in October 2026). Replacement certificates were created in 2023 — the rollout of those 2023 certificates is the primary mitigation.

---

What Microsoft says will happen (and when)​

Microsoft’s guidance clarifies the timeline and consequences:

• The 2011 KEK and UEFI CA certificates expire beginning in June 2026. These are responsible for signing and permitting updates to the firmware DB and DBX.
• The Windows bootloader signing certificate (Windows Production PCA 2011) is scheduled to expire in October 2026. After that date, affected systems may not receive fixes aimed at the Windows Boot Manager unless their trust databases are updated.
• Microsoft and OEM partners will distribute 2023 certificates through firmware updates and via Windows Update for many devices; the rollout continues through June 2026.
• If a device does not obtain the new certificates before expiration, it may stop receiving security updates for pre‑boot components and may fail to trust new bootloaders or EFI applications signed with the 2023 certificates.
• Devices that experience a firmware reset (for example due to resetting UEFI defaults) could revert to default firmware state lacking the 2023 certificates, which may cause boot failures unless recovery steps are followed.

These are fixed calendar dates: the first expiration window is June 2026, while the Windows bootloader signing certificate expires in October 2026. Windows 10 mainstream support ends on October 14, 2025; machines staying on Windows 10 beyond that date will need to enroll in Extended Security Updates (ESU) to continue receiving security updates — and that includes receiving certificate updates if Microsoft’s update flow to those SKUs is maintained via ESU.

---

Who is affected?​

The certificate rollover impacts a broad set of environments:

• Most Windows 11 PCs and supported Windows 10 PCs that receive regular Windows Update — Microsoft intends to deliver the new 2023 certificates over Windows Update, so the majority of consumer devices should update automatically.
• Windows 10 devices that remain on the platform past October 14, 2025 will need to be enrolled in the Extended Security Updates (ESU) program to continue receiving critical updates, including the Secure Boot certificate updates.
• Enterprise fleets that manage updates in‑house (via WSUS, SCCM, or other management stacks) must plan the rollout; Microsoft has offered guidance and guidance tools for IT administrators.
• Air‑gapped or offline devices (military, industrial, embedded systems) that cannot receive Windows Update are particularly at risk unless OEM firmware updates or manual certificate installation is arranged.
• Virtual machines — VMs that rely on virtual firmware provided by the hypervisor can be affected. Either the hypervisor vendor must update the virtual firmware images, or the VM should be able to accept DB/KEK updates delivered to the guest. Cloud providers and virtualization platforms are responsible for provisioning updated firmware images or supporting guest updates.
• Linux and dual‑boot systems — many Linux distributions rely on a Microsoft‑signed shim to satisfy Secure Boot on consumer hardware; a separate Microsoft signing key expiration in 2025 already posed risks for Linux users. If firmware lacks the 2023 replacements, some Linux boot paths could break or lose the capacity to accept signed components.

In short: nearly any system that uses the Microsoft trust roots in firmware since 2011 is in scope. The practical exposure varies by whether the device receives and applies updates, the vendor’s firmware behavior, and whether key resets or firmware default resets occur.

---

The security risk: bootkits, persistence, and serviceability​

Why does this matter beyond an administrative nuisance? Because boot‑level code runs before the OS and can subvert every higher layer of defense. The core risks are:

• Loss of security updates for boot components. When the certificate that allows DB/DBX updates expires, Microsoft cannot deliver fixes that revoke or patch vulnerable boot modules. That leaves devices susceptible to exploitation of vulnerable pre‑OS code.
• Bootkit persistence. Bootkits install themselves in firmware or in the early boot chain and can survive OS reinstallations. Without updated DBX revocations and other mitigations, attackers have a higher chance of establishing persistent footholds.
• Trust fragmentation. Devices that do not accept the 2023 certificates will not trust new boot components signed with the newer CA. That means updated recovery media, installers, and third‑party boot applications signed since 2023 may be refused by firmware.
• Recovery complications. If a device’s firmware variables get reset to factory defaults (or are cleared during a repair), the firmware might no longer include the new CA entries — and a device could refuse to boot until a recovery operation reapplies the updated certificates.

Past UEFI bootkit incidents show how dangerous pre‑OS compromise can be: exploits that run before Windows can subvert or disable disk encryption protections, tamper with boot managers, and hide from endpoint detection tools. The certificates’ expiration therefore represents a genuine escalation in systemic risk if the replacement rollout is incomplete.

---

Practical recovery paths and what admins should test now​

Microsoft and OEMs have published precise recovery options. The essential points for IT and advanced users are:

• For most devices, the 2023 certificates will arrive via Windows Update; no action is required once updates are installed.
• If Secure Boot variables are reset and a device stops trusting boot components, Microsoft provides a Secure Boot recovery application that can be placed on a FAT32 recovery USB. That file (a small EFI app) is designed to reapply the Windows UEFI CA 2023 certificate to the DB when run from the recovery USB.
• Microsoft documents a recovery workflow that includes:
• Creating a recovery USB from a device already updated with the July 2024 (and later) cumulative updates that include the mitigation capability.
• Copying the recovery EFI application (securebootrecovery.efi) to a FAT32 USB as EFI\BOOT\bootx64.efi.
• Booting the affected machine from the USB, which runs the recovery application and re‑installs the Windows UEFI CA 2023 entry into DB.
• If recovery from a USB fails, the fallback is to reinstall Windows from updated installation media (which should include boot files signed by the 2023 certificate once updated), then reapply Secure Boot.
• If BitLocker is enabled, it’s imperative to back up the BitLocker recovery key before attempting any Secure Boot or firmware changes — firmware resets or key reapplication can trigger BitLocker lockouts. The manage-bde -protectors -get %systemdrive% command is a standard way to obtain the 48‑digit recovery password for backup.

IT teams should test their recovery process on representative hardware ahead of time. A recommended checklist:

• Inventory devices that are unlikely to receive automatic Windows Update (air‑gapped, custom images, unsupported OEMs).
• Confirm Secure Boot state and current KEK/DB content with Confirm-SecureBootUEFI and Get-SecureBootUEFI PowerShell cmdlets on a test device.
• Create and validate a recovery USB using a device that already has the updated DB entries.
• Verify BitLocker recovery procedures and ensure recovery keys are backed up to a secure location.
• Coordinate with OEMs for firmware (BIOS/UEFI) updates that include the 2023 certificates where required.

---

Step‑by‑step: how to check and prepare (concise actionable guidance)​

Below are targeted steps for administrators and experienced users. These require administrative privileges and comfort with firmware and recovery procedures.

• Verify Secure Boot is enabled:
• Run PowerShell as Administrator and enter: Confirm‑SecureBootUEFI — True indicates Secure Boot is active.
• Inspect KEK/DB entries:
• Run: Get‑SecureBootUEFI -Name KEK (and -Name db) to view the UEFI variables.
• Back up BitLocker recovery keys:
• From an elevated prompt: manage‑bde -protectors -get %systemdrive% and store the 48‑digit key in a secure location.
• Ensure devices have the latest Windows cumulative updates:
• Use Microsoft Update, WSUS, or Windows Update for Business to apply the rollouts that contain the certificate updates.
• Create a recovery USB (on a machine already updated):
• Use the Windows “Create a recovery drive” tool on a machine with the required updates.
• Copy the recovery application: md D:\EFI\BOOT ; copy C:\windows\boot\efi\securebootrecovery.efi D:\efi\boot\bootx64.efi
• Label and store the USB securely as an emergency recovery tool.
• Test the recovery USB on a non‑production device to ensure it boots and reapplies the DB entry properly.

If a device will be kept on Windows 10 beyond October 14, 2025, arrange ESU enrollment immediately to ensure continuity of updates including certificate rollouts.

---

OEM firmware and virtualization vendors: a critical role​

This is not solely a Microsoft problem. Many OEMs set the initial firmware key databases and are responsible for shipping BIOS/UEFI updates that include the new CA entries for systems where the OEM‑installed firmware does not permit DB updates via Windows Update.

• Check OEM advisories and update portals for BIOS/UEFI updates that explicitly add the 2023 certificate chain.
• For servers and enterprise hardware, vendors such as Dell, HP, Lenovo, and others have published guidance and BIOS update schedules for affected platforms — administrators should treat firmware updates as part of the remediation plan.
• Virtualization and cloud vendors must update virtual firmware images or provide mechanisms to propagate updated DB/KEK variables into guest VMs. Confirm with cloud and hypervisor providers whether their VM images will include the 2023 certificates or provide a way for guests to accept updates.

Do not assume all OEMs will ship updates for legacy devices. Devices beyond vendor support lifetimes may require manual recovery procedures or replacement planning.

---

Special considerations: Linux, dual‑boot, and legacy appliances​

The Secure Boot certificate timeline also intersects with Linux and other OS ecosystems:

• Many Linux distributions rely on a Microsoft‑signed shim binary to work under Secure Boot on consumer hardware. A separate Microsoft signing key used by many distros had a different expiration window (notably in 2025), already creating boot compatibility issues for some distributions.
• If firmware doesn’t include the 2023 certificates, updated Linux bootloaders and signed shims may not be trusted, forcing users either to disable Secure Boot (which reduces security), manually enroll keys, or use vendor firmware updates.
• Embedded systems, appliances, and specialized hardware may have no guaranteed update path. These devices should be inventoried and replaced if they cannot accept updated trust material.

---

What enterprises should do now: prioritized roadmap​

For IT leaders, time is the critical factor. A practical prioritized roadmap:

• Inventory: Identify devices that are air‑gapped, unmanaged, running unsupported OS versions, or aging hardware that may not receive firmware updates.
• Patch and update: Ensure all devices are fully patched with the cumulative updates that include Secure Boot update capabilities.
• Coordinate OEM updates: Track firmware updates from hardware vendors and schedule BIOS/UEFI updates; include firmware updates in change windows and test on pilot groups.
• Test recovery: Build and validate recovery USB images and rehearse recovery steps for representative hardware and VM images.
• Back up keys: Confirm BitLocker recovery key backups and document recovery procedures.
• Communicate: Tell help desks and endpoint teams about the risk and recovery steps. Prepare user guidance for potential boot issues after firmware resets.
• Plan for end‑of‑life OS: For Windows 10 systems staying in service, enroll in ESU or schedule migrations to supported platforms.

---

Strengths and limitations of Microsoft’s approach​

Microsoft’s plan to deliver updated certificates via Windows Update is the right practical approach for mass remediation: it minimizes manual work for consumers and many enterprises and leverages Microsoft’s existing servicing channels. Offering recovery tools and explicit KB guidance is also a strong move that helps administrators build tested playbooks.
However, there are limitations and risks:

• Rollout completeness is not guaranteed. Not every device will be reachable by Windows Update, and not all OEMs will ship firmware updates for older hardware. This creates a patchwork of protected and unprotected systems.
• Air‑gapped and regulated environments face operational friction — the manual recovery process is reasonably well‑documented but requires prior planning.
• User error and firmware resets remain a gap. If users or service technicians reset Secure Boot variables without a recovery plan, affected machines may be temporarily unusable and require technical intervention.
• Linux and third‑party ecosystems still depend on vendor cooperation. The separate expiration events impacting Linux shims have already demonstrated friction and incompatibility risks.

Given these constraints, organizations that treat firmware and boot integrity as an afterthought will likely face the worst outcomes. The issue highlights that firmware security and certificate management are now operational responsibilities for both vendors and IT teams.

---

Final analysis and risk posture​

The Secure Boot certificate expiration is a calendar‑driven, high‑impact maintenance event that exposes the boot layer to measurable risk if not addressed. The remediation path is straightforward for devices that receive Microsoft‑managed updates, but the complexity of real‑world IT environments — offline systems, unsupported hardware, diverse OEM behaviors, virtualization platforms, and non‑Windows OSes — means many organizations must act deliberately.
Key takeaways:

• Treat this as a scheduled security event: inventory, patch, test, and communicate now.
• Do not assume that a device “will be fine” simply because it boots today; the primary risk is losing the ability to receive future security updates to pre‑boot components.
• Back up BitLocker recovery keys and rehearsal recovery procedures before any firmware changes.
• Coordinate with OEMs and virtualization/cloud providers to ensure the 2023 certificates are present in firmware images where Windows Update cannot reach.
• For Windows 10 installations kept beyond October 14, 2025, ensure ESU enrollment to preserve update flow.

This is an operational challenge with security consequences — and one where avoidance or delay increases systemic risk. The good news is that the technical mitigations exist and are being distributed; the hard work is programmatic: inventorying, testing, and applying them proactively before the June 2026 and October 2026 expiration dates arrive.

---

Conclusion
The impending expiration of the 2011 Secure Boot certificates is not a theoretical vulnerability — it is a scheduled change that transforms the way trust is established at system boot. Microsoft’s update path and recovery tooling will protect many systems automatically, but significant cohorts of devices will require active management. Organizations must move now: audit device fleets, confirm update coverage, coordinate firmware updates with OEMs and virtualization providers, back up critical recovery keys, and test recovery media. Failure to prepare risks leaving devices unable to receive critical boot‑level security patches and exposed to bootkit‑style persistence that is extremely costly to detect and remediate. The window for proactive action is limited; a disciplined remediation program now will prevent a far more painful remediation later.

---

Source: Windows Report Windows Secure Boot Certificates Expire in 2026, Microsoft Warns of Update Risks