Microsoft Secure Boot certificates expiring in 2026: impact, fixes, and what to do

Background

Modern PCs don’t just start running code blindly when you press the power button. Since the Windows 8 era, most consumer and business systems ship with UEFI firmware and a feature called Secure Boot. At a high level, Secure Boot ensures that only boot components signed by trusted keys can run during startup. The aim is to stop bootkits and low‑level malware from sneaking in before the operating system takes control.

Under the hood, Secure Boot is a small public key infrastructure (PKI) that lives in your motherboard’s non‑volatile memory. A few key concepts help decode the headlines:

Platform Key (PK): Establishes the owner of the Secure Boot policy—normally the OEM when the PC ships. Changing the PK is how enterprises take full control of Secure Boot.
Key Exchange Keys (KEK): Authorized entities allowed to update the allowlist and blocklist. Microsoft and OEMs typically have a KEK on consumer machines.
Allowlist (db): Certificates and hashes that are trusted to sign boot components like boot managers, shims, and drivers.
Blocklist (dbx): Revoked signatures or specific binaries that must never run (for example, vulnerable bootloaders).

Microsoft plays a central role because most PCs trust its UEFI signing infrastructure out of the box. That includes:

A certificate chain used to sign Windows boot components.
A separate “third‑party” UEFI CA that signs ecosystem loaders like the Linux shim used by many distributions.

Certificates don’t last forever. Like a driver’s license, they have an expiration date. When a long‑lived CA (certificate authority) in that chain ages out, vendors must roll to a new chain and make sure firmware trusts it. That rollover is what Microsoft is flagging now.

What happened

Microsoft has begun warning OEMs, IT administrators, and the broader ecosystem that some of the long‑standing Secure Boot signing certificates—widely trusted in PC firmware since the early 2010s—are reaching their natural end of life later in 2026. As those old roots age out, newer Windows boot components and third‑party shims will be signed by replacement certificates. If a PC’s firmware doesn’t recognize those new trust anchors, the system can refuse to start the OS, even if the OS itself is current and legitimate.

This is not a hack, a zero‑day, or a surprise revocation. It’s a scheduled cryptographic maintenance event. But because Secure Boot lives below the operating system, the fallout of getting it wrong is severe: the machine may not boot until you change firmware settings or apply updates in the right order.

Microsoft’s message boils down to three imperatives:

Firmware must learn to trust the new certs. OEMs and motherboard vendors need to ship UEFI updates that add the upcoming Microsoft trust anchors to the Secure Boot db (allowlist) or KEK store.
Operating systems will eventually be signed only by the new chain. Future Windows builds and third‑party bootloaders (notably the Linux shim) will prefer or require the new certs. That means dual‑booters and enterprises distributing custom images should verify their platforms accept the new signatures.
Users and IT need to plan the sequence. Applying a blocklist or flipping to components signed by the new chain before firmware knows about those certs can strand a system. Conversely, updating firmware first—while the OS still uses backwards‑compatible signatures—is the safe path.

This isn’t the first time boot trust changes have rattled the ecosystem. After the BlackLotus bootkit disclosures in 2023, Microsoft staged multi‑phase updates: new Windows boot manager versions, dbx revocations to kill unsafe loaders, and lengthy grace periods so OEMs could update firmware. A key lesson from that episode applies here: when trust roots or revocations change, updates across firmware, OS, and bootloaders must be coordinated.

Why expiration matters in Secure Boot

In many software signing scenarios, an expired certificate doesn’t invalidate files signed while it was valid because timestamping preserves the signing time. Secure Boot is different. Firmware doesn’t use the same timestamping model and typically validates signatures against what it currently trusts in its db and KEK. Once the ecosystem moves to binaries signed by a new CA, your firmware needs to recognize that CA—or boot will halt.

Who is most at risk

PCs that never receive UEFI firmware updates. That includes many white‑box desktops, older laptops whose vendors stopped issuing updates, and air‑gapped systems.
Machines managed outside Windows Update or LVFS (Linux Vendor Firmware Service), especially in environments where firmware updates are discouraged.
Dual‑boot Linux systems relying on the Microsoft third‑party UEFI CA for shim. If your firmware doesn’t carry the new third‑party CA, newer shims may not load.
Virtual machines with Secure Boot using static templates (e.g., on‑prem Hyper‑V or VMware) that haven’t had their Secure Boot databases refreshed.
Recovery images or offline media baked with future boot components but used on systems stuck with old firmware trust stores.

How to prepare (and verify)

Treat this like a gradual migration, not a single patch day. The basic strategy is: update firmware trust first, then consume OS and bootloader updates that use the new chain.

On Windows

Update firmware via Windows Update if your OEM participates, or visit your vendor’s support site for a BIOS/UEFI update. Read release notes; look for mention of Secure Boot db/KEK updates, “UEFI CA 2023/2025,” or trust store refreshes.
Keep Windows up to date. Microsoft often stages boot‑related changes across cumulative updates before enforcement.
To inspect Secure Boot variables from an elevated PowerShell prompt:
- Check Secure Boot status: Confirm-SecureBootUEFI
- Export the allowlist (db): Get-SecureBootUEFI -Name db -OutputFile db.bin (you can analyze this with third‑party tools)
Note: msinfo32 shows whether Secure Boot is on, but not which certificates are present.
If you manage Hyper‑V:
- Update host OS and firmware.
- Regenerate or update Secure Boot templates for Gen 2 VMs so the guest’s virtual firmware trusts the new chain.

On Linux

Update system firmware using fwupd/LVFS (fwupdmgr get-updates && sudo fwupdmgr update) on supported hardware.
Keep your distribution’s shim, GRUB, and kernel packages current. Newer shims are expected to carry signatures from the replacement Microsoft third‑party UEFI CA.
Inspect UEFI variables with efitools:
- Read allowlist: sudo efi-readvar -v db
- Verify a bootloader signature: sbverify --list your-efi-binary.efi
If you operate your own MOK (Machine Owner Key) regime, confirm your signing process and enrolled keys match what your firmware trusts today and what it will trust post‑rollover.

For enterprises

Inventory state: which device models, firmware versions, and Secure Boot variables are in circulation. Pay attention to long‑lived systems, embedded endpoints, kiosks, and labs.
Coordinate change windows: apply firmware updates first, then roll out OS images or boot media that include components signed by the new chain.
Stage recovery: have tested offline media, BitLocker recovery keys, and a plan to temporarily disable Secure Boot if a machine is stranded.
Validate virtual infrastructure: update templates and golden images for Hyper‑V, VMware, and cloud images you maintain.

Risks, edge cases, and gotchas

BitLocker prompts: Updates to boot components can change measured boot values. Some machines may ask for BitLocker recovery keys once after the change. Ensure keys are escrowed in Azure AD/AD DS or saved securely.
Dual‑boot fragility: A Windows update that adds new trust anchors can be harmless, but a later Linux shim switch to the new CA may fail on firmware that never got the trust update. Keep both OSes updated and apply firmware updates in between.
Recovery media mismatch: USB installers built later this year may carry bootloaders signed by the new chain. Using them on an older machine with stale firmware could fail to start the installer. Maintain two sets of media during the transition, and update firmware before attempting clean installs.
VM templates: Secure Boot in virtual firmware is not magical; it has the same db/KEK as physical firmware. Refresh templates so future guest OSes boot.
Rollback traps: Some vendors allow rolling back firmware. Doing so after installing OS components that assume the new trust chain can create a boot failure. Lock in a minimum firmware once you migrate.

Key takeaways

This is a planned cryptographic rollover, not a security emergency. But it’s low‑level enough to break boot if ignored.
The safe order is: update firmware trust stores first, then consume OS/bootloader updates signed by the new certificates.
Machines that never get firmware updates are the most likely to be stranded by future OS installers or bootloader updates.
Dual‑boot and enterprise imaging workflows need extra care. Validate on a pilot group before broad rollout.
Keep recovery options handy: firmware setup access, Secure Boot toggle, BitLocker keys, and alternate boot media.

What to watch next

OEM firmware releases: Expect a wave of BIOS/UEFI updates throughout 2026 adding replacement Microsoft Secure Boot trust anchors. Business‑class devices will likely get them first.
Distribution guidance: Linux vendors will publish notes on shim versions and which firmware trust anchors you need. Some may ship transitional shims for a while.
Windows update milestones: Microsoft may stage the switchover—first allowing both old and new signatures, then moving new releases fully to the new chain after enough firmware is updated.
Revocation timing: After a sufficient adoption window, older signing chains might be deprecated more aggressively. Watch for dbx updates that retire legacy, vulnerable bootloaders.
Virtualization platform updates: Hypervisors and cloud providers will refresh their Secure Boot templates. Azure, AWS, and others will communicate timelines for images that require the new chain.

FAQ

Q: Will my PC stop booting on a random day when a certificate expires?
A: Not instantly. The trouble starts when your OS or boot media use binaries signed only by the new chain and your firmware doesn’t trust that chain yet. That’s why firmware updates ahead of time are key.

Q: Can I fix this by disabling Secure Boot?
A: Temporarily, yes—most firmware lets you turn off Secure Boot, which will allow unsigned or differently signed bootloaders to run. But you lose a major protection layer. Treat it as a last‑resort recovery step, not a permanent solution.

Q: How do I know if my firmware trusts the new Microsoft certificates?
A: Vendors rarely present this in a friendly UI. On Windows, export the db with Get-SecureBootUEFI -Name db and inspect it. On Linux, use efi-readvar -v db. Release notes from your OEM’s BIOS update are often the easiest confirmation.

Q: I manage Linux desktops. What should I do?
A: Update firmware across your fleet, then ensure you’re deploying a shim version signed by the latest Microsoft third‑party UEFI CA. Test dual‑boot scenarios and keep alternate installer media during the transition.

Q: Will this trigger BitLocker recovery prompts?
A: It can, once, because measured boot values change. Make sure recovery keys are available before making firmware or bootloader changes.

Q: What about servers and VMs?
A: The same principles apply. Update server firmware, plan maintenance windows, and refresh Secure Boot variables for Gen 2 Hyper‑V VMs or UEFI‑based VMs on other hypervisors. Cloud images maintained by providers will be handled for you, but custom images you own may need updates.

Q: My device is out of support and won’t get a BIOS update. Am I stuck?
A: Not immediately. Your current OS will continue to boot. The pain arrives when you try newer OS versions or installers that rely only on the new chain. Your options then are to disable Secure Boot, replace hardware, or—in advanced setups—enroll your own keys.

Q: Is this related to the BlackLotus bootkit?
A: Indirectly. That incident accelerated the industry’s focus on keeping boot trust current and revoking unsafe loaders. The 2026 event is about certificate lifecycles; it benefits from the same careful, staged rollout practices developed during post‑BlackLotus mitigation.

Source & original reading: https://arstechnica.com/gadgets/2026/02/microsoft-sounds-the-alarm-about-secure-boot-certificates-expiring-later-this-year/

Microsoft warns: long‑trusted Secure Boot certificates are aging out—here’s what that means for your PC