Firmware and Bootloader: The Verification Gap in OT Infrastructure

Deep DivePolicy Pulse
Written By Sandra Weiss

BY SANDRA WEISS

Securing industrial control systems requires looking beneath network traffic to verify code execution. As the revised Network and Information Security Directive (NIS2) and the Cyber Resilience Act (CRA) enforce stricter supply chain obligations, establishing a defensible operational posture means verifying that every bootloader and firmware image matches an approved vendor baseline. By combining modern cryptographic verification with structured controls for legacy hardware, operational technology (OT) operators can move past perimeter security assumptions to build true execution integrity. This report shows how to build that workflow without slowing down operations you already depend on.

European critical infrastructure operators are facing an operational reality check. While post-registration compliance efforts under NIS2 continue, a fundamental question remains unanswered across most industrial control environments. How do you prove that the code executing on your field device is actually what the vendor shipped?

Where perimeter defense focuses on network traffic, execution integrity requires validating the low-level software that runs before and during system boot. With NIS2 Article 21 and CRA Article 13 shifting regulatory expectations toward verifiable supply chain integrity, OT engineers and Chief Information Security Officers (CISOs) can no longer treat embedded firmware as an unexamined black box. Closing the verification gap requires moving beyond static inventory lists to cryptographic validation across the hardware boot chain.

 

The Verification Problem

A Programmable Logic Controller (PLC) or Remote Terminal Unit (RTU) typically triggers an alert the moment it drops off the network. Proving that the firmware currently running on that device, or the bootloader that loaded it, hasn’t been altered, corrupted, or replaced is a different problem entirely, and one that’s much harder to solve with cryptographic certainty.

This gap has transformed from an architectural blind spot into an immediate regulatory risk:

  • NIS2 Article 21(2)(d) requires operators to address supply chain security, including security-related aspects of their relationships with direct suppliers.

  • CRA Article 13 places obligations on manufacturers, such as drawing up Software Bills of Materials (SBOMs), that create the reference data operators need for that verification.

The regulatory framework assumes a two-sided model, in which manufacturers provide the verification materials, and operators perform the validation. In practice, most OT environments lack the operational workflows to bridge this gap. The workflow this report outlines is built to close exactly that gap.

 

The Verification Toolkit

To establish code integrity, OT security teams can draw on four primary technical mechanisms, ranging from basic manual checks to hardware-enforced remote attestation.

1. SHA-256 Hashing

The vendor calculates a cryptographic hash of the firmware binary and publishes it through a secure channel. The operator calculates the hash of the downloaded file prior to flashing and compares the values.

  • Practical Utility: Low barrier to entry, and requires no special hardware on the field device.

  • Operational Limitation: On resource-constrained OT controllers, calculating a full SHA-256 hash over several megabytes of flash memory during startup can noticeably increase boot time, which may be unacceptable for high-availability systems. Furthermore, it relies on vendors maintaining an accessible, trustworthy repository of reference hashes.

2. Digital Signatures with Public Key Infrastructure (Secure Boot)

The manufacturer signs the firmware image using a private key. The field device’s bootloader stores the corresponding public key in secure, immutable storage and verifies the digital signature before executing the code.

  • Practical Utility: Guarantees both data integrity (the image was not altered) and authenticity (it came from the legitimate vendor).

  • Operational Limitation: Standard on modern industrial computing hardware, but often absent on legacy field equipment deployed over the last two decades.

3. TPM 2.0 and Platform Configuration Registers (PCRs)

A Trusted Platform Module (TPM 2.0) acts as a hardware root of trust. As each stage of the bootloader and firmware loads, its cryptographic hash is “measured” and extended into TPM Platform Configuration Registers (PCRs).

  • Practical Utility: Creates an unalterable, hardware-enforced audit log of the exact boot state. If an unauthorized binary executes, the PCR values change, preventing the release of cryptographic keys needed for secure operation.

  • Operational Limitation: Requires explicit hardware support on the silicon layer. Retrofitting TPM modules into existing field controllers is generally not feasible, restricting this capability to new equipment deployments and high-end industrial PCs.

4. Remote Attestation and Continuous Integrity Telemetry

Remote attestation builds on TPM PCR measurements. A central management or OT security platform requests a cryptographically signed quote of the PCR values from a field asset. The platform compares these values against a database of verified reference baselines.

  • Practical Utility: Allows central security teams to continuously verify the low-level code integrity of remote substations and plants without taking assets offline.

  • Operational Limitation: Relies heavily on stable, secure outbound connectivity to field sites. In strictly air-gapped systems or low-bandwidth serial networks (e.g., remote water distribution or pipelines), remote attestation polling can fail or consume vital network capacity.

 

Regulatory Alignment: NIS2, CRA, and BSIG

The requirement to verify embedded software is moving from best practice into European regulation.

NIS2 Article 21(2)(d): Supply Chain Security

Focuses on the operator’s responsibilities. Essential and important entities must address supply chain security, including the cybersecurity practices of their direct suppliers. For firmware, that in practice means being able to show how software and firmware from third-party original equipment manufacturers (OEMs) are verified before deployment.

 

CRA Article 13: Manufacturer Obligations

Focuses on the OEM’s responsibilities. Equipment manufacturers must draw up SBOMs, document vulnerabilities, and provide security updates through secure distribution mechanisms during the support period. The CRA makes this documentation and update discipline a legal obligation, which gives operators a stronger basis for asking for it.

 

§ 30(2) BSIG: Technical & Organizational Measures

In practice, demonstrating these measures for firmware typically means showing:

  1. An accurate inventory of firmware versions across all OT assets.

  2. A documented, repeatable verification workflow for all software changes.

  3. Audit-ready evidence proving that the binaries currently executing on field devices match approved configurations.

 

Lessons from NERC CIP Enforcement

European operators can draw valuable insights from North America, where the North American Electric Reliability Corporation (NERC) enforced similar requirements through its Critical Infrastructure Protection (CIP) standards CIP-010 (Configuration Change Management) and CIP-013 (Supply Chain Risk Management).

When NERC CIP-010 and CIP-013 required verification of software and firmware integrity prior to installation, US utilities commonly reported distinct operational hurdles:

  • Procurement Realities: Obtaining reference hashes from vendors proved challenging. Most legacy procurement contracts did not obligate OEMs to provide cryptographically verifiable checksums or signed binaries. Utilities had to update vendor contract language before technical verification could occur.

  • Operational Scale: Manually verifying software hashes across thousands of multi-vendor devices in geographically dispersed substations proved unsustainable. Successful entities shifted from manual checklist processes to automated asset management platforms capable of aggregating vendor reference baselines.

The Takeaway for EU Operators:

The CRA eases the procurement hurdle by making SBOMs, vulnerability handling, and secure update distribution legal obligations for manufacturers. However, EU entities must still build the internal operational workflows required to ingest, document, and audit these materials.

 

The Legacy OT Challenge

While modern hardware supports TPM 2.0 and Unified Extensible Firmware Interface (UEFI) Secure Boot, the reality of industrial operations is that field equipment often remains in service for 15 years or more. Many operational PLCs, RTUs, and smart meters lack hardware roots of trust, cannot perform cryptographic signature checks, and run on microcontrollers where hashing adds significant performance overhead.

While the CRA’s product requirements apply to new products entering the market, NIS2 obligations apply to operators regardless of asset age. When modern verification tools cannot run on legacy hardware, operators must implement targeted compensating controls:

  1. Out-of-Band Update Gates: Where a PLC cannot verify its own updates, restrict flashing capabilities over the network. Require firmware binaries to be downloaded to a dedicated, isolated engineering station, verified via SHA-256 against vendor documentation, and transferred via controlled physical media.

  2. Passive Baseline Drift Monitoring: Configure OT security and management tools to continuously poll asset identification frames (such as Common Industrial Protocol (CIP) List Identity in EtherNet/IP or Modbus report slave ID[C22]  commands). Any unexpected change in reported firmware revisions should trigger an immediate security alert.

  3. Contractual Requirements for Lifecycle Upgrades: Mandate that all incoming equipment replacements include hardware support for Secure Boot and TPM 2.0.

  4. Documented Risk Acceptance: For legacy systems where low-level cryptographic verification is technically impossible, maintain a formal, documented risk posture detailing the compensating network segmentation and operational controls in place.

 

Action Plan for OT Engineering & Security Teams

To move from passive compliance to a verified posture, security teams should execute the following sequential roadmap:

Step 1: Expand Asset Inventory 

Go beyond IP addresses, MAC addresses, and model names. Establishing a defensible operational baseline requires auditing low-level asset characteristics:

  • Exact firmware build numbers and patch levels

  • Bootloader versions (where exposed)

  • Availability of cryptographic verification features (Secure Boot/TPM)

Step 2: Conduct Vendor Baselining

Select your top 10 OT equipment vendors by asset volume and evaluate their delivery channels:

  • Do they publish signed hashes over HTTPS/GPG-signed channels?

  • Are firmware binaries cryptographically signed?

  • Do they supply machine-readable SBOMs?

Step 3: Implement Pre-Deployment Staging

Update change-management procedures. Before any firmware file is loaded onto a field tool or flashed to a production asset:

  • Verify the file checksum against official vendor documentation.

  • Log the verification event, including the operator name, timestamp, hash matched, and approval ticket.

Step 4: Update Procurement Specifications

Update engineering specifications for all upcoming infrastructure projects:

  • Require TPM 2.0 and UEFI Secure Boot on all new industrial PCs, human-machine interfaces (HMIs), and edge gateways.

  • Mandate native digital signature validation for all new PLCs and RTUs.

Step 5: Configure Continuous Monitoring

Leverage your OT and asset management platforms to track firmware baselines continuously. Ensure the system is configured to generate an immediate alert upon detecting any unauthorized firmware version drift across the asset base.

 

Sources and Further Reading

Sandra Weiss
Next

The Execution Layer Gap: Why European Critical Infrastructure May Be Looking at the Wrong Regulatory Clock