CRA Data Confidentiality and Integrity: Encryption, Integrity Controls, and Evidence

The Cyber Resilience Act (CRA) requires products with digital elements, where applicable and based on the manufacturer's cybersecurity risk assessment, to protect both the confidentiality and the integrity of relevant information. Annex I Part I point 2(e) addresses confidentiality of stored, transmitted and otherwise processed personal or other data, including through state-of-the-art encryption and other technical means. Point 2(f) separately requires protection of the integrity of data, commands, programs and configuration against manipulation or modification not authorised by the user, together with reporting on corruptions.

For product teams, the practical task is not to apply encryption everywhere by default. It is to identify which assets need confidentiality or integrity protection, understand the threats and trust boundaries around them, select controls that are proportionate to the product risk, and retain evidence that the released product actually implements those controls.

Start with the two separate CRA objectives

Confidentiality and integrity are related but distinct security properties.

Confidentiality is about preventing unauthorised disclosure of information. Under Annex I point 2(e), this can apply to data at rest, in transit, or otherwise processed. Encryption is explicitly named as an example, but the legal wording also allows other technical means.

Integrity is about preventing unauthorised manipulation or modification. Point 2(f) applies not only to ordinary data, but also to commands, programs and configuration. This matters because an attacker may not need to read protected information if they can change a command, alter executable code, modify a configuration file, replace a firmware package, or tamper with a policy object.

The two controls therefore need separate threat models. A channel may provide confidentiality without giving strong assurance that the endpoint accepts only authorised commands, while an authenticated integrity mechanism may protect a command without hiding its contents.

Make the cybersecurity risk assessment drive scope

The CRA does not define a universal list of data that must be encrypted or one mandatory cryptographic architecture for all products. Annex I Part I point 2 states that the detailed requirements apply on the basis of the cybersecurity risk assessment and where applicable.

A practical scoping exercise should identify:

• data that would create security harm if disclosed;
• credentials, tokens, keys or authentication material;
• product or user data transferred over untrusted networks;
• configuration that changes security behaviour;
• update packages and executable code;
• commands that can alter product state;
• logs or diagnostics containing sensitive operational information;
• locally stored data on removable or service-accessible media;
• data processed by connected or remote services that form part of the product; and
• interfaces where an attacker could inject, replay, reorder or alter messages.

For each item, record the relevant threat, the required security property, the selected control, and the reason that control is proportionate to the product's intended purpose and reasonably foreseeable use.

Protect confidentiality across the full data lifecycle

Confidentiality review should follow the data, not stop at the network boundary.

Useful questions include:

• Where is the data created?
• Where is it stored?
• Which processes can read it?
• Does it leave the device or application boundary?
• Is it copied into logs, caches, crash dumps or backups?
• Is it transferred to remote processing services?
• Can service personnel or local users access the storage medium?
• Does the data remain after reset or decommissioning?
• Which secrets are needed to decrypt or otherwise access it?

Encryption at rest may be appropriate where disclosure of stored information creates material security risk, but the implementation needs more than an algorithm name. Key generation, key storage, key rotation, access control and recovery behaviour can determine whether the protection is meaningful.

For data in transit, encrypted transport is useful only when endpoint identity and trust are handled correctly. Product teams should consider certificate or key validation, downgrade resistance, protocol configuration, credential lifecycle, and whether sensitive traffic can fall back to an unprotected path.

Use state-of-the-art mechanisms without hard-coding one algorithm forever

Annex I point 2(e) refers to state-of-the-art mechanisms. For engineering teams, this argues against treating cryptographic choices as permanent one-time decisions.

A maintainable design should make it possible to:

• replace deprecated algorithms or protocol versions;
• update trust anchors where the architecture permits;
• change certificate or key material;
• disable weak cipher configurations;
• patch cryptographic libraries;
• record which cryptographic profile applies to each supported release; and
• review cryptographic choices when the risk assessment changes.

The CRA does not prescribe one cipher suite in Annex I. Teams should therefore document the rationale for the chosen mechanism and keep the decision linked to the product and release for which it was made.

Treat integrity protection as more than checksums

A checksum can detect accidental corruption, but by itself it is not necessarily protection against deliberate manipulation by an attacker.

For security-relevant integrity, product teams should consider whether they need mechanisms such as:

• authenticated transport;
• digital signatures;
• message authentication;
• signed firmware or software packages;
• authenticated update metadata;
• secure boot or measured boot where appropriate;
• protected configuration stores;
• anti-rollback controls;
• authenticated command channels;
• access-controlled administrative interfaces; and
• tamper-evident audit records.

The correct mechanism depends on the threat. If an attacker can replace both a file and its ordinary checksum, the checksum does not establish authenticity. If a signed update can be replayed to force installation of an older vulnerable version, signature verification alone may not be enough.

Include commands and configuration in the threat model

Annex I point 2(f) explicitly extends integrity protection to commands, programs and configuration. That makes control paths particularly important.

Examples include:

• API calls that change security settings;
• remote device-management commands;
• industrial control commands;
• boot configuration;
• firewall or access-control rules;
• feature flags that enable privileged functionality;
• update policies;
• trust-store configuration;
• recovery and maintenance commands; and
• locally stored configuration files that are writable outside the intended administrative path.

For each security-relevant control path, identify who or what is authorised to make the change, how that authority is authenticated, how the change is validated, and how unauthorised or corrupted state is detected.

Detect and report corruption

Point 2(f) does not stop at prevention. It also requires products to report on corruptions.

The implementation can vary by product, but the team should define what counts as relevant corruption and how the product surfaces it. Depending on the architecture, evidence may include:

• failed signature validation;
• integrity-check failures;
• detected configuration tampering;
• corrupted update packages;
• invalid authenticated messages;
• boot-integrity failures;
• damaged protected storage; and
• alerts or logs generated when protected state cannot be trusted.

The reporting path should be usable by the intended operator or support process. A corruption flag that is generated but never exposed to a responsible user or system may not provide useful operational evidence.

Review key and trust-material lifecycle separately

Encryption and integrity controls often depend on keys, certificates, trust anchors or other secrets. Their lifecycle can be a separate source of risk.

A review should cover:

• how keys or credentials are generated;
• whether production secrets are distinct from development or factory values;
• where secrets are stored;
• which components can access them;
• how trust is provisioned;
• how credentials are rotated or revoked;
• what happens when a key is lost or compromised;
• whether recovery weakens the normal security boundary;
• how old trust material is removed; and
• how the released product state is associated with the relevant key or certificate set.

The evidence does not need to expose private-key material. It should show the design, ownership, configuration and verification decisions that demonstrate how the control is implemented.

Test failure and downgrade cases

A successful encrypted connection or a valid signed package proves only the happy path.

Useful negative testing can include:

• invalid or expired certificates;
• untrusted signing keys;
• modified messages;
• replayed commands;
• corrupted packages;
• altered configuration;
• unsupported protocol versions;
• attempted downgrade to weaker settings;
• missing or inaccessible keys;
• partial storage corruption; and
• recovery from interrupted updates.

The objective is to verify that the product fails safely when confidentiality or integrity assumptions break.

Keep release evidence tied to the exact product state

A practical evidence set can include:

• the cybersecurity risk-assessment entries that establish confidentiality and integrity needs;
• data-flow and trust-boundary diagrams;
• cryptographic design decisions and approved protocol profiles;
• key and certificate lifecycle documentation;
• update and boot integrity design records;
• configuration-protection rules;
• test results for confidentiality and integrity controls;
• negative-test evidence for tampering and downgrade attempts;
• corruption-detection and reporting behaviour;
• release-specific security configuration; and
• records showing that implemented controls match the approved design.

The CRA does not prescribe this exact evidence package. These are practical engineering records that can support technical documentation and lifecycle traceability.

Build the review into release governance

Confidentiality and integrity controls can degrade as products change. New APIs, storage paths, telemetry, remote-processing components, certificate changes or update mechanisms can create new trust boundaries.

A release review can ask:

• Have new data flows or storage locations been introduced?
• Do confidentiality assumptions still match the threat model?
• Are cryptographic protocols and configurations still acceptable?
• Are new commands or configuration paths protected against unauthorised change?
• Are code and update artefacts authenticated where required?
• Have trust anchors, keys or certificates changed?
• Are corruption conditions detected and surfaced?
• Have downgrade and tamper tests passed?
• Does the evidence correspond to the exact product, variant and release?

The gate should support the engineering decision; it should not make the manufacturer's legal conformity decision automatically.

Keeping those risk decisions, security controls, verification records and release scope connected is the operational challenge behind this requirement. AA-sec is designed around traceability between requirements, evidence, decisions and exact product or lifecycle context, which can help teams keep confidentiality and integrity evidence attached to the release it supports. AA-sec does not determine CRA conformity for the manufacturer.

Practical checklist

Before treating confidentiality and integrity requirements as covered for a release, confirm that the team can answer:

• Which data require confidentiality protection, and why?
• Which data, commands, programs and configuration require integrity protection?
• Which controls apply at rest, in transit and during processing?
• Are cryptographic mechanisms and trust decisions documented?
• Are keys, certificates and trust anchors managed across their lifecycle?
• Are update and executable artefacts protected against unauthorised modification?
• Can the product detect and report relevant corruption?
• Have tampering, replay, downgrade and failure cases been tested?
• Are the controls verified on the actual released product state?
• Can the evidence be traced to the relevant product, variant and release?

Key takeaway

CRA confidentiality and integrity are risk-based product-security requirements, not a universal mandate to encrypt every byte. Manufacturers need to identify the information and control paths that require protection, select proportionate state-of-the-art mechanisms, prevent or detect unauthorised manipulation, report relevant corruption, and preserve evidence that the released product implements the intended design.

Official sources

• Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
• Cyber Resilience Act - Manufacturers — European Commission
• Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission