Firmware Update Security

The updates that fix vulnerabilities can also create them

CVE-2024-56161 revealed that AMD CPUs were verifying microcode signatures using... the example key from the NIST specification document. Anyone who read the public standard could sign malicious microcode that AMD processors would accept as legitimate. The root of hardware trust was protected by keys literally marked as examples. [1]

Firmware updates are supposed to fix security problems. Instead, they're increasingly becoming security problems themselves. Compromised signing keys, unsigned update mechanisms, and malicious updates masquerading as legitimate patches have turned firmware into one of the most dangerous attack surfaces in modern computing.

The Firmware Update Problem

Every device you own runs firmware - low-level code that controls hardware before your operating system loads. Your BIOS/UEFI, SSD controller, network card, keyboard, mouse, and USB hub all have firmware. Most of it can be updated. And most update mechanisms are terrifyingly insecure. [2]

What Can Go Wrong

  • No signature verification: Updates accepted without cryptographic validation
  • Weak signatures: Using example keys, weak algorithms, or compromised keys
  • Downgrade attacks: Installing older, vulnerable firmware versions
  • Supply chain compromise: Malicious updates from compromised vendor infrastructure
  • Man-in-the-middle: Updates intercepted and modified in transit
  • Local privilege escalation: Malware with admin access reflashing firmware

Real-World Failures

AMD Microcode Signing (CVE-2024-56161)

AMD's microcode signature verification used the example key from NIST SP 800-38B - a key explicitly intended for testing, not production. Researchers could sign arbitrary microcode that AMD processors would execute, potentially modifying CPU behavior at the most fundamental level. [1]

This wasn't a bug in the implementation. It was using test cryptography in production across years of processor generations.

Clevo Boot Guard Key Exposure (2025)

In October 2025, Intel Boot Guard keys for Clevo-based systems were exposed (VU#538470). Boot Guard is supposed to ensure only authorized firmware runs. With the signing keys public, anyone can create firmware that these systems will accept as legitimate. [3]

Because Boot Guard keys are fused into the CPU, affected systems cannot be fixed - the compromised trust persists for the hardware's lifetime.

PKfail (2024)

Binarly discovered that numerous manufacturers shipped devices with test Platform Keys - including keys explicitly marked "DO NOT SHIP" and "DO NOT TRUST." Secure Boot on these systems could be bypassed by anyone with the (publicly known) test keys. [4]

UEFI Vulnerabilities

2024-2025 saw a steady stream of UEFI vulnerabilities:

  • CVE-2024-7344: Microsoft-signed application bypassed Secure Boot verification entirely
  • CVE-2024-0762 (UEFICanHazBufferOverflow): Phoenix SecureCore vulnerability affecting hundreds of PC models
  • AMD Sinkhole/SinkClose: System Management Mode exploitation enabling persistent firmware-level malware
  • CVE-2025-3052: NVRAM manipulation disabling Secure Boot while reporting it as enabled

Firmware-Level Malware

MoonBounce (2022)

An advanced UEFI firmware rootkit that hid in SPI flash memory - the chip that stores BIOS/UEFI. MoonBounce persisted across OS reinstalls because it lived in hardware, not on the hard drive. Detection required specialized firmware scanning tools most organizations don't have. [5]

BlackLotus (2023)

The first in-the-wild bootkit to bypass Secure Boot on fully patched Windows 11 systems. BlackLotus installed itself into the boot chain, loaded before Windows, and persisted across updates. Microsoft's mitigation took over a year to fully deploy. [5]

BootKitty (2024)

The first UEFI bootkit targeting Linux. While created by researchers as a proof of concept, it demonstrated that Linux systems are not immune to boot-level attacks. The technical barriers to commodity UEFI malware for Linux have fallen. [6]

Why This Is Hard to Fix

Fragmented Ecosystem

Your laptop contains firmware from dozens of vendors - BIOS from one company, SSD controller from another, WiFi from a third. Each has its own update mechanism, security model, and (lack of) verification. Coordinating security across this ecosystem is nearly impossible.

Invisible Updates

Most firmware updates happen silently. Windows Update pushes BIOS updates without user awareness. Your SSD might update its controller firmware without any visible indication. You can't secure what you can't see.

Long Lifetimes

Hardware remains in service for years. Firmware vulnerabilities discovered after purchase may never get patched - manufacturers have no obligation to support devices indefinitely, and often don't.

Recovery Difficulty

Compromised firmware is hard to detect and harder to remove. Reinstalling your OS doesn't help - the malware runs before the OS loads. You may need specialized hardware tools or complete motherboard replacement.

Protecting Yourself

Update (Carefully)

  • Do apply security updates: Known vulnerabilities are more dangerous than theoretical update risks
  • Use official sources: Download firmware only from manufacturer websites or automatic updates
  • Verify when possible: Some vendors provide checksums - verify them
  • Monitor security advisories: Know when your hardware has vulnerabilities

Reduce Attack Surface

  • Disable unnecessary firmware features: Intel AMT, remote management you don't use
  • Enable Secure Boot: Imperfect but raises the bar for firmware attacks
  • Set BIOS/UEFI passwords: Prevent casual firmware modification
  • Physical security: Many firmware attacks require physical access

Choose Hardware Carefully

  • Vendors with security focus: System76, Purism, and others prioritize firmware transparency
  • Enterprise hardware: Often has better firmware security than consumer devices
  • Avoid end-of-life hardware: No firmware updates means unpatched vulnerabilities forever

Defense in Depth

  • Full disk encryption with PIN: Even if firmware is compromised, encrypted data requires your password
  • Hardware security keys: Authentication that doesn't depend on firmware integrity
  • Network segmentation: Compromised devices can't reach everything
  • Regular backups: Recovery from firmware compromise may require starting fresh

Enterprise Considerations

Organizations face additional challenges:

  • Firmware inventory: Know what firmware versions are running across your fleet
  • Automated updates: Centralized firmware management with verification
  • Boot integrity monitoring: Detect when measured boot values change unexpectedly
  • Incident response: Have plans for firmware-level compromise (it's different from OS compromise)
  • Procurement requirements: Specify firmware security requirements when buying hardware

ENISA reports that supply chain-related firmware incidents accounted for 17% of critical infrastructure breaches. [2] This isn't theoretical risk.

The Fundamental Problem

Firmware security requires trusting:

  • Hardware vendors to implement signing correctly
  • Key management to be secure across the supply chain
  • Updates to be delivered without interception
  • Vulnerabilities to be patched promptly
  • All of the above for every component in your system

This trust is frequently misplaced. AMD used example keys. Manufacturers shipped test certificates. Signing infrastructure gets compromised. Updates get delayed or abandoned. The system assumes security properties that don't exist.

The era of treating signed code as inherently safe has ended. Verification is essential - but often impossible for end users. You're trusting a chain you can't inspect, hoping each link holds.

Related Articles

References

  1. GBHackers. "Repeated Firmware Key-Management Failures Undermine Intel Boot Guard and UEFI Secure Boot." gbhackers.com
  2. Eclypsium. "The Top 5 Firmware and Hardware Attack Vectors." eclypsium.com
  3. CyberPress. "Exposure of Clevo UEFI BootGuard Keys Allows Unauthorized Firmware Signing." October 2025. cyberpress.org
  4. Binarly. "Repeatable Supply Chain Security Failures in Firmware Key Management." binarly.io
  5. FirmGuard. "6 Unparalleled UEFI BIOS Firmware Attacks." firmguard.com
  6. ESET. "Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344." January 2025. welivesecurity.com