Deep Dive: CRA Requirement (f) – Protecting the Integrity of Data and Functions

Requirement (f) of the Cyber Resilience Act focuses on integrity, one of the three pillars of the CRA security triad alongside confidentiality and availability. Of these, integrity is often the most overlooked, yet without it, data and commands cannot be trusted, no matter how well they are protected from access or kept confidential.

The Cyber Resilience Act introduces a clear duty for manufacturers of connected products:

“(f) protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions;”

What makes this requirement fundamentally new is that indirect protections, such as encrypting communication channels with TLS, are no longer enough. Manufacturers must be able to prove that data, configurations, and commands remain unaltered as they move through complex IoT and OT system layers, and they must detect and report any corruption that occurs. Integrity is no longer just a best practice, it is a legal obligation across the entire lifecycle of digital products. 

What This Requirement Means

What if the data you rely on was a lie? Most people overlook the criticality of data integrity in a world that is becoming more digital every day.

Take the example of a European energy community, where an intelligent energy management system forecasts demand and balances supply using signals from electric cars and stationary batteries. If data streams are manipulated, for example by fake signals indicating higher demand or false information of free grid capacity, the optimizer makes the wrong decisions. The result is increased costs for the community, an unstable grid, and even power outages. Without integrity, the system that is supposed to save money and stabilize the grid becomes itself a threat to critical infrastructure.

This is a fundamental shift. Until now, today’s connected products focus on indirect protection through encrypted transport (e.g. TLS) or secure VPNs. While these mechanisms protect data in transit, they do not provide a way to prove that the data, commands, or configurations themselves are unaltered when used by other parts of the system or end users. The CRA requires manufacturers to implement data integrity assurance end-to-end, including for data, configurations and commands flowing through sensors, gateways, middleware and cloud applications.

For technical teams, the scope is daunting. Today, integrity checks are well established only for software update packages, where digital signatures are standard practice. But there is rarely a mechanism to verify the integrity of runtime data, operational commands, or device configurations. This gap is especially visible in IoT and OT systems, where information often crosses multiple trust boundaries. As a result, telemetry may be spoofed, commands injected, or configurations tampered with, without leaving clear evidence. CRA Requirement (f) calls for moving beyond indirect protections toward systematic, verifiable integrity mechanisms across all system layers.

Relevant Standards and Guidelines

While harmonised CRA standards are still in development, there are existing frameworks that provide a starting point for integrity protection:

• EN IEC 62443-4-2 (industrial systems): Defines integrity requirements for industrial automation components, including detection of manipulation and corruption.

• ETSI EN 303 645 (consumer IoT): Requires that software integrity be protected and verified during updates.

• EN 18031 (embedded IoT): Introduces requirements for encryption, signatures, and secure update mechanisms relevant to radio-connected devices.

• ISO/IEC 9797 (general IT): Defines message authentication codes (MACs) for ensuring data integrity in communication and storage.

• ISO/IEC 14888 (general IT): Specifies digital signature schemes for protecting integrity and authenticity of data and commands.

However, the gaps are significant. Most standards stop at securing updates or defining general management controls. They do not provide practical methods for runtime integrity verification of data, commands, or configurations, particularly when these move across different layers of an IoT or OT system. Reporting of corruption is also inconsistently defined. These gaps mean that new harmonised standards under CRA will likely expand requirements for direct integrity verification beyond what is available today.

How to Approach Implementation

Start by breaking Requirement (f) down into practical product capabilities. Integrity must be ensured for stored data, transmitted messages, software and firmware, and configuration values. It is not enough to assume that encryption of communication channels provides this assurance; verification must be applied to the data, configurations, commands, and update packages themselves.

To move beyond generic protections, it is also important to understand what exactly needs to be protected and against which threats. Integrity requirements will differ depending on the role of the data and the criticality of the function it supports. Identifying these threats should be part of the mandatory risk assessment required under the CRA. To support this process, Tributech has developed a data-centric risk and threat analysis framework that helps map risks to data flows, system functions, and trust boundaries. This makes it easier to define which integrity protections are essential and where they must be applied to ensure compliance.

To effectively meet this requirement, the following steps and capabilities should be considered:

• Cryptographic signing of software and firmware including secure boot

• Hashing and message authentication codes (MACs) for transmitted data (e.g. TLS)

• Integrity checks for operational data, configurations and commands across system layers using hashing (e.g. SHA 256) and signature (e.g. RSA, ECC) algorithms

• Mechanisms to detect and report corruptions in software, firmware, configuration files, commands and operational data

In industrial IoT and OT systems, the main challenge is ensuring that integrity protections extend consistently across all layers of the system. Data rarely flows in a straight line, it often passes through sensors, gateways, middleware, and cloud platforms, creating multiple points where manipulation could occur.

To reduce this risk, data should be secured as close as possible to the source where it is generated, so that integrity is preserved before it crosses trust boundaries. Cryptographic methods such as hashing and digital signatures must be applied not only to software packages but also to operational data, configurations, and commands.

These protections must be supported by secure key provisioning and lifecycle management, since without trustworthy key handling, integrity checks can be bypassed or corrupted. To strengthen assurance, it is recommended to integrate hardware-based security modules, for example, those aligned with TPM 2.0 standards, to provide a hardware root of trust and minimise attack vectors across the system.

For embedded IoT devices, the challenges to implement new integrity requirements are similar in principle but amplified by the limited resources of microcontrollers. Implementing hashing and signature mechanisms in such constrained environments requires resource-efficient designs that do not compromise security. Using lightweight cryptography that is not widely adopted may introduce new risks. This makes certified hardware security modules (HSMs) optimised for embedded devices especially valuable, as they can offload the computational workload to dedicated hardware that is purpose-built for cryptographic operations. Using HSMs enables secure key storage and efficient integrity checks without forcing critical trade-offs in cryptographic strength.

Critical considerations include cryptographic agility, mechanisms should be designed so that algorithms and parameters can be updated as best practices evolve. Beyond current standards, manufacturers will need to build practical methods for end-to-end verification of runtime data, configurations, and commands, not only for software updates. This is the step that makes CRA Requirement (f) fundamentally new.

Compliance and Strategic Considerations

From a compliance perspective, Annex VII requires that manufacturers document how integrity protections are applied across operational data, configurations, commands, software, and firmware. It should also describe how corruptions are detected and reported, so regulators and operators can verify that attempts at manipulation do not go unnoticed. In addition to the CRA, other regulations such as the ESPR (Digital Product Passport), the EU AI Act, and the EU Data Act also demand mechanisms to secure data integrity and protect systems against related threats.

When assessing in-house development versus vendor solutions, consider the complexity of implementing end-to-end integrity checks. Building them internally provides flexibility but requires deep cryptographic expertise, significant resources and lifecycle maintenance. Vendor solutions can simplify implementation but must be reviewed for CRA alignment, especially regarding the ability to detect unauthorised alterations.

Strategically, requirement (f) marks an inflection point. While confidentiality and access control have long been part of cybersecurity practices, systematic integrity verification across data, commands, and configurations is completely new in IoT and OT systems. Meeting this requirement will be challenging but will also raise the baseline of trust in connected products. Companies that adopt end-to-end integrity verification early will be better positioned for compliance and will stand out in a market where customers increasingly demand not just secure communication but trustworthy data.

In our next post, we will explore Requirement (g): Data Minimisation, which ensures that products only collect and process the data that is truly necessary for their purpose.

Previous Blog CRA Requirement (e): https://www.tributech.io/blog/cra-requirement-e-protecting-confidentiality-of-dataNext Blog CRA Requirement (g):https://www.tributech.io/blog/cra-requirement-g-data-minimisation