UEFI and Secure Boot

The trusted boot chain that keeps getting compromised

In January 2025, ESET researchers disclosed CVE-2024-7344 - a Secure Boot bypass affecting "the majority of UEFI-based systems." The vulnerable application was signed by Microsoft's own certificate. Exploitation allowed running unsigned code during boot, completely bypassing the protection Secure Boot was designed to provide. This wasn't the first bypass. It won't be the last. [1]

Secure Boot is supposed to create a "chain of trust" from power-on to operating system. Each component verifies the next, ensuring only signed, trusted code runs. The reality: Secure Boot bypasses surface regularly, Microsoft controls the signing keys, and the system actively prevents you from running alternative firmware on your own hardware.

Is Secure Boot security, or is it control dressed up as security?

How UEFI Secure Boot Works

UEFI (Unified Extensible Firmware Interface) replaced traditional BIOS. Secure Boot is a UEFI feature that verifies cryptographic signatures on boot components. [2]

The Trust Chain

  1. Platform Key (PK): The root of trust, usually controlled by the hardware manufacturer
  2. Key Exchange Keys (KEK): Keys authorized to update the signature databases
  3. Signature Database (db): Hashes and certificates of trusted bootloaders
  4. Forbidden Signatures (dbx): Revoked signatures that should never run

When you power on, the firmware checks the bootloader's signature against db. If it matches a trusted signature and isn't in dbx, execution proceeds. If not, boot fails.

Microsoft's Central Role

Here's where it gets complicated. Microsoft operates as the de facto Secure Boot certificate authority. Almost all consumer hardware ships with Microsoft's certificates pre-loaded. [3]

To boot on Secure Boot systems, software needs to be:

  • Signed directly by Microsoft, OR
  • Signed by Microsoft's third-party UEFI CA (for non-Microsoft software like Linux bootloaders)

Linux distributions get their bootloaders signed through Microsoft's signing service. Without this, they couldn't boot on most consumer hardware with Secure Boot enabled.

The Bypass Problem

Secure Boot bypasses are not rare. They're recurring features of security research.

CVE-2024-7344 (January 2025)

ESET found a UEFI application signed by Microsoft's certificate that used a custom PE loader instead of standard UEFI functions. This loader would execute any binary - signed or not. [1]

The vulnerable application bypassed the entire Secure Boot verification chain. An attacker could use it to load bootkits like BlackLotus or Bootkitty, even on systems with Secure Boot enabled. Microsoft revoked the vulnerable binaries in the January 2025 Patch Tuesday.

CVE-2025-3052 and CVE-2025-47827

Binarly researchers found vulnerabilities allowing attackers to manipulate NVRAM variables, overwrite security flags, and execute unsigned code during boot. The OS would still report Secure Boot as "enabled" while protection was completely defeated. [4]

BlackLotus (2023)

The first in-the-wild bootkit to bypass Secure Boot on fully patched Windows 11 systems. BlackLotus exploited CVE-2022-21894 to inject its own boot chain, persisting across reboots and OS reinstalls. [5]

Microsoft's mitigation was slow - adding vulnerable boot loader hashes to dbx overwhelmed the available storage on many devices. Full remediation took over a year.

PKfail (2024)

Binarly discovered that many manufacturers shipped devices with test Platform Keys - including keys explicitly marked "DO NOT SHIP" and "DO NOT TRUST." These test keys allowed anyone to sign malicious bootloaders that would be accepted as trusted. [6]

Pattern Recognition

The pattern is clear: "Secure Boot bypasses continue to be a persistent issue within the UEFI ecosystem, with new vulnerabilities surfacing a few times each year." [1]

The system designed to ensure only trusted code runs keeps failing to ensure only trusted code runs.

The Control Problem

Security failures are one issue. But Secure Boot also functions as a control mechanism.

You Can't Run What You Want

Secure Boot prevents unsigned code from running at boot. That includes:

  • Coreboot and Libreboot: Open source firmware replacements are blocked on Secure Boot systems
  • Custom bootloaders: Your own code, on your own hardware, is rejected
  • Older Linux distributions: Unsigned or improperly signed bootloaders won't load
  • Recovery tools: Some legitimate utilities lack Microsoft signatures

Intel Boot Guard Makes It Permanent

Boot Guard goes further than Secure Boot. It's a hardware feature that burns cryptographic keys into the CPU at manufacture. If the firmware's signature doesn't match the fused keys, the CPU refuses to boot. [7]

Boot Guard cannot be disabled. If your laptop manufacturer enabled it (most modern systems), you physically cannot replace the BIOS with open alternatives. The CPU will refuse to execute code that isn't signed by the manufacturer's key.

This is why Libreboot's ThinkPad T480 support is significant - those laptops don't have Boot Guard enabled.

The Certificate Expiration Problem

Microsoft's UEFI certificate expires in June 2026. This affects every system released since 2012 that relies on Microsoft's certificate chain - which is nearly all of them. [8]

Microsoft's attempt to update certificates via Windows Update caused problems. The transition demonstrates how much of the boot trust chain depends on a single company's continued operation and good decisions.

Security vs Control: The Trade-off

What Secure Boot Actually Protects Against

  • Unsophisticated bootkits: Malware that doesn't have a valid signature
  • Supply chain attacks without signing access: Modified bootloaders get rejected
  • Casual tampering: Basic boot-level modifications are blocked

What Secure Boot Doesn't Protect Against

  • Attacks using signed but vulnerable components: CVE-2024-7344
  • Firmware-level compromise: UEFI vulnerabilities below Secure Boot
  • State-level attackers: Who can obtain or forge signatures
  • Supply chain attacks at manufacture: Hardware arrives pre-compromised
  • Your laptop manufacturer: They control the root keys

What Secure Boot Prevents You From Doing

  • Running open source firmware
  • Verifying your own boot chain
  • Removing yourself from Microsoft's trust ecosystem
  • Full control over your own hardware

What You Can Do

If You Need Secure Boot

Keep it enabled. For most users, it provides meaningful protection against common threats. Update your firmware when patches are available. Use Windows Update or your manufacturer's tools to keep UEFI current.

If You Want Control

Options are limited on modern hardware:

  • Disable Secure Boot: Most UEFI allows this, but you lose the protection it does provide
  • Enroll custom keys: Some systems let you replace Microsoft's keys with your own - complex but possible
  • Buy hardware without Boot Guard: ThinkPad T480, older systems, or specific vendors
  • Use Coreboot-compatible hardware: System76, Purism, or supported older machines

Defense in Depth

Don't rely on Secure Boot alone:

  • Use full disk encryption (not SSD hardware encryption - software like LUKS or VeraCrypt)
  • Keep all software updated, including UEFI firmware
  • Assume firmware could be compromised and design security accordingly
  • Use a hardware security key for authentication
  • Monitor for boot-time anomalies where possible

The Bigger Picture

Secure Boot exists in a strange middle ground. It provides real security benefits - blocking unsigned malware is genuinely useful. But it also centralizes control over boot trust in Microsoft's hands, prevents users from running alternative firmware, and fails often enough that its guarantees are questionable.

The December 2025 NSA guidance on UEFI Secure Boot acknowledges the problems while still recommending it as a security measure. [9] The practical reality: Secure Boot is better than nothing, but worse than what's promised.

The deeper question is whether you should trust a security mechanism controlled by entities you can't verify, on hardware you can't fully audit, implementing code that keeps getting bypassed. For most users, the answer is pragmatic acceptance. For high-security use cases, the answer might be hardware that doesn't require this compromise at all.

Related Articles

References

  1. ESET. "Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344." January 2025. welivesecurity.com
  2. Microsoft. "Secure Boot Overview." microsoft.com
  3. Binarly. "Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass." binarly.io
  4. Eclypsium. "Hydrophobia and other UEFI Secure Boot Bypass Vulnerabilities." eclypsium.com
  5. FirmGuard. "6 Unparalleled UEFI BIOS Firmware Attacks." firmguard.com
  6. Binarly. "Repeatable Supply Chain Security Failures in Firmware Key Management." binarly.io
  7. Intel. "Boot Guard Technical Documentation." intel.com
  8. Born's Tech. "Microsoft's UEFI Secure Boot certificate expires in June 2026." borncity.com
  9. NSA. "Guidance for Managing UEFI Secure Boot." December 2025. defense.gov