Confidentiality and Integrity Under the CRA: One Mechanism, Two Obligations
This post is the post #7 in our series about the Cyber Resilience Act (CRA) essential requirements, specifically about Part I requirements 2(e) and 2(f). The requirements state that products with digital elements shall "protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means" (Annex I, I.2e), and shall "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" (Annex I, I.2f).
In essence, the requirements I.2(e) and I.2(f) are both about protecting data in one form or another. Often they are also delivered by the same mechanism, e.g. set up TLS and you've addressed both confidentiality and integrity of the data in transit in one move. That overlap is convenient, but let’s go through both requirements separately.
Confidentiality of data
The requirement I.2(e) covers confidentiality of "data, personal or other". If we compare this to the General Data Protection Regulation (GDPR) the scope is wider, as it applies to anything the product stores, transmits, or processes, regardless of whether it's personal data.
The requirement names three data states: at rest, in transit, and otherwise processed. Protection can use encryption or other “state of the art mechanisms". Thus, CRA ties the requirement to evolving best practices rather than a fixed algorithm or protocol you can tick off once and forget. A static compliance checklist ages badly against CRA; what counted as state of the art at design time may not be valid years into the support period. The requirement also explicitly allows "other technical means" beyond encryption, for example OS-level access control or secure enclaves can both deliver, depending on the risk.
For data in transit, TLS and mTLS are the standard tools, and there's no shortage of good implementation guidance for them which we are not going to repeat here. Using such well-known secure and maintained protocols has the added benefit that you do not need to discuss their cryptographic strength, which is already publicly established. Of course, you must update your implementation to match the latest known good practices, if they change.
For data at rest, there's a real range of appropriate controls to match the security risk level. At the light end, OS-level file permissions and access control may be enough. Full-disk or file-level encryption sits further up the scale, and once you're there, the key management question appears: where are keys stored and how are they rotated. Weak key handling undermines strong encryption algorithms just as effectively as using a weak algorithm in the first place; history knows many products using a shared key for all deployed instances with devastating consequences. On top there are separate Trusted Platform Modules (TPMs) which handle secure key generation storage in a convenient package.
One distinction worth keeping straight: access control (I.2d) governs who can request data; confidentiality (I.2e) protects the data from channel or storage medium compromises. An authorised session running over unencrypted transport still fails as access control does not give confidentiality for free.
Integrity of many things
The requirement I.2(f) is about protecting data, but also commands, programs, and configuration. That's a broader scope; it pulls in firmware and software integrity and runtime command integrity, not just data sitting in storage or moving across a wire. The standard set by the text is "manipulation or modification not authorised by the user", meaning an unauthorized change, not necessarily a malicious change. A flawed but authorised update isn't an I.2(f) failure; an unauthorised one is, even if well-intentioned.
The common data protection techniques, e.g. mentioned TLS and mTLS, also provide data integrity. Same goes for access control, e.g. use of OS file permissions. For integrity-only solutions, there are many cryptographic mechanisms; hashes, HMACs, digital signatures etc. Firmware and software integrity can take advantage of signed updates and secure/verified boot chains, as well as update rollback protection. As before, the level of protection depends on the level of risk.
Reporting on corruptions
The second half of the requirement I.2(f), "report on corruptions," is an obligation that sits alongside I.2(d)'s "report on possible unauthorised access" and I.2(l)'s activity monitoring and logging.
However, what should corruption reporting actually tell the user, and what should it recommend they do? A raw integrity-check failure surfaced to a non-technical user isn't actionable on its own; do they get an error code, a support link, or a prompt for device reset? The regulation doesn't specify this. The action to proceed depends heavily on the domain and user experience. In a corporate or industrial environment, one should integrate with existing SIEM or other infrastructure. In consumer electronics, there is no central reporting service nor professional administrators. In such a setting, perhaps a link for support pages is the best thing to provide.
The bottom line
CRA essential requirements I.2(e) and I.2(f) protect the same underlying assets: data, and for integrity also commands, programs, and configuration. Both call for risk-based, state-of-the-art technical controls, and integrity carries the added duty of detecting and reporting when those controls are defeated. In practice the two obligations often ride on the same mechanism (TLS being the obvious example), but treating them as one and the same is exactly how gaps get missed - an encrypted channel doesn't always guarantee the commands running over it are protected from tampering, and a well-locked-down device can still leak data if the confidentiality half was never separately addressed.
