By Sarah Riggins and Dr. Hajime Inoue
Firmware is everywhere. It is inside routers, radios, cars, industrial controllers, satellite terminals, navigation equipment, mission systems, and countless other devices. Most of us rely on it every day without ever seeing it or thinking about what it does.
And that is part of what makes firmware interesting from a cybersecurity perspective. We generally know that our devices contain hardware and software. What is less obvious is the layer of software that is built into the device itself, helping the hardware work and allowing other software to make use of it.
So, what exactly is firmware?
What Is Firmware?
Firmware is software embedded inside a device that controls how the hardware operates. It provides the low-level instructions that help a device start, communicate, interact with its physical components, and perform the functions it was designed to perform.
One way to understand firmware is to think about the relationship between software and hardware. Hardware is the physical part of a system: processors, memory, circuit boards, sensors, network interfaces, and other components. Application software operates at a higher level, performing tasks for users or other systems. Firmware is software too. The difference is that it operates much closer to the hardware. Higher-level software may rely on firmware to interact with the device, while the hardware relies on those low-level instructions to operate as intended.
Consider something as familiar as a router. The processor, memory, and network interfaces are hardware. The router also contains software that provides functions such as network management and web-based administration. Inside the device is firmware that helps initialize, configure, and control how the router operates. The exact boundaries between firmware, operating systems, and applications aren’t always neat, and different devices are built differently. But the important distinction is simple: firmware is software that is closely tied to how a device and its hardware actually work.
And once you understand that, another question becomes important: How much do you actually know about the firmware inside the devices your organization depends on?
Where Is Firmware Found?
The short answer is: almost everywhere.
Firmware is found in familiar equipment such as routers and other network devices, but it is also embedded in highly specialized systems. In mission environments, firmware can be found in mission computers, radios, navigation equipment, and weapons-interface line-replaceable units (LRUs). Networks depend on firmware inside routers, switches, VPN concentrators, and satellite terminals. Installations rely on devices containing firmware to support water treatment, fueling, power distribution, HVAC, access control, and other physical processes.
Not all firmware looks the same. Some devices run embedded Linux, while others use real-time operating systems designed to respond within precise timing requirements. Simpler devices may run directly on bare-metal microcontrollers. Firmware can also be found in platform components, peripherals, programmable logic, and increasingly in hardware supporting AI-enabled systems. The technical details vary, but the basic idea does not: there is software inside these devices making them work.
In many cases, the people responsible for securing those devices have surprisingly little visibility into that software.
Has Firmware Actually Been Attacked?
Yes, and some of the most consequential cyberattacks in history have involved the low-level software that controls the physical equipment. These incidents demonstrate why firmware security matters beyond traditional concerns about stolen data or compromised applications.
One of the best-known examples is Stuxnet, discovered in 2010. This sophisticated malware targeted industrial controllers operating centrifuges at Iranian nuclear facilities. By manipulating the controllers’ programming, attackers were able to interfere with physical operations while concealing the changes from operators. Stuxnet demonstrated that malicious software could reach beyond a computer screen and cause damage to industrial equipment.
In 2017, the TRITON malware targeted industrial safety controllers at a petrochemical facility in Saudi Arabia. Unlike conventional attacks aimed at stealing information, TRITON sought to manipulate systems designed to protect industrial operations from dangerous conditions. The malware could modify running controller firmware, illustrating how attacks against embedded systems can potentially undermine the very safeguards intended to prevent physical harm.
These examples demonstrate an important point: the security of a device depends on more than the applications we can see or the networks to which it connects. The software operating inside the device matters too, and understanding what is there is an essential first step toward understanding risk.
You can find a list of notable firmware devices here: https://www.linkedin.com/pulse/notable-firmware-attacks-20072025-bryan-mossey-tyrse/
Why Is Firmware Difficult to See?
If attacks can reach the software controlling physical equipment, an obvious question follows: How can organizations know whether that software is secure? This is where firmware begins to look very different from the software most security teams are accustomed to working with. If you are analyzing source code, you have human-readable instructions written by developers that can be examined, tested, and analyzed using established tools. Even with a compiled application, the program itself is generally obtainable, although some of the names and structure that make the original source code easier to understand may be gone.
With firmware, you may get something very different: one packaged image for an entire device, with no source code, no parts list, and no symbols explaining what is inside. An organization may own the device, know who manufactured it, know the model and where it is installed, and understand exactly what job it performs without necessarily knowing exactly what software is running inside it. And importantly, a firmware image isn’t necessarily a single program.
What’s Actually Inside Firmware?
When you open a firmware image, you may find an entire collection of software. While some firmware is tiny, others are full computer systems, including file systems, operating system components, individual programs, libraries, open-source components, and other software. Each of those components may have its own version, history, and known vulnerabilities.
A real example helps put this into perspective. GrammaTech examined a 3.7-megabyte firmware update for a common internet router and, in approximately an hour of computer time, identified 164 separate programs, 219 previously catalogued vulnerabilities, three open-source components that were years out of date, and that most routine build-time protections were switched off. That’s a remarkable amount of software and security information inside a relatively small firmware file.
The point isn’t that every firmware image will contain hundreds of vulnerabilities. It is that you cannot necessarily tell what’s inside simply by looking at the device. To understand the software running inside that equipment, you first have to open the firmware and identify what is there. That brings us to FBOMs.
What Is an FBOM?
A Firmware Bill of Materials, or FBOM, is essentially an ingredients list for firmware. If you’ve heard of a Software Bill of Materials, or SBOM, the concept will sound familiar. An SBOM identifies the components that make up a piece of software. An FBOM applies that same idea specifically to the software contained within firmware. There is naturally overlap between the concepts because firmware is software.
The distinction is useful because obtaining an inventory of firmware can be considerably harder than obtaining one for conventional software. There may be no source code and no vendor-provided parts list. Instead, analysts may need to open the firmware image, recover its contents, identify components and versions, and determine what software is actually present. An FBOM turns that discovery into an inventory and helps answer a remarkably important question: What software is actually inside this device?
What Can an FBOM Tell You?
Depending on what can be recovered from the firmware, an FBOM can identify individual programs, libraries, operating-system components, open-source software, component versions, and other elements inside the firmware. Those components can then be compared with public vulnerability information to identify software associated with known security problems.
That gives defenders something they may not have had before: visibility. Once an organization understands what’s inside its firmware, it can begin asking more useful questions. Are we running an outdated component? Is there open-source software inside this device that we didn’t know about? Does the firmware contain a component associated with a known vulnerability? Is the vendor still maintaining it? An FBOM doesn’t necessarily answer all of those questions by itself, but it provides the inventory needed to start asking them intelligently.
An FBOM Is a Starting Point
There is one distinction that is especially important. If an FBOM identifies a component associated with a known vulnerability, that does not automatically mean someone can exploit that vulnerability on the device. The component may be present, but the vulnerable functionality may not be used, may not be reachable by an attacker, or may behave differently in the particular device. Those questions require deeper analysis.
That’s why an FBOM should be thought of as a starting point rather than the final answer. An FBOM tells you what is there. Further analysis helps determine what actually matters. We’ll explore that distinction in more depth later in this series.
Firmware Security Starts with Knowing What’s Inside
Firmware sounds complicated because the technology behind it can be complicated, but the basic concept doesn’t have to be. Firmware is software embedded inside a device that helps make that device work. It matters because modern devices can contain a significant amount of software, including devices that support communications, transportation, water, power, industrial processes, and mission-critical systems. Unlike the applications running on a laptop or server, however, the software inside those devices isn’t always easy to see.
An FBOM begins to change that. It takes something that may arrive as an opaque firmware image and starts answering the most fundamental question: What’s actually in here? Once you have that answer, you can begin asking the next one: What risk does all of this software introduce?