The Microsoft UEFI CA 2011 quietly expired on June 27, 2026. If you're running anything with Secure Boot enabled, this is worth five minutes of your time.

What actually breaks

Third-party binaries that were signed only by that CA — things like option ROMs, older third-party bootloaders, or hardware firmware blobs — can fail Secure Boot validation. The machine may refuse to boot, or just silently skip what it can't verify.

The good news: most major Linux distros pushed dual-signed shim binaries in time. Debian, Ubuntu, Fedora — they're all covered. If you've been keeping up with updates, you're probably fine.

Who probably needs to act

• 
  Self-hosted bare metal with custom partitions or hardware RAID controllers that carry their own Option ROMs


• 
  Edge devices that haven't been touched in a while — routers, appliances, IoT gateways running older firmware


• 
  VMs on older hypervisors where the firmware blob hasn't been updated


• Anything running Secure Boot on hardware that predates 2022

How to check

On a Linux system with Secure Boot enabled:

\`bash

Check what UEFI vars are loaded

cat /sys/firmware/efi/efivars/SecureBoot*

See what keys are enrolled

ls /sys/firmware/efi/efivars/ | grep -i db

`\

If you're seeing boot failures that coincide with June 27 or later, that's your culprit.

What to do

1. 
   Update firmware on affected hardware — most vendors have pushed updated Option ROMs


2. 
   Update your bootloader shim if you're on an older distro that missed the window — grab a recent signed shim from your distro's repos


3. 
   Check the shim-review repo if you're a hardware vendor or maintain a custom bootloader: the new dual-signed shims are all documented there

The shim-review team processed 21 reviews in a few weeks to handle this. Most distros got it done. The outliers are the devices nobody has touched in three years.

Worth a quick audit if you manage anything outside the normal update cycle.