UEFI Secure Boot has always been a slightly uncomfortable compromise: a measure that was good enough to satisfy the requirement that platforms only run signed pre-boot code, but designed around a trust hierarchy whose root keys live in firmware that an OEM controls and that an end user rarely audits. For most of its first decade the system worked well enough in practice that the gaps between the specification and the reality were tolerable. Then BlackLotus shipped a working bootkit that bypassed Secure Boot on fully patched Windows machines by exploiting a legitimately signed but vulnerable bootloader, and the year after that the PKfail disclosure showed that hundreds of consumer and enterprise device models had shipped from the factory with Platform Keys generated by AMI's test infrastructure and never rotated to production values.
Those two incidents are different in mechanism but identical in lesson: the Secure Boot trust chain works as designed when the inputs are clean, and the inputs are not as clean as the spec assumes. The platform key, the key exchange key, the db and dbx databases, the OEM-signed shim — every link in that chain is a thing some party has to keep secret, sign correctly, and rotate when compromised, and the supply chain that does that work is significantly less mature than the one that ships application code. This post is about what that supply chain looks like in 2026 and what an operator can actually do about the parts of it they do not control.
What does the Secure Boot trust chain actually depend on?
Secure Boot is a chain of signature verifications that starts at a platform key (PK) burned into firmware by the OEM, authorizes a small set of key exchange keys (KEKs), and uses those KEKs to populate two databases — db, the list of permitted signing certificates and hashes, and dbx, the list of revoked ones. When the platform powers on, firmware verifies the bootloader it is about to execute against db, the bootloader verifies the kernel it is about to load, and the kernel verifies anything it loads at runtime if it has been configured to do so. The chain only works if every signing key is held privately, every verification is performed correctly, and every revocation is honored by the entities that maintain db and dbx.
In a well-run deployment that chain involves at least four organizations. Microsoft holds the keys that sign most third-party bootloaders. The Linux distributions hold the keys that sign their kernels and modules. The OEM holds the platform key and the integration responsibility that ensures everything is glued together properly. And the BIOS/UEFI vendor — AMI, Insyde, Phoenix — provides the firmware that hosts the trust roots. Each of those entities has its own key management practices, its own update cadence, and its own attack surface, which means the Secure Boot trust chain inherits the weakest link from each of them.
What did BlackLotus actually exploit, and why did the fix take so long?
BlackLotus was the first publicly documented UEFI bootkit that defeated Secure Boot on a stock Windows 11 machine. The technique did not require breaking signature verification; it used a legitimately signed Windows bootloader that contained CVE-2022-21894, a vulnerability that allowed the bootkit to run before the OS kernel and disable Secure Boot enforcement from there. The signed-but-vulnerable bootloader is the interesting part: once a binary is signed, removing it from the trust chain requires adding its hash to dbx, dbx has to be updated on every machine in the field, and every machine that runs the old version remains vulnerable until that update has been applied.
The Microsoft response to BlackLotus took most of 2023 to roll out because revoking a widely deployed bootloader is operationally hazardous. If you push a dbx update that revokes a bootloader before every reachable machine has installed a replacement, you brick the machines that have not. The compromise was a phased revocation with a long opt-in window, which meant that for a substantial period of time the world contained both the vulnerability and the fix, and an attacker who could get the old bootloader onto a target's disk could keep using the technique on machines that had not yet enrolled the new dbx. The supply-chain takeaway is that revocation is the hardest operation in any trust system, and Secure Boot's revocation channel was never engineered to handle a high-volume incident gracefully.
What was the PKfail disclosure, and what did it say about OEM hygiene?
PKfail, disclosed by Binarly in 2024, was a different shape of problem. Researchers found that hundreds of device models from major OEMs had been shipping production firmware with Platform Keys generated by AMI as test keys, accompanied by a comment in source code that said "DO NOT TRUST" or "DO NOT SHIP." The private halves of those keys had been leaked years earlier — in some cases as part of public source code dumps — and anyone with access to the leaked material could sign firmware that would be accepted as legitimate by every device that still trusted the test PK.
The exposure was large because OEMs rarely rotate platform keys after a device leaves the factory. The PK is supposed to be the root of trust for the device's entire lifetime, and the firmware update mechanisms that an OEM ships are generally not designed to replace it. The fix for PKfail therefore had to be device-by-device, often requires user action, and in some cases requires firmware updates from OEMs who have ended support for the affected models. The supply-chain lesson is severe: when the root key in a hardware trust system is set incorrectly at the factory, the consumer often has no realistic remediation path, and the only durable fix is procurement-side scrutiny of OEMs before purchase rather than after.
How should operators think about Secure Boot risk in 2026?
The honest framing is that Secure Boot is a useful but partial defense whose effectiveness depends on the upstream supply chain doing things you cannot directly verify. That does not mean turning it off; it means investing in the layers that compensate for its known weaknesses. TPM-based measured boot, which records what actually ran during boot into PCR values rather than just verifying signatures, gives you an attestation primitive that can detect a compromised bootloader after the fact even when Secure Boot would have accepted it. Boot integrity attestation through services like Microsoft's Device Health Attestation or open implementations such as Keylime closes the loop between "this platform booted" and "this platform booted what we expected."
The procurement side matters as much as the runtime side. OEMs that have a public process for rotating platform keys, that respond quickly to firmware advisories, and that publish CSAF VEX documents for their firmware components are meaningfully easier to operate than OEMs that do not, and the difference shows up in your mean time to remediate when the next BlackLotus or PKfail-class issue lands. Treating UEFI and BMC firmware suppliers as part of your TPRM scope rather than as opaque components of a hardware purchase is the change that separates organizations who were ready for PKfail from organizations who learned about it from a news article.
How Safeguard Helps
Safeguard ingests firmware SBOMs and attestation evidence alongside the rest of your software bill of materials, correlating Secure Boot trust roots, signed bootloader inventory, and dbx revocation state against the latest advisory data. Griffin AI can answer questions like "which of our managed laptops are still trusting AMI test platform keys" and produce a remediation plan that respects OEM update cadences. Our TPRM scoring tracks OEM and BIOS vendor responsiveness on firmware advisories, including PKfail-class disclosures, so procurement decisions can be calibrated to actual supply-chain hygiene rather than to brand reputation. Policy gates can prevent endpoints from being enrolled in production environments while running revoked bootloaders or unrotated platform keys, and our firmware-aware SBOM coverage extends from BMC and UEFI all the way through to the userspace dependencies. If you want a single view of your boot-time trust posture across the fleet, get in touch.