The date has passed; checking still matters
As of September 24, 2026, this transition is no longer a warning about a future date: the Microsoft Corporation UEFI CA 2011 certificate stopped being used for new signatures on June 26. Microsoft moved the signing of third-party UEFI applications to the 2023 authorities, including Microsoft UEFI CA 2023; Option ROMs have a separate 2023 authority. The precise date matters because some earlier headlines made it sound as if Secure Boot itself had an expiry date. It does not: specific certificates used to sign certain components are what expire. (Microsoft’s Linux distribution guidance)
Secure Boot is a UEFI firmware feature that checks the signatures of boot programs before allowing them to run. The chain may include the operating system’s boot manager, intermediate loaders, and UEFI drivers, including firmware components known as Option ROMs. The db trust database contains authorized certificates or images; the dbx revocation database identifies items that must not load. A PC’s status therefore depends on the keys registered in its firmware and on the specific signatures of the components it tries to start, not simply on the age of the machine. (Microsoft’s OEM Secure Boot overview)
Expiration is not the same as revocation
The essential distinction is between stopping the issuance of new signatures with a certificate and revoking trust in that certificate or in a program signed with it. Expiration of the 2011 certificate prevents it from being used to sign new components through Microsoft’s process; on its own, it does not remove the key from the firmware’s db database or automatically invalidate every file signed earlier. Microsoft says that a Linux shim already signed by the 2011 authority may continue to boot if the firmware retains that authority and the shim or its SBAT level has not been revoked. (Microsoft’s Linux distribution guidance)
Revocation is a separate action: dbx entries can block particular certificates or components. If an image appears on both the trust list and the revocation list, revocation takes precedence. A computer may therefore still start an older loader today while not being ready to receive a corrected future version signed only with 2023. Booting successfully does not prove that the chain is up to date: it confirms only that the firmware accepts the boot path used for that particular start. (Microsoft’s OEM Secure Boot overview)
What Windows and a typical desktop user may notice
For Windows, Microsoft says a device without the new certificates may continue to boot and install ordinary updates. The main consequence is forward-looking: the PC might not receive or validate future protections and updates that affect the pre-boot environment, such as the boot manager and other early-start components. This does not mean Windows will stop working the day after expiration, nor that every computer needs an immediate BIOS update. Compatibility depends on the model, the OEM firmware, and the actual state of its key databases. (Microsoft’s certificate update guidance)
Microsoft’s page for users and administrators describes higher-risk scenarios when firmware is old or the update process fails: validation errors, BitLocker recovery prompts, startup blocks, or inability to boot. These are possible issues associated with particular circumstances, not an inevitable consequence of the calendar reaching a certain date. The sensible recommendation is to keep Windows and firmware current through the manufacturer’s official channels, and not to change UEFI keys independently in an attempt to get ahead. If an organization manages the computer, follow its procedure and do not begin manual changes. (Microsoft’s certificate update guidance)
Linux and dual boot: the pairing of signatures and keys matters
On Linux, the usual intermediate component in many Secure Boot distributions is shim: the firmware validates its signature, and shim verifies the next elements in the chain, such as GRUB and the kernel. Microsoft documents two possible mismatches: a system whose firmware trusts only the 2023 CA will not accept a shim signed only by the 2011 CA; and a system that trusts only 2011 will not accept a shim signed only by 2023. In either case, simply installing “the newest version” is not enough: the installed loader and the certificates trusted by the firmware must be compatible. (Microsoft’s Linux distribution guidance)
For dual boot, Windows may act as a delivery channel for some updates on compatible computers, but that does not prove the Linux loader or every distribution is ready. Maintainers need to publish components signed by the new authorities, check that target firmware recognizes them, and account for revocation lists and SBAT policy. Red Hat, for example, recommends updating both the firmware trust database when a suitable update is available and the distribution’s shim; it also warns that simply revoking the 2011 certificate may prevent components that still depend on it from booting. Do not extrapolate one distribution’s schedule to all the others. (Microsoft’s Linux distribution guidance)
How to check the status without changing keys blindly
On a home Windows PC, check Windows Update and the Device security > Secure Boot section of the Windows Security app, if it is available in your version. Microsoft documents notices and status information about certificate updates; on managed computers, visibility and deployment may be controlled differently. For administrators, the documentation points to indicators such as the UEFICA2023Status registry value and system events, including events 1801 and 1795. These details can help distinguish a pending update from a firmware error, but users should not interpret a single message without checking the guidance for their edition and device. (Microsoft Windows release health)
On Linux distributions, tools such as mokutil can show whether Secure Boot is enabled and inspect certificates in the firmware database; Red Hat’s guide also explains how to identify shim signatures. Interpret the result carefully: seeing a 2023 CA does not by itself guarantee that every component is current, and not seeing one may matter for a new boot path without meaning the computer will fail now. On a system with encryption, measured boot, or automatic unlocking tied to the TPM, changing UEFI databases can alter measurements such as PCR7 and may require configuration changes. Take an inventory before changing anything. (Red Hat’s Secure Boot certificate guidance)
What to do if the manufacturer does not offer an update
First identify the exact motherboard or desktop model and consult its support page: UEFI database updates often depend on the firmware manufacturer or OEM. In Windows, install updates offered through Windows Update and check the status reported by the system; on Linux, use the mechanism recommended by the distribution, such as fwupd when the device and update are supported. On managed computers, a pilot and gradual rollout are safer than applying a change to an entire fleet without validation, especially where BitLocker, dual boot, or custom key policies are involved. Microsoft recommends checking OEM firmware first and testing representative updates before expanding deployment. (Microsoft’s certificate update guidance)
If no firmware update is available, there is no universal answer that guarantees future compatibility. Ask the manufacturer and the specific distribution for guidance, keep BitLocker recovery information and important data available, and avoid deleting the old CA, writing UEFI variables using generic instructions, or disabling Secure Boot as an automatic reaction. Red Hat warns that removing or revoking the 2011 authority may disable loaders or Option ROMs that depend on it; Microsoft also describes incompatible configurations that can prevent booting. The practical conclusion is limited: expiration alone does not switch off a desktop, but updating and checking the trust chain helps preserve the ability to receive future boot signatures and protections. (Red Hat’s Secure Boot certificate guidance)