Secure Boot was supposed to make a simple promise: if firmware is signed, the platform will boot safely. Ars Technica reports that this promise has been effectively broken for 13 of its 14 years, because Microsoft-signed “shims” were not revoked after vulnerabilities were found. The key word is “signed.” ESET found old, publicly available firmware images that should have been dead, but still carried Microsoft’s blessing.

ESET’s researchers identified 11 firmware images, including at least one from 2013, that were known to be defective but remained signed by Microsoft anyway. These images are called “shims,” and they were invented to extend Secure Boot to Linux devices and utility software. The punchline is not academic. Using a technique simple enough for novice hackers, an attacker can use those forgotten shims to completely bypass the protection embedded into the UEFI firmware on the motherboard.

To understand why this matters so much to executives, you have to connect the dots between firmware trust and operational reality. Secure Boot is embedded in UEFI, the earliest stage of the boot chain. That means the defense is meant to prevent malicious code from loading before the operating system even gets its turn. But the Ars account says attackers can subvert the mandated chain of digitally signed firmware, then install malicious firmware that loads early in the boot process. Because it is in firmware, it does not care whether the OS is reinstalled or whether a hard drive is replaced. For teams who assumed “wipe the disk” or “reimage the machine” is enough, this is the kind of gap that turns incident response into a longer, harder war.

There is also a cross-platform catch. The threat extends to Windows and Linux users alike because the shim can be installed on devices running both operating systems. That is a big deal for enterprise security programs, which often separate responsibilities. Microsoft-focused teams may be watching Secure Boot behavior for Windows fleets, while Linux-focused teams look at distro-level hardening. Here, the same underlying firmware mechanism can be abused to reach both.

The immediate “how” is essentially a revocation failure plus a known design goal. Microsoft oversees the signing of shims. According to the report, Microsoft failed to revoke publicly available images once vulnerabilities were found in them. That is an accountability moment, but it is also an engineering reality check. In secure ecosystems, revocation is the safety valve. If a valve stays open, the system remains only as strong as the oldest, most forgettable artifacts still sitting on the internet. ESET’s finding that at least one defective image dates back to 2013 suggests this was not a short-lived slip. It persisted across years because the images remained available and signed.

Second-order implications land on boards and leadership teams because they change what “assured boot” means as an assurance claim. If Secure Boot can be bypassed using old, forgotten shims, then the practical value of Secure Boot in risk models may decline for affected configurations. This also complicates vendor management. Many enterprises rely on OEM and platform vendors to implement UEFI correctly, then rely on Microsoft signing infrastructure and Secure Boot semantics to establish trust. A revocation gap introduces uncertainty at the exact layer that should reduce uncertainty: the earliest boot stage.

There is also a market and regulatory framing angle. Governments and regulators increasingly care about software and supply-chain integrity, and early-boot protections are often cited as part of a broader “secure-by-design” posture. When a widely used protection is bypassable for 13 of 14 years, it becomes much easier for auditors, procurement teams, and incident lawyers to ask uncomfortable questions. Were compensating controls assumed? Were warranties and assurances based on Secure Boot being effective in practice, not just in theory? Even without inventing policy details, the direction is clear: assurance programs prefer revocable, actively managed trust, not trust anchored to artifacts that linger.

For executives at other platform, endpoint, and security companies, the strategic stakes are straightforward. Secure Boot is a shared foundation across Windows and Linux devices through UEFI. If the foundation can be bypassed by leveraging signed shims that were not revoked, then peers should treat firmware integrity as a living operational problem, not a set-and-forget feature. The report from ESET is a reminder that the security lifecycle does not end at signing. It ends when vulnerable artifacts are actually removed from the world they can still be used in.