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)
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)
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)
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
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)
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.
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)
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)
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
