Deep Dive: CRA Requirement (e) – Protecting the Confidentiality of Data

Requirement (e) of the EU Cyber Resilience Act focuses on keeping data confidential:

“(e) 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;”

Confidentiality is one of the three pillars of the CIA security triad, alongside integrity and availability, which highlights its central role in protecting connected products. Encryption and related technologies are well established, and in many IT systems confidentiality is already treated as a given. The real challenge lies in applying these protections consistently across every part of a product or system. In practice, the most significant gaps often appear at the field level, where industrial and IoT protocols such as Modbus or OPC UA are still commonly deployed without encryption or proper authentication.

This requirement makes confidentiality a legal obligation across the full data lifecycle. Whether data is stored on a device, transmitted between systems, or processed, it must be protected against unauthorised access. And it applies not only to personal information but also to technical, operational, and business data that may be just as sensitive.

What This Requirement Means

Imagine sending a postcard through the mail. Anyone handling it along the way can read what is written. Now compare that to sending a sealed envelope; the contents are hidden unless you are the intended recipient. Confidentiality in connected products works in the same way: information must be sealed using cryptography and other safeguards so that only authorised entities can see it.

This requirement means that products must not expose sensitive data in clear form at any point in their lifecycle. It is not enough to simply block access; data must also be protected if intercepted, stolen, or accessed without permission. This applies equally to personal information and operational data that may reveal business processes or system vulnerabilities.

From a technical point of view, this requirement calls for modern encryption standards for data at rest and in transit, strong key management, and isolation techniques that prevent unauthorised access during processing. It also implies system-level measures such as secure storage, encrypted communications (e.g. TLS), and partitioning of confidential data from non-critical components.

Relevant Standards and Guidelines

There is already a strong base of standards that address confidentiality, encryption, and data protection. While the CRA will introduce new harmonised standards, these existing ones are the natural starting point and are likely to form the foundation for compliance. They differ in scope, with some aimed at general IT, others at IoT, and others at industrial systems.

• EN IEC 62443-4-2 (industrial systems): Defines technical security requirements for industrial automation and control system components, including confidentiality of data at rest and in transit. The focus is on OT environments.

• EN 18031 (RED – Radio Equipment Directive): Sets requirements for secure updates and use of cryptography for radio equipment, including encryption and digital signatures.

• ETSI EN 303 645 (consumer IoT): Provides baseline requirements for IoT devices, covering secure communication, cryptography, and protection of personal data. The system is robust in consumer contexts, but it lacks detail in industrial and embedded systems.

• ISO/IEC 9796 Parts 2 and 3 (general IT): Specifies digital signature schemes providing message recovery and protection against forgery.

• ISO/IEC 9797 Parts 1 to 3 (general IT): Defines message authentication codes (MACs) to protect integrity and confidentiality in data exchange.

• ISO/IEC 14888 Parts 1 to 3 (general IT): Covers digital signature mechanisms for ensuring confidentiality, integrity, and authenticity of data.

• ITU-T X.815 (general IT): Defines confidentiality services and mechanisms in open systems, focusing on threats and protections for stored and transmitted data.

Despite this coverage, there are still important gaps.

IEC 62443-4-2 assumes mature industrial infrastructures and does not directly address lightweight or constrained devices.

ETSI EN 303 645 sets consumer IoT baselines but mainly covers basic cryptographic protections and does not fully define how to secure industrial traffic or protect data during processing.

EN 18031 focuses on radio equipment and does not extend to general IoT or embedded systems.

The ISO/IEC standards listed above provide detailed cryptographic algorithms and message authentication schemes, but they do not cover key lifecycle management, practical deployment in constrained environments, or how to update cryptographic mechanisms to remain state-of-the-art. As a result, future CRA harmonised standards will likely expand on these areas to address key management, lightweight cryptography, and confidentiality protection in embedded systems.

How to Approach Implementation

Start by translating the confidentiality requirement into concrete product capabilities. Focus on protecting data at every stage of its lifecycle, when stored on the device, when transmitted across networks, and while being processed.

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

• Encryption of data at rest (e.g. file system encryption, database encryption, or secure elements for keys)

• Encryption of data in transit (e.g. TLS, VPNs, secure fieldbus or protocol wrappers)

• Key management (generation, distribution, rotation, revocation)

• Segregation of sensitive data from non-critical components

• Depending on your risk profile, confidentiality protection during processing (e.g. using enclaves, memory protection, or isolation)

In industrial IoT and OT systems, protecting data confidentiality means securing not only cloud and edge connections but also machine-to-machine protocols. Many widely used industrial protocols, such as Modbus or OPC UA, were not designed with encryption by default and are still deployed in insecure configurations. Under the CRA, continuing to use unencrypted industrial traffic will no longer be acceptable. Solutions affected by the CRA must implement secure versions of these protocols or provide compensating measures such as encrypted tunnels, gateways, or protocol upgrades. This will be a significant challenge in industrial environments where legacy equipment, interoperability requirements, and strict availability constraints have often prevented the adoption of encrypted communication. At the same time, the CRA may act as a turning point by creating the regulatory push needed to make encrypted industrial protocols the new baseline. Over time, this could shift the market toward secure-by-default communication across industrial networks, reducing long-standing risks and aligning practices with modern security expectations.

For embedded IoT devices, the challenge lies in limited memory and compute resources. Lightweight encryption algorithms, secure elements for storing keys, and minimalistic TLS stacks may be required to balance performance with security. Embedded devices must also protect confidentiality against physical access attacks, for example, by encrypting firmware images and configuration files to prevent data extraction.

Critical considerations include keeping cryptographic algorithms and libraries up to date, ensuring secure key bootstrapping during provisioning, and verifying that the chosen methods meet the current state of the art. Confidentiality measures should be tested regularly and adapted as new threats and updated standards emerge. For many products, especially embedded devices, upgrading to entirely new algorithms may not always be feasible due to hardware constraints. In such cases, resilience can still be improved by adjusting key lengths, strengthening configurations, and using the most secure options supported by the hardware. Where possible, systems should also be designed with cryptographic agility so that algorithms and parameters can be updated when required, avoiding the need for major redesigns and ensuring products remain aligned with evolving best practices.

Compliance and Strategic Considerations

From a compliance perspective, it is important to consider that data confidentiality under Requirement (e) also overlaps with obligations from other regulations, such as the GDPR when personal data is processed. To avoid gaps, make sure the Annex VII technical file clearly documents which cryptographic measures are in place, how keys are managed, and how confidentiality is maintained during storage, transmission, and processing.

When deciding between building capabilities in-house or adopting vendor solutions, complexity and dependencies must be carefully weighed. Cryptography is notoriously difficult to implement correctly, and many vulnerabilities stem from improper key handling or insecure defaults. Using proven libraries or platforms can reduce risk, but vendors must be reviewed to ensure their roadmaps remain aligned with CRA expectations.

From a strategic standpoint, this requirement emphasises that confidentiality is no longer a distinguishing factor but rather a fundamental obligation. Companies that embed strong confidentiality measures into their lifecycle from the start will not only comply with CRA but also build trust with customers and reduce operational risk. At a market level, this requirement is likely to accelerate the adoption of secure industrial protocols and modern cryptographic practices, even in domains where cleartext communication has long been the norm.

In our next post, we will explore Requirement (f): Integrity of Data and Functions, which extends beyond confidentiality to ensure that information and system behaviour cannot be tampered with.

Previous Blog CRA Requirement (d): https://www.tributech.io/blog/cra-requirement-d-protection-from-unauthorised-accessNext Blog CRA Requirement (f):https://www.tributech.io/blog/cra-requirement-f-protecting-integrity-of-data-and-functions