Firmware integrity verification: proving devices run known good code

Firmware is the code that starts a device and runs beneath its operating system. If someone changes it, a device can keep working normally while running code its owner never approved, and malware that starts before the operating system can bypass its security and stay hidden. Firmware integrity verification is the routine that proves the code on each device still matches a known good version.

Why firmware tampering matters

NIST's Platform Firmware Resiliency Guidelines (SP 800-193, May 2018) warn that a successful attack on platform firmware could render a system inoperable, perhaps permanently, or require reprogramming by the original manufacturer. Attackers may instead plant persistent malware in firmware to disrupt operations or take data. The guidelines cover PC clients, servers and network devices.

Routers and switches

A September 2023 joint advisory from NSA, FBI, CISA and two Japanese agencies, People's Republic of China-Linked Cyber Actors Hide in Router Firmware (AA23-270A), describes the BlackTech group, after gaining privileged access, replacing firmware on certain Cisco IOS-based routers. The modified firmware carried an SSH backdoor whose connections were not logged. The agencies add that similar techniques could be used against other network equipment.

Industrial controllers

PLCs, RTUs and other operational technology (OT) controllers face the same risk. A 2013 Air Force Institute of Technology thesis showed how to alter a legitimate firmware update and upload it to an Allen-Bradley ControlLogix L61 PLC, work also published in the International Journal of Critical Infrastructure Protection. The thesis lists digitally signed and encrypted firmware among the mitigations.

Servers

SP 800-193 lists firmware in storage and network controllers and service processors, and notes that most modern servers include a baseboard management controller (BMC). CISA and NSA's June 2023 guidance on hardening BMCs says hardened credentials, firmware updates and network segmentation options are often overlooked.

What "known good" means

A known good image is firmware you can trace to the vendor and show has not changed. NIST's BIOS Protection Guidelines (SP 800-147, April 2011) call it a golden master image, used to install the approved BIOS before systems are deployed. ASD's Information Security Manual (ISM, September 2026 release) calls for network devices to be flashed with trusted firmware, obtained from vendors via trusted means, before first use (ISM-1800), noting this can reduce supply chain risks such as malicious firmware introduced through an interdiction attack.

The usual proof is a cryptographic hash. NIST's Secure Hash Standard (FIPS 180-4) says digests are used to detect whether data has changed since they were made. Cisco's IOS Software Integrity Assurance guide describes hashing an image on an administrative workstation with tools such as sha512sum and matching it to the value on Cisco's download site. For systems up to PROTECTED, the ISM asks that SHA-2 hashes are at least 224 bits, preferably SHA-384 or SHA-512 (ISM-1766).

Signed firmware, secure boot and measured boot

A hash tells you whether a file matches. A signature tells the device who produced it. SP 800-147 calls for an authenticated update mechanism: the update image must carry a digital signature that verifies against a key in a protected Root of Trust for Update before the BIOS is changed. The mechanism should also block unauthorised rollback to an older authentic version with a known weakness, for example by checking version numbers.

Secure boot applies the same idea at start-up. Microsoft's guide to securing the Windows boot process explains that UEFI firmware checks the bootloader's signature and only starts it if it is trusted. With measured boot, the firmware stores hashes of the firmware, bootloader and boot drivers in the TPM, which signs the log so a separate attestation server can judge the device's health. The ISM's operating system hardening controls call for both to be enabled (ISM-1745).

Signing has limits. BlackTech first installed older legitimate firmware, then modified it in memory to bypass the router's signature checks and load an unsigned bootloader and firmware. The advisory recommends devices with stronger secure boot checks for bootloaders and firmware, and replacing end-of-life equipment as a priority.

Reading the firmware versus asking the device

A tampered device controls its own answers. Cisco's guide warns that the on-device verify check "implies trust in the onboard verify /md5 command, which may itself be compromised", and gives the same warning for memory dumps and copy commands.

BlackTech showed this in practice: the advisory describes hidden Embedded Event Manager policies that removed lines from the output of legitimate commands and blocked commands useful for forensic analysis. Microsoft makes the same point about PCs: "you can't trust the client to tell you whether it's healthy." SP 800-193 builds this into its design rules, requiring the Root of Trust for Detection to stay trustworthy even after a successful attack on the firmware itself.

So treat a device's self-reported version or hash as a claim, not proof. Stronger evidence comes from reading the stored image through a path the device's own software does not control, or from a hardware-anchored measurement sent to a separate verifier. For running code, Cisco describes hashing the memory text region and comparing it with the same region from a router known not to be compromised.

Verification methods compared

Protect, detect, recover

SP 800-193 organises firmware resiliency around three principles. Protection keeps firmware and critical data in a state of integrity, including checking that updates are authentic. Detection finds when they have been corrupted or changed from an authorised state. Recovery restores them to a state of integrity.

Each principle rests on its own root of trust, for update, detection and recovery. NIST prefers cryptographic integrity checks for detection, done by the device itself or a host device. For recovery, it describes systems that restore from a backup image held in a separate location, such as a second flash chip. NIST says buyers can use the guidelines to shape procurement, so ask suppliers how their devices meet each principle.

A practical firmware verification routine

ISM-2161, added in the September 2026 edition, sets a minimum for network devices:

The integrity of network device firmware and running configurations is verified against an approved known-good baseline following patching, on detection of anomalous behaviour and at least monthly.

Apply the same discipline to controllers and servers:

1. Record at receipt. Log each device's model, serial number and firmware version in your software register (ISM-1643 expects registers to cover firmware). Get the vendor image through a trusted channel, check its hash and store that value as your reference.
2. Verify before deployment. Flash or confirm trusted firmware (ISM-1800) and compare the device against your reference before it goes live.
3. Re-verify after maintenance. Check again after patching, repair, or any time the device has left your control.
4. Re-verify on a schedule. Monthly at minimum for network devices, and whenever behaviour looks wrong. AA23-270A also recommends periodic snapshots of boot records and firmware compared against known good images.
5. Handle vendor updates safely. Use a managed process that maintains update integrity and confirms success (ISM-0298). Verify the hash or signature before installing, record the new version as the approved baseline, then confirm the device still meets policy, as SP 800-147 recommends. Apply firmware fixes within 48 hours for critical vulnerabilities or working exploits, otherwise within one month (ISM-1903, ISM-1904).
6. Watch and respond. Review logs for unauthorised reboots, version changes and firmware update attempts, as AA23-270A advises. Treat any unapproved change from the baseline as an incident to investigate, document and remediate, as SP 800-147 recommends.

Where BoardSafe fits

Firmware checks show whether the code is what the vendor shipped, but not whether the board underneath is. BoardSafe covers both. Its scanner checks firmware on a device against a known good version, and checks the circuit board against the board's original design files, flagging parts that are fake, swapped or not in the design.

It runs on site, so design files stay with you, and takes under 60 seconds per board. After a device passes, a small serial-numbered tamper-evident seal goes across the join of its case. See how the scan works, or read our guides to hardware supply chain security in Australia and tamper-evident seals for IT and OT equipment.

Questions people ask