CRA confidentiality is broader than a simple requirement to switch on encryption. Manufacturers should identify data whose unauthorised disclosure could create cybersecurity risk, map where that data is stored, transmitted or processed, choose suitable technical protections, manage cryptographic keys securely and verify that sensitive data is not exposed through logs, backups, diagnostics, interfaces or other overlooked product paths.
Annex I Protects Personal and Other Data
Annex I Part I point 2(e) requires products with digital elements, on the basis of the cybersecurity risk assessment and where applicable, to protect the confidentiality of stored, transmitted or otherwise processed data. The wording expressly includes personal data and other data. The requirement therefore should not be reduced to privacy-regulated information alone. Credentials, cryptographic secrets, configuration data, commercially sensitive information, operational information, customer content and security telemetry can all have confidentiality significance depending on the product. The manufacturer's cybersecurity risk assessment should identify which information requires protection and what consequences could follow if an unauthorised party obtained it.
- Identify security-relevant data assets.
- Include personal and non-personal information.
- Assess consequences of unauthorised disclosure.
- Map where sensitive data exists in the product.
- Connect confidentiality controls to the risk assessment.
Map Data Across Storage, Transmission and Processing
The CRA wording covers stored, transmitted and otherwise processed data, which means confidentiality analysis should follow data through the product rather than focus on a single database or network connection. Sensitive information can exist in application storage, files, device memory, caches, backups, temporary files, browser storage, diagnostics, crash reports, message queues, APIs, local buses or remote services. Data-flow diagrams can help identify these paths and the trust boundaries they cross. The analysis should also consider administrative interfaces and support functions because privileged tools can expose information that ordinary user interfaces do not. Product teams should know where confidentiality depends on the product itself and where it depends on an external service or deployment environment.
- Map stored data.
- Map network and inter-process transmission.
- Map temporary and cached copies.
- Map backups and diagnostic outputs.
- Identify trust boundaries and external dependencies.
Encryption Is an Important CRA Confidentiality Mechanism
Annex I point 2(e) specifically gives encryption of relevant data at rest or in transit by state-of-the-art mechanisms as an example of confidentiality protection. This does not mean that every byte handled by every product must be encrypted identically. The requirement is applied through the cybersecurity risk assessment and concerns relevant data. Manufacturers should identify where encryption is necessary, which threats it addresses and whether another technical control is needed in addition to or instead of encryption for a particular data path. Transport encryption can protect data across an untrusted network, while storage encryption can protect certain data if storage media or files become accessible. Neither automatically prevents an authorised but compromised process from accessing plaintext while the product is using it.
- Identify data that requires cryptographic protection.
- Protect relevant data in transit.
- Protect relevant data at rest where appropriate.
- Consider data while actively processed.
- Document why the selected mechanism addresses the risk.
State of the Art Is Not a Permanent Algorithm List
The CRA refers to state-of-the-art mechanisms rather than naming a fixed algorithm or protocol in Annex I point 2(e). That is important because cryptographic technology and accepted security practice change over time. Manufacturers should therefore maintain a defensible cryptographic baseline and review it as protocols, algorithms, key sizes, implementation guidance and known weaknesses evolve. A mechanism that was considered appropriate when a product was first designed can become unsuitable during a long support period. Product architecture should make necessary cryptographic maintenance possible where feasible, and change management should assess whether updates to libraries, certificates, protocols or cryptographic settings affect the product's confidentiality evidence.
- Maintain an approved cryptographic baseline.
- Review deprecated protocols and algorithms.
- Track relevant cryptographic dependencies.
- Plan for certificate and key changes.
- Reassess controls during the support period.
Key Management Can Determine Whether Encryption Is Effective
Encryption can provide little practical confidentiality if cryptographic keys are exposed, shared unnecessarily or stored alongside protected information without adequate protection. Product teams should therefore include key lifecycle design in the confidentiality analysis. Depending on the product, this can include key generation, provisioning, storage, access, rotation, revocation, backup and destruction. Secrets embedded identically across all shipped products can create systemic risk if compromise of one device exposes the wider fleet. Products that rely on operating-system, hardware or cloud key-management capabilities should document the dependency and the security assumptions involved. Testing should confirm not only that cryptography is invoked, but that keys and secrets are handled according to the intended design.
- Protect key generation and provisioning.
- Limit access to cryptographic keys.
- Avoid unnecessary shared secrets.
- Plan rotation and revocation.
- Verify key storage and destruction behaviour.
Access Control and Confidentiality Work Together
Encryption is not the only confidentiality control. Authentication and access management determine which users, services and components can legitimately obtain data. A product may encrypt its database but expose the same sensitive information through an unauthorised API request or overly broad administrative role. CRA Annex I point 2(d) and point 2(e) therefore address related but distinct outcomes. Point 2(d) focuses on protection from unauthorised access, while point 2(e) focuses on confidentiality of data. A strong design maps both: who can reach the data, under which identity and permissions, and how the information is protected while stored, moved and processed. Evidence should remain requirement-specific even where the same technical mechanism contributes to both outcomes.
- Restrict access to sensitive data.
- Apply least privilege where appropriate.
- Protect administrative data paths.
- Test object-level data access.
- Map shared controls to each Annex I requirement.
Logs and Diagnostics Can Accidentally Defeat Confidentiality
Sensitive information is often exposed through secondary product functions rather than the primary storage path. Debug logs can contain credentials, access tokens, personal data, request bodies or cryptographic material. Crash reports can capture memory contents. Support bundles can collect configuration and customer information. Telemetry can transmit identifiers or operational data to remote systems. Manufacturers should include these paths in the confidentiality assessment and minimise unnecessary sensitive content. Where diagnostic data is necessary, access, retention and transmission protections should be appropriate to the risks. Security logging requirements do not require products to record secrets that create new confidentiality risks.
- Review logs for sensitive information.
- Review crash and diagnostic data.
- Review telemetry payloads.
- Protect support bundles and exports.
- Avoid recording passwords, tokens or cryptographic secrets unnecessarily.
Confidentiality and Integrity Are Separate CRA Outcomes
Confidentiality concerns preventing unauthorised disclosure. Integrity concerns preventing unauthorised manipulation or modification. Annex I treats these as separate requirements. Encryption can sometimes support both outcomes when used with mechanisms that also authenticate data, but using encryption does not automatically prove that every integrity risk is addressed. Likewise, an integrity control such as a digital signature does not necessarily keep the signed content secret. Product teams should therefore avoid combining confidentiality and integrity into one broad statement such as data is encrypted. Each requirement should have its own threat analysis, controls, tests and evidence even where the implementation technologies overlap.
- Confidentiality protects against unauthorised disclosure.
- Integrity protects against unauthorised modification.
- Some cryptographic mechanisms support both.
- Maintain separate requirement mappings and verification.
Evidence for CRA Confidentiality Requirements
A useful evidence package begins with the product's data inventory and data-flow model. It can then identify which information requires confidentiality protection, the trust boundaries involved, the access controls applied, cryptographic mechanisms, key-management design and verification results. Tests can include transport security validation, storage inspection, permission testing, API access-control testing, secret scanning, log review and checks for insecure fallback behaviour. The evidence should identify the relevant product version and configuration. Where confidentiality depends on a deployment assumption or external system, that dependency should be explicit rather than left as undocumented operational knowledge.
- Data inventory and classification.
- Data-flow and trust-boundary diagrams.
- Cryptographic design decisions.
- Key-management documentation.
- Access-control mapping.
- Confidentiality security tests.
- Product-version-specific evidence.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.