Meeting Cyber Resilience Act Requirements with Hardware Root of Trust

Many embedded devices today ship with known vulnerabilities or default credentials that manufacturers often fail to patch promptly. The European Cyber Resilience Act (CRA) aims to improve the security of products with digital components. The regulation now tackles these problems by imposing mandatory cybersecurity requirements throughout a product’s lifecycle, from design and development to post-sales maintenance.

A common way to meet these requirements, especially embedded and IoT devices, is to leverage hardware-based Root of Trust (RoT). A hardware RoT is a trusted source within any cryptographic system that provides key security functions such as secure boot, secure storage, cryptographic operations, and device authentication.

In the context of software security measures, when an attacker gains kernel-level (Ring 0) or hypervisor (Ring -1) privileges, they can access memory, and bypass protections. However, the hardware RoT operates within a separate cryptographic boundary, often on a different co-processor or in an isolated execution environment.

Therefore, by leveraging hardware RoT features, manufacturers can address the fundamental requirements of the CRA. These include robust identity and authentication mechanisms, secure updates and vulnerability management, and data removal from the system. In the next step, we will explore the technical implementation of CRA requirements via RoT.

Figure 1: STMicroelectronics’ STSAFA110DFSPL02 authentication chip and IoT secure element with signature verification service through secure boot and firmware upgrade. (Image source: STMicroelectronics)

Technical implementation

1. System integrity via secure and measured boot

One of the most critical functions of a hardware RoT is to establish a trusted boot process. This means the RoT contains immutable code that runs first when the device powers, and its job is to verify the authenticity and integrity of the next stage of software (bootloader, OS, etc.) before handing control over.

This creates a chain of trust from the hardware upward. The prior stage cryptographically checks each component in the boot sequence. In practice, the RoT will verify the digital signature of the bootloader using an embedded public key, allowing only manufacturer-authorized firmware to run.

In more advanced implementations, a RoT can also perform a measured boot that records the cryptographic hash of each software stage for remote attestation. This means an external system can request proof of exactly what firmware versions booted on the device. CRA doesn’t mandate such attestation, but it complements the regulations' intention of allowing users and organizations to assess product security.

2. Strong identity and authentication

A hardware RoT provides each device with a strong identity in the form of a unique cryptographic key or certificate injected at manufacturing. This identity serves as the basis for authenticating the device's legitimacy. For instance, the Cisco hardware RoT chip stores a Secure Unique Device Identifier (SUDI) certificate and a private key, which are hardware-protected and not intended to be exported from the secure hardware.

For the resource-constrained IoT devices where a full Trusted Platform Module (TPM) is impractical, the TCG DICE (Device Identifier Composition Engine) standard provides a lightweight hardware RoT mechanism. It binds identity to both silicon and software states.

Figure 2: Microchip Technology’s AT97SC3204-U2A1A-20 Trusted Platform Module (TPM) LPC interface with a cryptographic accelerator capable of computing a 2048-bit RSA signature in 200ms. (Image source: Microchip Technology)

At the time of manufacturing, a Unique Device Secret (UDS), a 256-bit value is stored in fuses or derived from a PUF (physical unclonable function) and made accessible only to the immutable boot layer.

To further strengthen this model, PUF-based implementation is adopted to ensure that root keys are never stored in non-volatile memory, reducing exposure to physical extraction attacks. These mechanisms support anti-spoofing, secure authentication, and confidentiality requirements under CRA.

3. Secure updates and vulnerability management

Hardware RoT is more than just initial boot security. It remains critical during the device’s operations as well, especially for software updates. The CRA puts heavy emphasis on vulnerability handling and patching, requiring manufacturers to provide mechanisms to securely distribute updates and fix known flaws without delay. A RoT enables authenticated, secure firmware updates by verifying the digital signature on update packages.

For example, Microchip notes that designing CRA-compliant products includes implementing secure boot processes and ensuring firmware integrity, and subsequently performing secure firmware updates to protect against emerging threats. The RoT can also enforce anti-rollback protection so that an attacker cannot load an older firmware once an update has patched it.

Conclusion

The implementation of hardware Root of Trust delivers the building blocks to meet the core drivers outlined in the Cyber Resilience Act. The RoT enables secure boot, unique device identity, authenticated update installation, protection of cryptographic keys, and a platform for long-term security maintenance. Together, these capabilities strongly support the essential cybersecurity requirements defined by the CRA.