Protecting stored and transmitted data under the CRA requires a data-flow view of the product. Manufacturers should identify sensitive and security-relevant information, determine where it is stored, transmitted and processed, assess confidentiality and integrity threats, apply appropriate access-control and cryptographic protections, manage keys securely and verify that protections remain effective across interfaces, backups, diagnostics and external dependencies.
Stored and Transmitted Data Spans Two Annex I Requirements
The CRA does not contain a separate Annex I point titled protection of stored and transmitted data. Instead, the subject appears directly in the confidentiality requirement at point 2(e) and the integrity requirement at point 2(f). Both refer to stored, transmitted or otherwise processed data. Point 2(e) focuses on preventing unauthorised disclosure, while point 2(f) focuses on preventing unauthorised manipulation or modification. A practical data-security assessment should therefore examine both outcomes. Treating storage encryption alone as the complete CRA data-protection answer can leave transmission, integrity, access-control and processing risks unaddressed.
- Map confidentiality under point 2(e).
- Map integrity under point 2(f).
- Assess storage, transmission and processing.
- Connect controls to the cybersecurity risk assessment.
- Maintain separate evidence for each legal outcome.
Start With a Product Data-Flow Map
Manufacturers need to know where relevant data exists before they can protect it consistently. A product data-flow map can identify data sources, destinations, processing components, local storage, remote services, APIs, message buses, backups, temporary files, caches, diagnostic systems and export functions. It should also identify trust boundaries where information moves between security domains. A diagram alone is not enough if it omits actual runtime behaviour, so teams should compare architecture records with the shipped implementation and configuration. The purpose is to make protection decisions traceable to real data paths rather than a simplified assumption that all important information lives in one database.
- Identify data sources and destinations.
- Identify local and remote storage.
- Identify network and internal transmission paths.
- Identify temporary and diagnostic copies.
- Identify trust boundaries and external services.
Stored Data Can Require Multiple Layers of Protection
Data at rest can include databases, local files, firmware storage, configuration stores, removable media, backups, browser storage and cached information. Encryption can be appropriate where unauthorised access to the storage medium presents a confidentiality risk, but encryption should be considered together with access controls and key management. Integrity can require authenticated storage, signatures, protected configuration, database controls or other mechanisms capable of detecting or preventing unauthorised modification. Products should also consider what happens when sensitive information is copied into temporary files, support bundles or backups because those secondary copies can bypass protections applied to the primary store.
- Identify protected storage locations.
- Apply confidentiality controls where needed.
- Apply integrity controls where needed.
- Protect backup and temporary copies.
- Verify access and cryptographic key boundaries.
Transmitted Data Needs Protection Across Trust Boundaries
Data can be exposed or modified while moving between a product and a cloud service, between devices, across APIs, between local processes or through management interfaces. Transport security can protect many network paths, but teams should understand what the transport endpoint actually protects. If information passes through intermediaries that can read or modify it, end-to-end protections may be relevant for higher-risk use cases. The security assessment should consider server authentication, client or device authentication where appropriate, certificate validation, protocol downgrade, replay, message integrity and error handling. The selected protection should match the product's threat model rather than rely only on the presence of an encrypted connection indicator.
- Identify transmitted security-relevant data.
- Authenticate endpoints where appropriate.
- Protect confidentiality in transit.
- Protect message integrity.
- Consider replay and downgrade threats.
- Test certificate and trust validation.
Encryption Does Not Remove the Need for Access Control
Encryption protects particular threats, but authorised software eventually needs access to many forms of protected data. If an attacker can authenticate as a privileged user, exploit an API authorisation flaw or compromise a process that legitimately holds decryption keys, encrypted storage may offer little protection at that stage. Manufacturers should therefore connect Annex I confidentiality and integrity controls with the separate protection-from-unauthorised-access requirement. Product design should identify who can request data, who can change it, which component performs the access decision and whether the decision can be bypassed through an alternative interface.
- Restrict access to protected data.
- Apply product-specific authorisation.
- Protect administrative interfaces.
- Test alternate data-access paths.
- Keep cryptographic and access-control evidence distinct.
Key Management Is Part of Data Protection
Cryptographic controls depend on keys, certificates and other secrets. Manufacturers should consider how these are generated, provisioned, stored, accessed, rotated, revoked and destroyed. A product that stores an encryption key beside protected data without meaningful separation may provide limited protection against some threats. Shared fleet-wide secrets can create systemic exposure if one copy is compromised. Products relying on operating-system, hardware-security or cloud key-management services should document those dependencies and the assumptions placed on them. Key lifecycle tests can be as important as testing the encryption operation itself.
- Protect key generation.
- Protect key storage.
- Limit key access.
- Plan rotation and revocation.
- Avoid unnecessary shared secrets.
- Verify external key-management dependencies.
Diagnostics and Telemetry Are Part of the Data Flow
Products often create secondary information through logs, crash dumps, telemetry, support exports and debugging features. These paths can contain credentials, identifiers, configuration, customer data or security-sensitive operational information. They can also become integrity targets if attackers can modify diagnostic records used during incident investigation. Manufacturers should therefore include diagnostic and telemetry flows in the same protection analysis as primary product data. Collection should also be reviewed against the CRA data-minimisation requirement so that security tooling does not gather more information than is necessary for the product's intended purpose.
- Review log content.
- Review crash dumps.
- Review telemetry payloads.
- Protect support exports.
- Avoid unnecessary secrets in diagnostics.
- Connect collection decisions to data minimisation.
Protection Needs to Follow Product Changes
New integrations, storage technologies, APIs and cloud services can create data paths that did not exist in the original design. Change control should therefore ask whether a release introduces a new place where relevant information is stored, processed or transmitted and whether the existing confidentiality and integrity controls still apply. A migration from local storage to a remote service, for example, can change trust boundaries and key-management assumptions. The cybersecurity risk assessment, data-flow map and Annex I control mapping should be updated when those changes materially affect the product's data-security risks.
- Review new storage locations.
- Review new interfaces and integrations.
- Review changed trust boundaries.
- Review new third-party services.
- Update verification when protection mechanisms change.
Evidence for Stored and Transmitted Data Protection
A useful evidence package can include data inventories, data-flow diagrams, trust-boundary documentation, cryptographic design records, access-control matrices, key-management design and security test results. Verification can include transport security testing, storage inspection, access-control testing, tamper testing, certificate validation, secret scanning and review of logs or diagnostic outputs. Evidence should identify the relevant product version and configuration. Where protection depends on an external platform, service or deployment control, the assumption should be explicit in the cybersecurity risk assessment and technical documentation.
- Data inventory.
- Data-flow diagrams.
- Trust-boundary analysis.
- Cryptographic control mapping.
- Key-management evidence.
- Access-control tests.
- Confidentiality and integrity verification.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.