What is Firmware, and Why It Matters in OT
Firmware is the low-level software embedded in a device that controls how its hardware behaves. In an industrial environment, firmware runs on almost everything: programmable logic controllers, remote terminal units, protection relays, HMIs, network switches, sensors, and inverters. It sits beneath the applications and operating systems that security teams usually focus on, and it operates with the highest level of privilege on the device.
That combination, deeply privileged and rarely examined, makes firmware one of the most consequential and least understood parts of the OT attack surface. A compromise at the firmware level can persist through reboots, survive the reinstallation of higher-level software, and remain invisible to tools that only inspect the operating system above it. For devices that directly control physical processes, a firmware-level compromise is among the most serious outcomes an operator can face.
Firmware security has moved from a niche concern to a mainstream one, driven by growing attention to product security and supply chain integrity across critical infrastructure. Understanding the threat is the first step to managing it.
The Firmware Threat Landscape
Several distinct categories of firmware threat affect industrial devices.
Hardcoded and Backdoor Credentials
One of the most common firmware weaknesses is the presence of hardcoded credentials: usernames and passwords built into the firmware itself, sometimes intended for manufacturer support and sometimes left in by mistake. Because they are embedded in the firmware, they cannot be changed by the operator and are often identical across every unit of a product line. Advisories describing hardcoded or default credentials in industrial products appear regularly, and they represent a standing risk because a single disclosed credential can affect an entire installed base.
Defensive implication: Devices with hardcoded credentials cannot be fully secured by configuration alone. Compensating controls, especially network segmentation and access restriction, become essential, and firmware-level credential issues should weigh heavily in procurement decisions.
Malicious or Tampered Firmware Updates
Firmware is updated through images supplied by the vendor. If an update mechanism does not cryptographically verify the authenticity and integrity of a firmware image, an attacker who can deliver a modified image can install persistent malicious code. Where firmware is unsigned, or where signature verification is weak, the update process itself becomes an attack vector.
Supply Chain Implants
Because firmware is created and loaded before a device ever reaches the operator, integrity concerns extend all the way back through the supply chain. The 2025 reports of undocumented communication components discovered inside certain imported energy devices brought this concern into sharp focus for the critical infrastructure community. When a significant share of the components in a sector originate from a concentrated set of manufacturers, the integrity of what is inside a device before it is even installed becomes a strategic question.
Latent Vulnerabilities in Firmware Code
Beyond deliberate threats, firmware simply contains software, and software contains flaws. Memory-safety issues, insecure services, and weak cryptography in firmware can allow remote code execution or the arbitrary modification of device behavior. In long-lived OT devices, these flaws may remain unpatched for years.
Why Firmware Is Hard to Secure in OT
Firmware security is genuinely difficult in industrial environments, for reasons rooted in the nature of OT.
Updating is constrained. Applying a firmware update to a controller often requires a maintenance window, vendor involvement, and compatibility testing, and in some cases a process shutdown. Known firmware vulnerabilities can therefore remain in place long after a fix exists.
Firmware is opaque. Operators rarely have visibility into what a firmware image actually contains. Without a software bill of materials, it is difficult to know which third-party components and libraries are embedded, and therefore which vulnerabilities apply.
Devices are long-lived. Industrial devices remain in service for decades, often outliving vendor support, which means firmware that is no longer maintained continues to run critical processes.
Detection tooling is limited. Traditional endpoint security does not inspect firmware, and the low-level nature of firmware makes tampering difficult to detect from the operating system above it.
Defending Against Firmware Threats
Firmware risk cannot be eliminated, but it can be substantially reduced through a combination of technical controls, standards, and procurement discipline.
Demand Secure Development and Component Requirements
The IEC 62443 series addresses product security directly. IEC 62443-4-1 defines requirements for a secure product development lifecycle, and IEC 62443-4-2 defines technical security requirements for the components themselves, including secure update mechanisms and protection of device integrity. Requiring vendors to demonstrate conformance to these standards shifts firmware security upstream, to where it is most effective.
Require Secure Boot and Signed Firmware
Devices that implement secure boot verify the integrity of their firmware before executing it, and devices that require cryptographically signed firmware updates reject unauthorized images. These capabilities directly counter tampered-firmware and malicious-update attacks, and they should be treated as core procurement criteria.
Insist on a Software Bill of Materials
A software bill of materials, or SBOM, is an inventory of the components inside a device's firmware. It transforms firmware from an opaque black box into something an operator can assess, allowing the organization to determine quickly whether a newly disclosed vulnerability affects its devices.
Defensive implication: Without an SBOM, an operator learning of a new vulnerability in a common firmware library has no efficient way to know which of its devices are affected. With one, the question becomes a straightforward lookup.
Build Security Into Procurement
Many of the most effective firmware controls are decided at purchase, not after installation. Building security requirements into procurement, including secure update mechanisms, no hardcoded credentials, SBOM provision, and alignment with the principles of secure-by-design, is one of the highest-leverage actions an operator can take. This reflects the broader movement, championed by initiatives such as CISA's Secure by Design, to place responsibility for product security with manufacturers.
Apply Compensating Controls
For the large installed base of devices that lack modern firmware protections, compensating controls carry the load. Network segmentation limits which devices can reach a vulnerable one, access control restricts who can attempt an update, and monitoring can detect the network activity associated with an unauthorized firmware change.
Common Findings
From Beacon Security's assessment work, the firmware-related issues most frequently identified include:
- Widespread hardcoded or default credentials on field devices, often unchanged and sometimes unchangeable.
- Unsigned or weakly verified firmware update processes, leaving the update mechanism exploitable.
- No firmware inventory, so the organization cannot answer which devices run which firmware versions, let alone what those versions contain.
- Long-unpatched firmware vulnerabilities, kept in place by the operational difficulty of updating.
- No firmware security requirements in procurement, allowing insecure devices to continue entering the environment.
Getting Started
Firmware security is a long-term discipline, but progress is straightforward to begin.
Build a firmware inventory. Extend asset management to capture firmware versions across the environment, so the organization knows what it is running.
Add security to procurement now. Every new device purchased under strong security requirements reduces future risk, so the sooner procurement standards change, the better.
Prioritize compensating controls for legacy devices, focusing segmentation and access restriction on the devices most exposed and most consequential.
Track vendor advisories for the devices in your inventory, and fold firmware updates into planned maintenance windows.
Firmware sits at the foundation of every industrial device, and for a long time it was simply trusted. Treating it instead as something to verify, both in the devices already installed and in every device yet to be purchased, closes one of the most significant and least examined gaps in OT security.
Beacon Security helps industrial operators assess firmware and device security, define product security requirements for procurement, and apply the compensating controls that protect legacy equipment, aligned with IEC 62443-4-1 and 4-2. Contact us to strengthen the product security of your OT environment.
