4 MIN READ
The firmware attack surface in 2026 is, for most enterprises, larger and more exposed than the operating system attack surface they have spent two decades learning to defend. Every modern endpoint runs firmware the OS cannot see: UEFI, BMC, NIC, hard drive controller, SSD controller, GPU, TPM, Webcam, and the dozen or so embedded controllers on the motherboard. Each one amounts to a separate processor running separate code with its own update mechanism and its own security model. The OS gets a monthly patch. The firmware gets a patch when the vendor releases one, which is often years after the vulnerability is disclosed. The threat actor does not need a zero day on the OS. The threat actor needs a one year old vulnerability on a peripheral the defender has never audited.
What is actually in your fleet
Start with the inventory. The free tool for this on Linux is the NIST maintained fwupd plugin, on Windows the Microsoft Surface firmware inventory, and for broader coverage the commercial options (DigiCert, AMI, Absolute) all work. Most organisations discover three uncomfortable facts when they run the inventory: firmware on the endpoints is months to years out of date, a non trivial percentage of endpoints are running firmware the vendor no longer patches at all, and the vendor’s own update tooling is often broken in the sense that it fails silently or applies the wrong firmware. None of this is news. All of it is still true in 2026.
The interesting attack surface in 2026 sits on the BMC, the baseboard management controller, on server class hardware. The BMC amounts to a separate computer on the motherboard that runs regardless of the main CPU state. It has its own network interface, its own web server, its own SSH, and its own firmware. The major CVEs in 2024 and 2025 (CVE-2024-54085 on HPE iLO, the AMI MegaRAC chain, the Supermicro IPMI issues) all give the threat actor remote management of the server with full firmware level access, regardless of what the main OS is doing. If the BMC is compromised, the OS is compromised, regardless of how good the EDR happens to be.
What the attackers are actually doing
Three patterns have shown up consistently through 2026. The first is ransomware crews pre positioning on firmware so that even after the OS is wiped and rebuilt, the same crew can re infect. The case studies are documented against BlackCat/ALPHV, Conti successors, and a handful of others, and the pattern looks the same every time: defender wipes the server, the firmware bootkit reinfects, the ransomware returns in 48 hours, and the defender has no idea why. Supply chain compromise of firmware update servers is the second pattern, and it is what happened with ASUS Live Update in 2018 and what still looks like a credible threat against smaller vendors. The third pattern runs through the embedded peripheral, the webcam, the network card, the printer controller. These run firmware the OS has no visibility into, and a foothold there is a foothold the EDR cannot see.
What to actually do
Inventory first, because the org cannot defend what it cannot see. Then prioritise by reachability: a BMC on a server in a public subnet is a much higher priority than a webcam controller on a workstation behind a firewall, and the gap between the two priorities is the gap the budget has to follow. Secure Boot and the measured boot chain through the TPM come next; neither prevents firmware compromise, but both detect it at boot, which is the difference between a clean recovery and a long weekend. Segment the BMC and the out of band management network from the main network so the BMC sits on its own VLAN, accessible only from a jump host. And write a firmware patch SLA into the vendor contracts, with quarterly firmware patches as the floor, or move to a vendor that will commit to them. The firmware attack surface in 2026 is not going away. The job sits as the work of shrinking the gap between the OS defender and the firmware defender so the two teams can actually see each other.
The bottom line
Firmware runs underneath the OS. The OS defender cannot see it. The firmware patch cadence runs in years, not weeks. Inventory first, then prioritise by reachability, then enable Secure Boot and TPM, then segment the BMC network. The gap is not going to close. Make the gap visible.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
