The EXODUS: Windows Secure Boot Kills Linux on June 24th! - YouTube
Linux · Security · UEFI Secure Boot
What Every Linux User Must Know Before June 27, 2026
A guide to the Microsoft Secure Boot crisis — from the SBAT disaster of August 2024 to the certificate expiration looming now — and exactly what you need to do to protect your system.
"Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed."
The machine shuts itself off. Your files are still there. Your operating system is still installed. But the firmware — the code that runs before any operating system — refuses to let it start. This is not hypothetical. This is exactly what happened to tens of thousands of dual-boot Linux users in August 2024. And a second, larger crisis is now unfolding in June 2026.
Part I: Understanding the Architecture — A Brief Tutorial
To understand what is happening, you need to understand a small slice of how a modern computer actually starts. When you press the power button, the very first code that runs is not Linux or Windows. It is the UEFI firmware — a program baked into chips on your motherboard by the manufacturer.
In the early 2010s, the UEFI Consortium introduced a feature called Secure Boot. The stated purpose was legitimate: prevent malware from inserting itself into the boot process before any operating system loads — a particularly vicious class of attack called a bootkit or rootkit. Secure Boot addresses this by requiring that every piece of software in the boot chain carry a valid cryptographic signature. If the firmware does not recognize the signature, the software does not run.
"Secure Boot is a UEFI firmware security feature that ensures only immutable and signed software are loaded during boot time." — Ubuntu Security Documentation
This is sound security engineering. The problem — the one that critics raised loudly in 2012 when Secure Boot was first mandated for Windows 8 hardware certification, and that has never gone away — is the question of who controls the keys.
The Microsoft Certificate Authority
On the overwhelming majority of personal computers sold in the world, the institution that manages the root of trust is Microsoft. Hardware manufacturers ship machines with Microsoft's certificates pre-enrolled in the firmware. Anything signed by Microsoft's certificate authority will boot. Anything not signed by it will not.
For Linux, this created an immediate problem. Canonical, Red Hat, and other distribution vendors are not Microsoft. Their bootloaders are not signed by Microsoft. The engineering solution the community invented is called shim.
How Shim Works
Shim is a thin, minimal first-stage bootloader. It carries a Microsoft signature, so the firmware accepts it. Shim then loads the actual Linux bootloader — typically GRUB — using Linux's own distribution-specific keys embedded inside shim itself. Ubuntu's shim uses Canonical's key; Red Hat's shim uses Red Hat's key. The chain looks like this:
UEFI Firmware (trusts Microsoft CA)
└── Shim (signed by Microsoft CA)
└── GRUB (signed by distro key embedded in Shim)
└── Linux Kernel (signed by distro key)
This architecture worked — imperfectly, with constant maintenance overhead — for over a decade. Then two events broke it: one in August 2024, and one approaching now.
Part II: The August 2024 Disaster — What Happened and Why
On August 13, 2024, Microsoft released a security update — KB5041585 for Windows 11 — intended to block older, vulnerable bootloaders by implementing a technology called SBAT: Secure Boot Advanced Targeting.
SBAT is actually an open-source community invention. Unlike the older DBX blacklist (a database of banned UEFI executables that has a hard size limit), SBAT uses a lightweight metadata system embedded in bootloader binaries that allows specific component versions to be revoked without burning through the limited DBX space. Linux distributions were already using SBAT to revoke their own vulnerable bootloader versions.
Microsoft's August 2024 update applied an SBAT revocation list to Windows machines. The stated goal: block shim versions with known security vulnerabilities related to the BlackLotus UEFI bootkit (CVE-2023-24932). Microsoft's own documentation said the update would not be applied to dual-boot systems.
⚠ What Actually Happened
The dual-boot detection logic failed. On a significant number of systems running both Windows and Linux, the SBAT revocation list was applied even though Linux was present. The firmware then refused to load the now-revoked shim versions. Dual-boot users booted into Windows one day, and the next morning found that Linux would not start — displaying the error: "Verifying shim SBAT data failed: Security Policy Violation."
Affected distributions included Ubuntu, Debian, Linux Mint, and others. Users who had never heard the phrase "Secure Boot" suddenly found themselves in a technical nightmare not of their making. Microsoft responded within days with a workaround involving registry edits, but the underlying fix — corrected detection logic — was not released until May 13, 2025, nine months after the original incident.
"This issue was resolved by Windows updates released May 13, 2025 [...]. We recommend you install the latest update for your device as it contains important improvements and issue resolutions, including this one." — Microsoft Windows Release Health Dashboard
The episode revealed two structural problems that go beyond the specific bug. First, a decision made by one company — pushed silently through an automated update mechanism — could render the Linux installations of tens of thousands of people non-functional overnight. Second, the communication gap was severe: users learned about the problem from error messages, not from advance notice.
Part III: The June 2026 Crisis — Certificates That Are Expiring Right Now
The 2024 SBAT incident was a bug — an unintended consequence of detection logic that failed. The 2026 situation is something different: a planned infrastructure event that has been in motion since 2023 and is now reaching its critical phase.
The Microsoft certificates that underpin Secure Boot for nearly all personal computers sold since 2012 were originally issued in 2011. They are expiring.
JUNE 24, 2026
Microsoft Corporation KEK CA 2011 — Expires
The Key Exchange Key certificate is the credential that authorizes Windows Update to push new entries to the Secure Boot allow list (DB) and deny list (DBX). When this expires, no new revocations can reach the device through the standard update pathway. Systems keep booting, but their Secure Boot posture becomes frozen — unable to receive future security updates at the firmware level.
JUNE 27, 2026
Microsoft Corporation UEFI CA 2011 — Expires
This is the certificate that signs third-party bootloaders — including Linux shim. After expiration, Microsoft can no longer sign new shim binaries with this key. New shim versions, signed only with the old key, will not be usable on machines that have already transitioned to the 2023 certificates. Linux installation media that ships outdated shim may fail to boot on updated systems.
OCTOBER 19, 2026
Microsoft Windows Production PCA 2011 — Expires
This certificate signs the Windows bootloader itself. This is Microsoft's own problem to solve, and it will — but the expiration underscores that the entire 2011-era Secure Boot infrastructure is being retired simultaneously.
Critical Clarification: Will Your Machine Become a Brick on June 27?
✓ Important: No, your machine will not stop booting
Secure Boot firmware does not enforce certificate expiration dates at boot time. The firmware has no reliable way to verify the hardware clock during the boot sequence, so it does not check whether a certificate has passed its expiration date. Machines using existing, already-installed shim binaries signed with the 2011 key will continue to boot after June 27, 2026. What expires is Microsoft's ability to sign new binaries with the old key — not the validity of already-installed software.
What the expiration does affect, immediately and concretely:
New installations. If you try to install a Linux distribution after the transition using installation media containing an old shim, on a system that has already enrolled the 2023 certificates and revoked the 2011 chain, the installer will fail to boot. This is the scenario most likely to affect ordinary users in the months ahead.
Frozen security posture. On machines that do not receive the 2023 KEK certificate, the Secure Boot deny list (DBX) cannot be updated. Future bootkit vulnerabilities — the kind of attack Secure Boot was designed to block — cannot be revoked on these machines. The machine keeps booting, but its boot-level security is now static.
Legacy hardware. Older machines that cannot receive OEM firmware updates containing the 2023 certificates face a genuine long-term problem. Their hardware may eventually be unable to boot newly signed software from any vendor.
Part IV: Who Is Affected and How — Your Situation
| Your Setup | Risk Level | Primary Concern |
|---|---|---|
| Linux only, modern hardware, Secure Boot on | Action Needed | Update shim to dual-signed version before your distro transitions to 2023-only signing |
| Linux only, Secure Boot disabled | Lower Risk | No immediate boot failure; monitor your distro's advisories |
| Dual-boot Windows + Linux, Windows up to date (May 2025+ patches) | Action Needed | Update Linux shim; the 2024 SBAT bug is fixed but certificate transition still requires attention |
| Dual-boot, Windows not updated since August 2024 | Urgent | Apply May 2025 Windows patches first; then update Linux shim |
| Legacy hardware (pre-2015), no OEM firmware updates available | Urgent | You may not be able to enroll the 2023 certs; plan ahead (see Step 6) |
| Windows only, considering trying Linux | Aware | Download fresh installation media — do not use ISOs older than early 2026 |
Major Distribution Status
Every major Linux distribution has issued formal advisories. The situation as of June 2026:
| Distribution | Status | Action |
|---|---|---|
| Red Hat Enterprise Linux 9 / 10 | Updated | New dual-signed shim released May 2026. Run dnf update shim-x64 |
| Red Hat Enterprise Linux 8 | Updated | Update released June 2026. Run dnf update shim-x64 |
| Ubuntu 22.04 LTS / 24.04 LTS | Updated | Run sudo apt update && sudo apt upgrade shim-signed |
| Fedora 39 / 40 / 41 | Updated | Run sudo dnf update shim-x64 |
| Debian 12 (Bookworm) | Updated | Run sudo apt update && sudo apt upgrade shim-signed |
| Linux Mint 21.x | Updated | Update through Update Manager; ensure shim-signed is current |
| Rocky Linux / AlmaLinux | In Progress | Check official advisories; CIQ is shipping dual-signed shim for Rocky |
| Arch Linux / Manjaro | Check Required | Arch uses a different boot setup; consult the Arch Wiki Secure Boot page |
| Older / unmaintained distros | Vulnerable | Consider migrating to a supported release |
Part V: The Step-by-Step Action Plan
Work through these steps in order. Each one builds on the last. If you get stuck, the Linux community forums have distribution-specific threads for every scenario described below.
Open a terminal and run:
mokutil --sb-state
This tells you whether Secure Boot is active on your system. If it reports SecureBoot enabled,
the steps below are essential. If it reports disabled, you have more
flexibility but should still update your shim for future-proofing.
On a dual-boot system, also check whether the 2024 SBAT issue affected you. Boot into Linux. If you cannot, skip to Step 7 (Recovery).
This step is non-negotiable. Certificate and bootloader operations touch the deepest layers of your system. A mistake can leave a machine that will not start. An external backup means the worst case is hours of recovery time, not lost data.
The simplest approach for most users:
sudo apt install clonezilla # Debian/Ubuntu # Or use your distro's equivalent
Alternatively, boot a live USB of your distribution and use Clonezilla or GParted to image your Linux partition to an external drive. Store that drive somewhere physically separate from the machine. Do this before running any updates in the steps below.
This is the single most important technical action. Install the updated shim — dual-signed with both the 2011 and 2023 Microsoft certificates — so your system can boot regardless of which certificate set your firmware trusts.
Debian / Ubuntu / Linux Mint:
sudo apt update sudo apt upgrade shim-signed grub-efi-amd64-signed
Fedora / Red Hat / CentOS Stream / AlmaLinux:
sudo dnf update shim-x64 grub2-efi-x64
Arch Linux: Arch does not use the standard shim approach. Consult the Arch Wiki page on Unified Extensible Firmware Interface for the sbctl-based workflow appropriate to your setup.
After updating, verify the installed shim version:
rpm -q shim-x64 # On RPM-based systems dpkg -l | grep shim-signed # On Debian-based systems
If you are running Windows alongside Linux and you have not applied Windows updates since before August 2024, do this before anything else:
Boot into Windows → Settings → Windows Update → Check for
Updates. Install all available updates, specifically ensuring you have
the May 2025 Patch Tuesday update (KB5058405 for Windows
11). This fixes the detection logic that caused the 2024 SBAT incident.
Without this fix, updating Windows in the future could re-trigger the
problem.
After Windows is fully patched, boot back into Linux and proceed with Step 3.
If your hardware supports firmware updates through the Linux Vendor Firmware Service (LVFS), you can enroll the new 2023 Microsoft certificates directly from Linux:
sudo fwupdmgr get-updates sudo fwupdmgr update
Not all hardware supports this. Check first:
fwupdmgr get-devices
If your device appears in the list with available updates, proceed. If not, check your OEM's website for a BIOS/UEFI firmware update that includes the 2023 certificate set. This is especially important for older machines that do not receive automatic certificate updates through Windows Update.
If your hardware is old enough that OEM firmware updates are unavailable, and you cannot enroll the 2023 Microsoft certificates through any automated pathway, you have a more technically demanding but fully workable option: enroll your own Machine Owner Key (MOK) and sign your bootloader with it.
# Generate a key pair (run this once) openssl req -newkey rsa:2048 -nodes -keyout MOK.key \ -new -x509 -sha256 -days 3650 -subj "/CN=My MOK Key/" \ -out MOK.crt # Convert to DER format openssl x509 -outform DER -in MOK.crt -out MOK.cer # Enroll in firmware (requires reboot to confirm in MokManager) mokutil --import MOK.cer
You will be prompted to set a one-time password. On next reboot, a blue MokManager screen will appear asking you to confirm enrollment. After confirmation, your key is enrolled in the firmware's trusted key database. Detailed instructions are on the Arch Wiki (Unified Extensible Firmware Interface / Secure Boot) and Ubuntu community documentation.
Disabling Secure Boot is not the catastrophe that its name implies for most personal computer users. The practical security impact is modest for home machines: you lose protection against a class of sophisticated bootkit attacks that require physical or deep OS-level access to execute in the first place.
To disable Secure Boot, restart your machine and enter the UEFI firmware setup. The key to press during startup varies by manufacturer: usually F2, F12, Delete, or Escape. Navigate to the Security or Boot section. Set Secure Boot to Disabled. Save and exit.
Linux will boot normally without any shim verification chain. Note this does not protect against the revocation-related boot failures in the same way — it simply bypasses the entire verification system. If you are in a high-security enterprise environment, consult your security team before proceeding.
If you are reading this after the fact and your Linux installation will not start, do not panic. Your data is still there. Use this recovery path:
a. Download a fresh ISO of your Linux
distribution from its official website. Verify the checksum. Write it to
a USB drive using Balena Etcher, Rufus (on Windows), or dd.
b. Boot from the USB drive. You may need to enter your UEFI firmware (F2/F12/Delete at startup) and temporarily change the boot order, or disable Secure Boot if the live USB itself fails to boot due to the same certificate issues.
c. From the live environment, mount your installed Linux partition:
sudo mount /dev/sdaX /mnt # replace sdaX with your partition sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo chroot /mnt
d. Update the shim package from within the chroot (use the appropriate package manager command from Step 3). Exit the chroot and reboot.
Distribution-specific recovery guides will be posted on official forums for every major distribution affected. You will not be navigating this alone.
Part VI: The Structural Problem — What This Really Means
The technical steps above solve the immediate problem. But the events of 2024 and 2026 together illuminate something deeper about the architecture of trust in personal computing.
Secure Boot, as implemented on modern PC hardware, answers the question of what software your computer is permitted to run by routing that decision through a single corporate certificate authority: Microsoft. When Microsoft makes a change to that infrastructure — even a change made for legitimate security reasons — the consequences propagate to tens of millions of machines simultaneously, including machines running operating systems Microsoft does not control and did not consider in its planning.
"The architectural change worth calling out is the split of the old monolithic Microsoft UEFI CA 2011 into two distinct 2023 certificates. One signs OS bootloaders (Linux shim). The other signs third-party option ROMs. The split is a real security improvement — but it is being executed on a timeline and communication cadence that serves Windows users first." — Eclypsium Security Research, June 2026
The 2024 SBAT incident was not malicious. It was a bug in detection logic. But a bug that can brick tens of thousands of Linux installations with a single patch deployment is a bug that is only possible because of this architectural centralization.
The 2026 certificate expiration is not a bug. It is planned infrastructure maintenance. Red Hat, Ubuntu, and other major distributors have responded professionally — releasing dual-signed shim updates in advance, publishing clear advisories, coordinating with Microsoft's timeline. The system is working, in the narrow sense that the people who know what they are doing are handling it. The system is failing, in the broader sense, for ordinary users who do not follow firmware specification mailing lists and who will encounter problems during new installations for months after the transition.
The Long View: What Better Looks Like
Projects like coreboot and Libreboot represent an alternative architecture: community-controlled firmware that does not route the root of trust through any single corporate certificate authority. They remain technically demanding to deploy. But the concrete demonstrations of 2024 and 2026 — weeks of unbootable machines, nine months to ship a fix, cascading confusion for ordinary users — are precisely the kind of events that turn niche projects into mainstream necessities.
The Open Platform Firmware Foundation and the work being done at the firmware level by organizations like 9elements, 3mdeb, and others point toward a future where the answer to "who controls whether my computer starts" is "you do." That future is not here yet. But it is worth knowing it exists, and worth supporting the work that makes it possible.
Sources and Formal Citations
-
Microsoft Windows Release Health. Known Issue: Linux fails to boot after August 2024 SBAT update. Resolved May 13, 2025. (KB5058405 / KB5041585 / KB5041571 / KB5041580.)
https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-23h2 -
Bleeping Computer. "Microsoft fixes Linux boot issues on dual-boot Windows systems." May 14, 2025.
https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-linux-boot-issues-on-dual-boot-windows-systems/ -
GamingOnLinux. "Microsoft finally solve the Linux dual-boot issue after 9 months." May 19, 2025.
https://www.gamingonlinux.com/2025/05/microsoft-finally-solve-the-linux-dual-boot-issue-after-9-months/ -
Techzine Global. "Windows patch prevents Linux from booting on dual-boot systems." August 21, 2024.
https://www.techzine.eu/news/devices/123609/windows-patch-prevents-linux-from-booting-on-dual-boot-systems/ -
Heise Online. "Microsoft extends workaround for Windows SBAT update." August 26, 2024.
https://www.heise.de/en/news/Microsoft-extends-workaround-for-Windows-SBAT-update-9848078.html -
linuxsecurity.com. "Windows Update Fixes Linux Dual-Boot Boot Issues." May 15, 2025.
https://linuxsecurity.com/news/vendors-products/windows-update-fixes-linux-dual-boot-boot-issues -
Red Hat Customer Portal. "Secure Boot Certificate Changes in 2026: Guidance for RHEL Environments." Updated May–June 2026.
https://access.redhat.com/articles/7128933 -
Red Hat Developer Blog. "Secure Boot certificate changes in 2026: Guidance for RHEL environments." February 4, 2026.
https://developers.redhat.com/articles/2026/02/04/secure-boot-certificate-changes-2026-guidance-rhel-environments -
Microsoft Tech Community. "Secure Boot playbook for certificates expiring in 2026." May–June 2026.
https://techcommunity.microsoft.com/blog/windows-itpro-blog/secure-boot-playbook-for-certificates-expiring-in-2026/4469235 -
Eclypsium. "Microsoft Secure Boot Certificates Expire 2026: Enterprise Impact." June 2026.
https://eclypsium.com/blog/microsoft-secure-boot-certificates-expire-2026/ -
CIQ. "No, your Secure Boot certificate is not expiring in June." June 2026.
https://ciq.com/blog/secure-boot-uefi-ca-key-rotation-2026 -
LWN.net. "Linux and Secure Boot certificate expiration." July 16, 2025.
https://lwn.net/Articles/1029767/ -
Ubuntu Security Documentation. "UEFI Secure Boot." Updated January 22, 2026.
https://documentation.ubuntu.com/security/security-features/platform-protections/secure-boot/ -
University of Wisconsin–Madison DoIT. "Microsoft Secure Boot Certificate Expiration 2026." 2026.
https://kb.wisc.edu/159935 -
Google Cloud Documentation. "Microsoft Secure Boot certificate expiration — Compute Engine Shielded VMs." 2026.
https://docs.cloud.google.com/compute/docs/security/ms-secure-boot-certificates-expiration -
AskWoody Forums. "Act now: Secure Boot certificates expire in June 2026." June 2026.
https://www.askwoody.com/forums/topic/act-now-secure-boot-certificates-expire-in-june-2026/ -
Windows Forum. "Secure Boot 2011 KEK CA Expiration: June 2026 Migration Risks for Windows and Linux." June 2026.
https://windowsforum.com/threads/secure-boot-2011-kek-ca-expiration-june-2026-migration-risks-for-windows-linux.422139/ -
Proxmox Support Forum. "UEFI 2011 certificates expire in June 2026!" June 2026.
https://forum.proxmox.com/threads/uefi-2011-certificates-expire-in-june-2026.183799/
