Some years ago, I mentioned a report about a compromised boot image from Kaspersky labs; Microsoft initially issued a revocation of its Secure Boot Certificate, but then had to withdraw that because it caused so many problems for Windows users who couldn’t (or just wouldn’t) upgrade/replace the affected versions of Kaspersky products <https://arstechnica.com/information-technology/2020/07/new-flaw-neuters-secure-boot-but-theres-no-reason-to-panic-heres-why/>. Now it turns out Microsoft has been negligent in revoking other certificates for ancient, compromised, obsolete bootloader “shims” <https://arstechnica.com/security/2026/07/microsoft-secure-boot-has-been-broken-for-most-of-its-existence/> -- even when the repercussions of doing so would be minor, there still didn’t seem to be the will to promptly enforce the rules that the company itself created. Certificate revocation in the event of a security compromise is also a measure used in another context: with TLS/SSL certificates for securely accessing websites. In this situation, it has long been known to be a troublesome and unreliable mechanism. And so something called “OCSP” was invented as a kind of workaround, only to fall victim to its own problems. Which is why, in the TLS/SSL world, the general consensus is that the only reliable solution nowadays is to drastically shorten the validity interval of the certificates -- some are suggesting they should be valid for no longer than a week -- so the problem is (mostly) solved simply by reducing the opportunity for malicious parties to make use of compromised certificates. This solution doesn’t seem practical for Secure Boot keys, which have to be stored in UEFI flash RAM on every PC ... or could something like it be made to work? But then again, is this just another item to add to the pile of evidence that Secure Boot might be more trouble than it’s worth? From the recent article: The prospect that attackers have had the means to bypass Secure Boot for more than a decade through what amounts to hack-by-numbers scripts isn’t much of an endorsement of the mechanism proposed by Microsoft in partnership with hardware makers. As mentioned earlier, a key contributor to this debacle is its complexity. “This is a solid rebuke of the entire secure boot model,” HD Moore, a firmware security expert, CEO and founder of runZero, and a long-time critic of Secure Boot, said in an interview. His complaints include Microsoft being the de facto root of trust for the entire UEFI platform, the inability of the protection to scale sufficiently, and the ability for components to boot even after top-level certificates expire.