OT Firmware Security: Integrity, Secure Boot and Supply-Chain Trust

01Key takeaways

1. 01

   OT firmware security is about device-level trust: proving the boot code, the running firmware and any update are genuine and unmodified.

2. 02

   Secure boot, signed and authenticated updates, and a hardware root of trust are the three pillars that make that proof possible.

3. 03

   A firmware SBOM lets operators map known-vulnerable components and respond when a new CVE lands in a library buried inside the device.

4. 04

   Many installed OT devices predate these features, so compensating controls such as segmentation, update governance and one-way transfer matter.

5. 05

   Firmware integrity reduces a specific risk - silently altered device code - but it does not replace inventory, monitoring, patch governance or exposure reduction.

02What OT firmware security means

Firmware is the software that runs closest to the hardware. On an industrial device it includes the boot loader, the real-time operating system or runtime, and the control logic environment. OT firmware security is the set of controls that ensure this code is authentic, unmodified and accounted for across its life - from manufacture, through update, to decommissioning.

This is narrower than broad supply-chain risk. Supply-chain security asks who you trust and how compromise reaches you. Firmware security asks a device-level question: when this controller powers on and runs, is it running exactly the code the vendor signed and the operator approved? That question is answered at the boot and update layer, not in the SOC.

Firmware

The low-level software stored in a device - boot loader, runtime and control environment - that runs before and beneath any application.

Firmware integrity

Assurance that the code on the device matches a known-good, authenticated reference and has not been altered.

Root of trust

A small, trusted component, ideally in hardware, that anchors every integrity check that follows.

03Why firmware is a high-value target

Firmware is attractive to attackers for the same reasons it is hard to defend. It runs below the tools most operators use to inspect a device. It persists across reboots and often survives a re-flash if the boot chain itself is compromised. And in OT, the same firmware image may run unchanged on thousands of identical field devices for a decade or more.

The threat is not theoretical. The MITRE ATT&CK for ICS knowledge base documents techniques such as System Firmware and Module Firmware modification, where an adversary alters device firmware to gain persistence or to manipulate the physical process. Real incidents have shown attackers issuing unauthorized firmware-level changes to controllers and protection equipment to disrupt operations and hide their presence.

The defining risk of firmware compromise is silence. A device can run altered code while reporting normal status, so the integrity check has to happen at boot and update time - not after the fact.

04Secure boot: trusting the device at power-on

Secure boot is the mechanism that verifies each stage of the startup process before it is allowed to run. The first immutable code measures or verifies the next stage, that stage verifies the one after it, and so on up the chain. If any stage fails its signature or hash check, the device halts, alerts, or falls back to a known-good image instead of running unverified code.

Two related concepts often appear together. Verified boot blocks execution when a stage fails a cryptographic signature check. Measured boot records a hash of each stage into a protected register so the result can be attested later, often to a remote verifier. Many robust designs use both: verified boot to stop bad code, measured boot to prove what actually ran.

Verified boot

Each boot stage is cryptographically checked against a trusted key before it is permitted to execute.

Measured boot

Each stage is hashed into protected storage so the boot state can be attested to a verifier later.

Boot chain anchor

The first-stage code in immutable storage that cannot itself be altered and starts the chain of trust.

05Signed and authenticated firmware updates

Most firmware reaches a device through an update, so the update path is the most common attack route. A secure update process requires that every image be signed by the vendor with a key the device trusts, and that the device verify that signature before writing the image. Authenticity proves the image came from the vendor; integrity proves it was not altered in transit or storage.

• Cryptographic signature verification against a trusted key before any image is written to flash.
• Version and rollback control so an attacker cannot force a downgrade to a known-vulnerable image.
• Anti-bricking measures such as dual-bank flash or a verified golden image to recover from a failed or rejected update.
• An audit record of who initiated the update, which image was applied, and whether verification passed.
• Protection of the engineering workstation and update server, which are themselves high-value targets in the update chain.

Standards reinforce this. NIST SP 800-82 Rev. 3 calls for verifying integrity and authenticity of OT software and firmware, and ISA/IEC 62443-4-2 defines component requirements that include support for signed code and verification of software updates. Where a device cannot verify signatures itself, the operator must compensate with strict update governance and trusted distribution.

06Hardware root of trust and where keys live

Every integrity check depends on something the attacker cannot quietly change. A hardware root of trust provides that anchor: immutable boot code and protected key storage, often in a secure element, a TPM, or one-time-programmable fuses inside the processor. If the keys and the first-stage code live in tamper-resistant hardware, the rest of the chain can be trusted to build on them.

A software-only root of trust is weaker because the thing that verifies the code is itself code that could be modified. In OT, where devices are physically accessible in substations, cabinets and remote sites, hardware anchoring matters more, not less. The same hardware can support remote attestation, letting a device prove its boot state to a management system rather than simply asserting that it is fine.

Ask the vendor a precise question: where do the verification keys live, and what physically prevents them from being read or replaced? The answer separates a real root of trust from a marketing claim.

07Firmware SBOM and known-vulnerable components

Modern firmware is assembled from many parts: an RTOS, network stacks, cryptographic libraries, and open-source components. A vulnerability in any one of them becomes a vulnerability in the device. A software bill of materials (SBOM) is the inventory of those components, and a firmware SBOM lets an operator answer a question that used to take weeks: which of my devices contain the library that just got a critical CVE?

This capability proved its worth during widespread embedded-stack vulnerabilities affecting many ICS products at once. Without an SBOM, operators could not tell which assets were affected. CISA publishes ICS advisories that increasingly reference component-level flaws, and the CycloneDX and SPDX formats give a practical way to consume that data. An SBOM does not fix anything by itself - it turns an unanswerable question into a triage list.

• Request a current SBOM for each firmware version as part of procurement, not as an afterthought.
• Map SBOM components against vulnerability feeds so new CVEs surface against your actual installed base.
• Track end-of-life and end-of-support firmware where no fix will ever arrive.
• Treat the SBOM as living data that must be re-issued whenever firmware changes.

08Tamper detection and runtime integrity

Secure boot proves the device started clean. Tamper detection and runtime integrity address what happens afterwards. Physical tamper evidence - seals, intrusion switches, enclosure sensors - signals when someone has opened a device in the field. Logical integrity monitoring periodically re-verifies firmware regions, configuration and control logic against known-good baselines.

In OT this often happens off-device because the controllers themselves have little spare capacity. A monitoring system can collect firmware versions, hashes and configuration snapshots and compare them over time, raising an alert when a controller's firmware fingerprint changes outside an approved maintenance window. The goal is to shrink the gap between an unauthorized change and the moment someone notices it.

Physical tamper detection

Seals, switches and sensors that record or signal physical access to a device enclosure.

Runtime integrity monitoring

Periodic re-verification of firmware, configuration and logic against an approved baseline.

Configuration baselining

Capturing a trusted snapshot of device state so later drift or tampering becomes visible.

09Standards, compliance mapping and common pitfalls

Firmware integrity is not a niche concern in the standards; it sits inside core OT security guidance. Mapping your controls to these frameworks makes audits and risk acceptance far easier, and it gives engineering teams concrete requirements rather than aspirations.

NIST SP 800-82 Rev. 3

Guide to OT security; calls for verifying integrity and authenticity of OT software and firmware and protecting the supply chain.

ISA/IEC 62443-4-2

Technical security requirements for components, including support for signed code, secure update and integrity verification.

ISA/IEC 62443-4-1

Secure product development lifecycle requirements for the vendors that build and sign the firmware.

NIST SP 800-53 / 800-161

Control catalog and supply-chain risk management practices that cover software integrity, code signing and SBOM.

• Trusting the device's self-reported version instead of verifying an actual hash against a known-good reference.
• Leaving signature verification disabled or in a permissive mode that only warns and still boots.
• Allowing firmware downgrade so an attacker can reintroduce a patched vulnerability.
• Storing signing keys on an exposed engineering workstation or shared file server.
• Treating the SBOM as a one-time procurement document rather than living data tied to each version.

10Where one-way transfer and exposure reduction fit

Firmware integrity controls reduce the chance that altered code runs on a device. Exposure reduction reduces the chance that an attacker can reach the device to deliver that code, or use a compromised device to reach further. The two are complementary, and they matter most for the large installed base of legacy devices that cannot enforce their own integrity. CISA's Secure-by-Design guidance pushes responsibility upstream, but most OT estates still run hardware that predates these features.

Limiting bidirectional reachability shrinks the firmware attack surface directly. If a protected zone publishes telemetry and status outward but accepts no inbound network path, an external attacker has no route to push a malicious update or trigger a firmware change over the network. Firmware version data, hashes and integrity alerts can flow out to a monitoring platform across a one-way boundary, while the update path stays tightly governed and offline by default.

This is where controls such as a one-way transfer or scheduled-disconnection architecture sit alongside secure boot and signed updates. The diode or unidirectional path is not a substitute for device-level integrity - it removes the inbound route that delivers most remote firmware attacks, so the device's own defenses face a far smaller threat.

11A practical firmware-trust roadmap

You cannot retrofit a hardware root of trust onto a device that lacks one, but you can build a program that gets steadily stronger. The order matters: start with knowing what you have, then verify it, then govern how it changes.

• Inventory every device with its current firmware version and obtain an SBOM where available.
• Verify integrity by hash against vendor-published references, not by trusting self-reported versions.
• Enable secure boot and signature verification wherever the hardware supports it, in enforcing mode.
• Govern the update path: signed images, controlled distribution, downgrade protection and audit records.
• Baseline and monitor firmware and configuration so unauthorized change is detected quickly.
• Reduce exposure with segmentation and one-way transfer so legacy devices that cannot verify themselves are not reachable from untrusted networks.

Firmware security is a layer, not a finish line. The goal is to make device trust provable: to know that what runs on a controller is what the vendor signed and the operator approved, and to notice quickly when that stops being true. Combine device-level integrity with disciplined updates and reduced reachability, and the firmware layer stops being an invisible gap and becomes a control you can actually evidence.

FAQFrequently asked questions

SRCSources of record