Microsoft Secure Boot was supposed to be the lock on the front door. Instead, ESET research argues it was, for about a decade, “a busted lock” thanks to 11 vulnerable UEFI shim bootloaders that could be exploited to run dubious code during boot. The key twist is that the bad code could persist beyond hard drive swaps and even survive OS reinstallations, because the compromise happened at the firmware boot path, not inside the installed operating system.

Those vulnerable shims were the bridge between UEFI firmware and operating systems like Linux, and the scope was wider than people often assume. Microsoft has revoked the permission it once granted to the affected shims. ESET and the reporting cited in the piece connect the dots: the revocation happened in Microsoft’s June monthly patch release, after ESET reported the 11 vulnerable shims in February. For decision-makers, the headline implication is brutal but clear: there was a long window where trusted boot components could be abused, and it took months for the “do not allow this anymore” switch to be flipped.

To understand why this matters, you have to know what Secure Boot is actually trying to do. “Unified Extensible Firmware Interface (UEFI)” is a firmware architecture spec that initializes hardware and then hands control to your OS during startup. Secure Boot is the safety precaution layered on top. It requires cryptographically signed certificates from UEFI apps before they can run, with the goal of rooting out boot kits.

Shims enter because not every operating system ships in a way that maps neatly to firmware trust stores. In this setup, shims are little bridges of code that allow a motherboard’s UEFI firmware to communicate with operating systems like Linux. They let Linux boot with Secure Boot enabled without requiring a key for every distribution to be registered in the motherboard’s NVRAM settings. That convenience is also the attack surface. The piece explains that third-party boot components like shims are often signed with “Microsoft Corporation UEFI CA 2011” so they work with Secure Boot.

Now, layer in the trust mechanics and the timeline. ESET researchers identified and reported 11 vulnerable shims back in February, and the affected images could be exploited to bypass the motherboard-level protection. Microsoft’s eventual move was to revoke the permission it once granted to those shims, so bad actors could not keep leveraging them as a bypass. The reporting notes that ESET highlighted at least one vulnerability had already been well documented a decade ago. That detail is a huge oversight flag because the whole point of Secure Boot is to prevent exactly the kind of persistence described here.

The other second-order problem is operational, not just technical. The article says malicious firmware installed this way could then survive swapping out the hard drive or persist past reinstalling your operating system. That shifts the incident response burden. A typical “reinstall Windows” story, or swapping a drive, is no longer the end of the investigation. Executives overseeing IT security, incident response readiness, or device fleets need to treat boot chain compromise as a different category of event, with different containment steps and potentially longer recovery timelines.

The scope also spans ecosystems. The vulnerable shims were part of various tools and software packages, including Linux distros and PC diagnostics software. CERT compiled a helpful list of the affected shims. And the reporting makes clear the issue wasn’t confined to one OS. It affected both Linux and Windows users, because shims and shim behavior can show up in Windows contexts too. Another twist: bad actors could introduce their own copy of an affected shim to a vulnerable system. That means the risk is not limited to a single vendor image, and it complicates trust decisions for anyone shipping, bundling, or validating boot-related components.

Microsoft’s revocation timing is the part that should keep boards and security leaders up. The piece states Microsoft only revoked the shims’ permissions in the June monthly patch release. So even if mitigation is “install updates,” the delay between February identification and June revocation defines the exposure window. For leaders, this is where the governance lessons land. Trust ecosystems depend on fast revocations and tight lifecycle controls for signed components. If permissions remain valid longer than they should, the damage can persist in ways that bypass ordinary software hygiene.

Finally, there’s an industry-level incentive mismatch worth watching. Secure Boot relies on a chain of trust, but shims are explicitly there to extend Secure Boot support to ecosystems that would otherwise be locked out. When vulnerabilities exist in that bridge layer, the impact lands across multiple OS communities, creating an outsized consequence for the vendor controlling the trust permissions. The strategic stakes for peers in similar roles are straightforward: if your security posture assumes that OS-level reinstall clears the problem, this kind of firmware-level persistence breaks that assumption. It also raises the bar for how quickly “revocation” happens once researchers warn you, because boot security is measured in windows, not intentions.