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 is 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 attacker does not need a zero day on the OS. The attacker needs a one year old vulnerability on a peripheral the defender has never audited.
What is actually in your fleet
Run an inventory first. The free tool for this is the NIST maintained fwupd plugin on Linux, the Microsoft Surface firmware inventory on Windows, or the commercial options (DigiCert, AMI, Absolute) if you need broader coverage. Most organisations discover three uncomfortable facts. First, the firmware on the endpoints is months to years out of date. Second, a non trivial percentage of endpoints are running firmware that the vendor no longer patches at all. Third, the firmware update tooling the vendor ships is often broken, in the sense that it fails silently or applies the wrong firmware. None of these are news. All of them are still true in 2026.
The interesting attack surface in 2026 is the BMC, the baseboard management controller, on server class hardware. The BMC is 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 attacker 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 your EDR is.
What the attackers are actually doing
Three patterns in 2026. The first is ransomware crews pre positioning on firmware so that even after the OS is wiped and rebuilt, the attacker can re infect. This is documented against BlackCat/ALPHV, Conti successors, and a handful of others. The defender wipes the server, the firmware bootkit reinfects, the ransomware returns in 48 hours. The defender does not know why. The second is supply chain compromise of firmware update servers, which is what happened with ASUS Live Update in 2018 and is still a credible threat against smaller vendors. The third is the embedded peripheral, the webcam, the network card, the printer controller. These run firmware the OS has no visibility into. Compromising them gives the attacker a foothold the EDR cannot see.
What to actually do
First, inventory. You cannot defend what you cannot see. Second, prioritise by reachability. The BMC on a server in a public subnet is a much higher priority than the webcam controller on a workstation behind a firewall. Third, enable Secure Boot and the measured boot chain through the TPM. This does not prevent firmware compromise, but it detects it at boot. Fourth, segment the BMC and the out of band management network from the main network. The BMC should be on its own VLAN, accessible only from a jump host. Fifth, write a firmware patch SLA into your vendor contracts. Quarterly firmware patches, or you go to a vendor that will commit to them. The firmware attack surface in 2026 is not going away. The job is to shrink the gap between the OS defender and the firmware defender so that one team can see the other.
The bottom line
Firmware runs underneath the OS. The OS defender cannot see it. The firmware patch cadence is 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.
