IIoT security: Firmware integrity from boot-up to execution

In industrial environments, where IIoT devices control critical operations, firmware compromise can lead to catastrophic consequences: from production outages and financial losses to threats to personnel safety. Ensuring firmware integrity at all stages—from initial boot-up to continuous execution—is not merely a recommendation but an architectural requirement for resilience against modern cyberattacks.

Why firmware integrity is the foundation of IIoT security

Firmware is the first line of defense for an IIoT device, defining its functionality and security. A successful attack on firmware can render a system inoperable, possibly permanently, or require reprogramming by the manufacturer, leading to significant operational disruptions. Attackers can use compromised firmware to inject malicious code, steal data, or turn the device into part of a botnet for further attacks.

Reports for 2025 indicate a rise in attacks on network and security equipment, linked to the increasing number of connected IoT devices and insufficient levels of embedded protection. Compromising a single IIoT device can become a springboard for further network penetration or cause local physical effects. Standards such as NIST SP 800-193 and IEC 62443 emphasize the need for firmware protection, defining mechanisms to guard against unauthorized changes, detect such changes, and rapidly recover from attacks.

Architectural components for building firmware trust

To ensure the integrity of IIoT device firmware, a set of technical mechanisms are applied, interacting to create an end-to-end trust architecture.

Hardware Root of Trust (HRoT)

HRoT is the cornerstone of security, representing a tamper-resistant module embedded within the device. It serves as the starting point for all security functions, ensuring that even if other parts of the system are compromised, the core remains protected. HRoT is an immutable, unique, and non-clonable identifier that authenticates the device on the network and initiates a secure boot process. Unlike purely software solutions, a hardware root of trust provides an additional layer of protection that is significantly harder to bypass.

Secure Boot Chain

The secure boot process implements a chain of trust where each subsequent component is authenticated before execution, starting from an implicitly trusted component (HRoT). This means the bootloader verifies the cryptographic signature of the operating system, the OS verifies drivers, and drivers verify loaded applications. If verification fails at any stage, device boot-up is halted, preventing the execution of unauthorized or malicious software.

Measured Boot

Measured boot is the process of computing and securely recording hashes of code and critical data at each stage of the boot chain before they are used. These measurements are stored in tamper-resistant logs, such as Platform Configuration Registers (PCRs) in a TPM. Unlike secure boot, which actively blocks unauthorized code from loading, measured boot passively records the system state, allowing policy verification to be deferred until after boot. This enables the system to boot and then verify its integrity, forming the basis for remote attestation.

Trusted Platform Modules (TPM) and Secure Elements (SE)

A Trusted Platform Module (TPM) is a specialized cryptographic processor standardized by the Trusted Computing Group (TCG). It provides a hardware root of trust for a computing platform, securely generating, storing, and protecting cryptographic keys, and measuring the integrity of the boot process. TPMs play a vital role in secure boot by helping to verify the integrity of the boot chain, and in measured boot by storing measurements in PCRs.

A Secure Element (SE) is a tamper-resistant microcontroller specifically designed to securely store cryptographic keys, digital identities, and sensitive data, as well as perform cryptographic operations. Unlike a TPM, an SE focuses on protecting specific applications, identities, and transactions, rather than the entire platform. SEs are often used in IoT devices, smartphones, and payment cards. While an SE can store boot keys, it typically does not measure or verify the full platform boot sequence.

Remote Attestation

Remote attestation is a cryptographic protocol that allows a trusted party (verifier) to remotely assess the integrity and trustworthiness of software, firmware, and critical system state on a remote, potentially untrusted, computing platform. It enables the detection of unauthorized modifications, tampering, or compromised execution environments through verifiable evidence. In IoT environments, where devices operate in often uncontrolled conditions, remote attestation ensures that each device remains trustworthy and unaltered, allowing it to securely interact with cloud services or other devices.

Integrating mechanisms: From boot-up to execution

The integration of these mechanisms creates a multi-layered trust architecture. The process begins with the Hardware Root of Trust (HRoT), which is the first code executed after power reset and establishes the anchor of trust for the boot chain. The HRoT verifies the first stage of the bootloader, which in turn verifies the next, and so on, creating a secure boot chain.

In parallel with secure boot, the measured boot mechanism computes hashes of each loaded component and stores them in immutable registers (PCRs) of the TPM. These measurements form an “Event Log” that records the boot sequence and system configuration.

After boot completion and during execution, remote attestation utilizes these measurements. A remote verifier can request an attestation report from the device, which contains signed PCR values and other system state information. By comparing these values against known “good” baselines, the verifier can determine if the device is operating in a trusted state and if its firmware has been compromised. This process ensures continuous integrity monitoring, which is critically important for IIoT devices operating autonomously for extended periods.

Challenges and trade-offs in implementation

Implementing an end-to-end trust architecture for IIoT device firmware involves a number of challenges and trade-offs. Firstly, there is the complexity of development and integration. Realizing a hardware root of trust, secure, and measured boot requires deep knowledge in embedded systems, cryptography, and cybersecurity. This demands highly skilled developers and engineers.

Secondly, the cost of hardware components, such as discrete TPMs or Secure Elements, can be significant, especially for mass IIoT deployments with limited budgets. While integrated solutions exist (e.g., TrustZone in microcontrollers), they may offer varying levels of resistance to physical attacks.

Thirdly, the impact on device performance. Cryptographic operations required for signature verification during secure boot and hash computation for measured boot can increase device boot time and resource consumption. For resource-intensive IIoT devices, this may be acceptable, but for ultra-low-power sensors, it can become a critical limitation.

A balance must be struck between a high level of security and practical implementation, considering the specific requirements and constraints of each IIoT project. For example, a TPM 2.0 may have a delay of 1–10 ms per operation, which is acceptable for servers but not always suitable for deeply embedded or ultra-low-power IIoT devices.

Matrix for selecting architectural solutions for IIoT firmware integrity

Utilizing the architectural principles of secure boot and firmware integrity monitoring described in this article allows for the integration of IIoT devices into the AZIOT ecosystem, providing a reliable foundation for data collection and processing with the assurance that devices are functioning with authentic and unaltered firmware. This enables AZIOT to effectively aggregate data from various protocols such as MQTT, Modbus, BACnet, KNX, Zigbee, Z-Wave, LoRaWAN, Matter, SCADA, and BMS for further edge processing, application of rules and scenarios, visualization on dashboards, and ensuring audit and access control, minimizing risks associated with device compromise.

Implementing an end-to-end trust architecture requires a strategic approach and investment in hardware components and skilled personnel. However, these investments are critically important for protecting industrial assets, ensuring operational continuity, and complying with growing cybersecurity requirements. CTOs and IIoT solutions architects must consider firmware integrity as an integral part of their overall cybersecurity strategy, ensuring resilience against threats in the modern industrial landscape.

Explore Intecracy solutions and inbase.com.ua solutions for more information.