Integrity on Embedded Linux Devices under the Cyber Resilience Act

Trainings<br>Customized Trainings<br>About<br>Blog<br>DE

security

29.06.2026

Integrity on Embedded Linux Devices under the Cyber Resilience Act<br>As with<br>confidentiality,<br>the Cyber Resilience Act (CRA) lists integrity as an essential cybersecurity<br>requirement.<br>In this post, we look at what that means for embedded Linux devices.<br>Annex I, Part<br>I(2)<br>states that products with digital elements placed on the EU market shall:<br>(f) protect the integrity of stored, transmitted or otherwise processed data,<br>personal or other, commands, programs and configuration against any<br>manipulation or modification not authorised by the user, and report on<br>corruptions

So how does an embedded Linux device actually satisfy this requirement? The<br>CRA&rsquo;s integrity requirement is as broad as it sounds. It covers not just<br>(personal and non-personal) data, but also commands, programs, and<br>configuration, and applies whether the device stores, transmits, or actively<br>processes those assets.<br>There is no single technical control that protects all of these assets in all<br>states. Depending on the product and its threat model, integrity may require<br>controls for the boot chain, software updates, stored data, application<br>binaries, configuration, commands, and communication with other systems.<br>Scope of the CRA Integrity Requirement<br>This has two parts:<br>Assets in Scope<br>stored, transmitted or otherwise processed data, personal or other, commands,<br>programs and configuration

The CRA names data, commands, programs, and configuration, but it does not<br>prescribe a fixed list of components or controls. Under Article<br>13,<br>the cybersecurity risk assessment must indicate whether and how the Annex I,<br>Part I(2) requirements apply to the product. For embedded devices, this means<br>the vendor needs a threat model. It should identify which assets an<br>attacker could modify, which paths they could use, and what the consequences<br>would be.<br>For an embedded device, the assets in scope may include the bootloader, kernel,<br>kernel command line, application binaries, configuration, and messages or<br>commands exchanged with other systems. The requirement is therefore not limited<br>to user data or personal data. Even a device that stores no personal data at all<br>falls within the integrity requirement.<br>Required Protection<br>protect &mldr; against any manipulation or modification not authorised by the<br>user, and report on corruptions

For an embedded Linux device, this means protecting relevant assets against<br>unauthorised modification, detecting integrity failures where appropriate, and<br>reporting corruptions. The right technologies depend on the asset and threat<br>model.<br>In some cases, protecting against unauthorised modification also requires<br>authenticity. The device<br>must verify that software, configuration, commands, or data originate from an<br>authorised source.<br>Integrity Controls for Embedded Linux<br>Embedded Linux devices usually need integrity controls at several layers.<br>The following examples are a starting point, not a checklist for every product:<br>Secure boot : to verify the integrity and authenticity of each component in<br>the boot chain before the device executes it. Implement secure boot carefully:<br>attackers may abuse inputs outside the chain of trust, such as the kernel<br>command line or bootloader environment, for bypasses.

Signed updates : to verify the authenticity and integrity of firmware,<br>operating system, and application updates before the device installs them.<br>Depending on the product, this may also require rollback protection.

Integrity of data at rest : to detect modification or corruption of stored<br>data. Depending on the layer and use case, different mechanisms can implement<br>this, such as:<br>dm-verity<br>for read-only block devices<br>dm-integrity<br>for writable block devices, optionally in combination with<br>dm-crypt<br>for authenticated encryption.<br>Linux IMA and EVM for<br>file integrity and selected file metadata.<br>fs-verity for<br>read-only file contents.

Access control : to preserve integrity by restricting who or what can modify<br>relevant assets. A device may implement access control at different<br>levels, for example with filesystem permissions, Linux security modules such<br>as<br>SELinux<br>or AppArmor, or application-level authorization checks<br>for APIs (such as REST or GraphQL).

Integrity of data in transit : to detect unauthorised modification of data<br>while the device exchanges it with other systems and reject modified data, for<br>example with TLS.

Trusted Execution Environments : to protect selected code and data while in<br>use. For instance, TEEs can provide integrity and confidentiality protection<br>even if an attacker compromises the main operating system, depending on the TEE<br>design and threat model.

Conclusion<br>The main takeaway is that the CRA integrity requirement is broad, and no single<br>feature can fulfill it. Depending on the threat model, the product may need<br>multiple complementary technologies.<br>As a reminder, non-compliance with...