Annex I (2)(e) Confidentiality of data: CRA evidence

What Annex I Part I (2)(e) confidentiality of data asks of your product

Annex I Part I point (2)(e) requires that a product with digital elements, when placed on the EU market, protects the confidentiality of data it stores, transmits or otherwise processes, whether that data is personal or not. The usual route is encryption at rest and in transit using state of the art mechanisms, backed by other technical means where encryption alone does not close the gap. You do not pick these mechanisms from a fixed list. You choose them through your Article 13(2) cybersecurity risk assessment, which must record the data the product handles, the threats to it, and why the controls you chose are proportionate. A market surveillance authority will look for that reasoning as much as for the encryption itself.

The hard part is rarely the cipher. It is knowing where data actually sits. Product teams often miss copies in logs, crash reports, caches, backups, temporary files, message queues, third-party analytics SDKs and support exports. Key handling is the second gap: who generates keys, where they are stored, how they rotate, and what happens to them when a device is resold or a tenant leaves. Confirm with your engineering leads which data classes exist, which of them the risk assessment has classified, and which key owner is named for each. Keep a short data flow record per product so you can show that each choice was deliberate.

Confidentiality failures are often underestimated in products that look like they handle little sensitive data. A device that only collects sensor readings may still expose account credentials, location history, or configuration that reveals the network it sits on. A developer tool may hold access tokens that unlock customer repositories. The risk is unauthorized disclosure, and its impact depends on what an attacker can link the data to, not on how sensitive the product's marketing says it is. Treat every data class as in scope until the risk assessment shows otherwise, and record that conclusion so an assessor can follow it.

Which data, interfaces and components are in scope for point (2)(e)

Point (2)(e) applies to every place where the product stores, transmits or processes data, so the first job is to map those places. Each scoping decision below changes the engineering and evidence work, and the risk assessment should record why any data store or interface is left out.

Data at rest in stores and backups

Databases, file stores, backup sets, log archives and caches all hold data that point (2)(e) reaches, including data written by the product on local device storage. Backups are often missed because they sit outside the application's normal path. For each store, check whether relevant data is encrypted with a state of the art mechanism, where the keys live, and who can read them. Confirm every backup target is in the inventory.

Data in transit across interfaces

External interfaces such as user-facing APIs, web sessions, management consoles and telemetry uplinks carry data across trust boundaries. Internal links between services, containers or nodes are often plaintext by default and still count as transmission. Update channels and remote support sessions also belong on the list. Test each link for protocol version, cipher choice and certificate validation rather than assuming the transport is encrypted.

Data in memory and processing

Data is also exposed while the product processes it. Memory, temporary files, swap space, crash dumps and in-process caches can hold personal or other sensitive data long after a request completes. Third-party services that receive data for processing, such as analytics, storage or AI inference endpoints, extend the boundary of the product. Document which of these locations hold data, how long they keep it, and whether the product clears them.

Key and certificate material

Encryption is only as strong as the protection of its keys. Encryption keys, signing keys, TLS private keys and certificate authority material need their own storage, access and rotation rules. Key management and certificate management systems are themselves a regulated product category under Implementing Regulation (EU) 2025/2392, so treat them as part of the scope. Confirm how keys are generated, where they are stored, how they rotate and how a compromised key is revoked.

Excluded stores and recorded reasons

Some data stores may be legitimately out of scope, for example a cache that holds only public content or a test fixture that never contains production data. Each exclusion changes the evidence the assessor will ask for, so it needs a written reason. The risk assessment should name the excluded store, the data it holds, the reason it is excluded and the check that supports that reason. Review the list when the architecture changes.

Product type sets the boundary

The data a product touches depends on what it does. A product that runs on a customer's premises has different stores and links from one that sends telemetry to a vendor backend, and both differ from a component delivered to an integrator. Map the product's intended purpose first, then the data flows that purpose requires. Ask your product or compliance team to confirm the product category before drawing the boundary.

How an assessor tests confidentiality of data for the CRA

This table shows what an assessor checks for Annex I Part I point (2)(e), how they test each area, and the evidence they ask for. Read each row as a question the manufacturer must answer with a documented design and a configuration that matches it. The main takeaway is that a documented encryption choice only counts if the test build shows the product behaves the same way.

Assessment area	Test approach	Evidence requested	Common findings
Data inventory and classification	Compare the data inventory against the cybersecurity risk assessment and check that every personal or other sensitive data flow is covered.	Data inventory listing stores, transfers and processing, with classification and the risk assessment entry that drives each protection.	Logs, backups, telemetry or support bundles missing from the inventory.
Encryption design for data at rest	Read the design, then sample stored data on a test build to confirm encryption is enabled for each store.	Storage design, encryption settings per store, and configuration exports from the test build.	Encryption enabled for the main database but not for search indexes, attachments or exports.
Encryption design for data in transit	Review allowed protocol versions and cipher suites, then capture traffic from a test build to confirm the documented settings apply.	Protocol and cipher configuration, certificate handling notes and captured test results.	Legacy protocol versions still accepted on internal or administrative interfaces.
Key generation, storage, rotation and access	Trace how keys are created, where they live, who can read them and how rotation runs on a test build.	Key lifecycle procedure, access control lists for key stores, and rotation records or test logs.	Keys stored on the same volume or in the same configuration file as the data they protect.
Justification for unencrypted data or fallback	Search the design and the test build for any plaintext path, fallback mode or exception, then check each has a recorded reason.	Written justification tied to the risk assessment, plus the configuration that controls each fallback.	Fallback to plaintext when encryption fails, with no documented decision or alert.
Technical means beyond encryption	Check whether other measures such as tokenization, access restriction or secure deletion are used where encryption alone does not protect the data.	Description of each measure, the data it protects, and test results showing it works.	Measures described in the design but not present in the shipped configuration.
Undocumented plaintext caches and temporary files	Run representative workflows on a test build and inspect caches, temporary directories, logs and crash dumps for unencrypted copies.	Test records listing where data was observed, and the design decision for each location.	Plaintext caches in browsers, temporary files or application logs that the design never mentions.

Evidence that shows confidentiality of data is protected

Point (2)(e) is tested by looking at what data the product handles, how it is protected where it sits and moves, and who can reach the keys. The artifacts below connect those answers to the risk assessment, and each one needs a refresh trigger so it stays accurate through the support period.

Data flow and store inventory

A current map of every place the product stores, transmits or processes personal or other data, tied to the Article 13(2) risk assessment that decided which data needs protection. Check that each store (databases, object storage, logs, backups, caches) appears with its encryption status. Review the inventory whenever a feature adds a new data path or a new third-party service receives data.

Encryption configuration baselines

Written baselines for each store that name the cipher, key length and mode the product uses, plus the setting keys that enforce them. For server-side encryption in Nextcloud, for example, the baseline should state that file contents are encrypted at rest with keys held on the server and that file names and folder structure are not encrypted. Keep the baseline under version control and record every change with its reason.

Transport security test results

Evidence that data in transit uses current TLS versions and accepted cipher suites, gathered by scanning every external and internal endpoint and comparing the results with the baseline. Regenerate the scan on each release and after any change to certificates or load balancers, and keep the output with the release record. Confirm which endpoints are excluded and why.

Key management design and access logs

A design document showing where keys are generated, stored, rotated and destroyed, and who can use them. Where the product relies on a transit engine such as OpenBao, record how versioned keys and rotation are configured. Retain access logs for key operations and review them against the list of authorized operators. Ask whether key material ever leaves a hardware or managed boundary.

Exception decision record with compensating measure

Where a store or channel cannot use the baseline mechanism, a dated decision record that names the component, the reason, the risk accepted, the approver and the compensating measure, such as network isolation or field-level protection. Review every exception at each release and close it when the component is replaced. Reviewers will look for exceptions that have no owner or no expiry.

Technical documentation on confidentiality mechanisms

The section of the technical documentation that describes, in plain terms, which mechanisms protect data, why each one is state of the art for its use, and how an operator configures or verifies it. It should cross-refer to the inventory, baselines and test results rather than repeat them. Update it with each release so that it matches the shipped configuration.

How to implement point (2)(e) in a product, step by step

This sequence takes a product team from knowing what data it handles to showing, with records and test results, that confidentiality protections are on by default and matched to the risk assessment. Each step closes with an artifact that an assessor or market surveillance authority can review.

Map data stores and data flows
The product team, with the security and privacy leads, lists every place the product keeps data (databases, file storage, caches, backups, logs, temporary files) and every interface that moves data in or out (APIs, sync channels, integrations, admin consoles, support exports). Include data processed only in memory if it can be written to disk. The output is a data inventory and a data flow diagram that the risk assessment under Article 13(2) can reference. You know this step is done when every store and interface has an owner and a named data category.
Classify data against the risk assessment
Using the documented cybersecurity risk assessment, the team assigns each data category a sensitivity level and records which categories contain personal data or other data whose exposure would cause harm. The security lead confirms the classification and the reasons for it. The output is a classification register that links each store and flow to the protection level it needs. This step is complete when no store or flow lacks a classification and the register has been reviewed and approved.
Select encryption and transport mechanisms
For each store and interface, the architect chooses the mechanism that protects confidentiality in transit and at rest, using state of the art algorithms and protocols and any other technical means the risk assessment calls for. Where the product relies on a third-party component, the team confirms that component's encryption behavior and its limits, such as whether file names or folder structures are encrypted. The output is a cryptographic design record per store and interface, including known gaps. The step is done when each entry names the mechanism, the key it uses and the decision rationale.
Implement key management and rotation
The engineering team builds or integrates a key management approach that generates, stores, rotates and retires encryption keys, keeping key material separate from the data it protects. Key access is limited to the services that need it, and rotation procedures are written down and tested. Where a certificate authority or secrets engine is used, its configuration becomes part of the design record. The output is a key management specification and a rotation runbook. The step is complete when a rotation has been executed in a test environment and the logs confirm the old keys were retired.
Configure encryption as the default
The product team sets encryption on in the default configuration so that customers, integrators and administrators do not have to enable it manually to get protection. Any option to disable encryption is either removed or restricted and logged, and any exception is documented with the risk owner's approval. The output is a default configuration file or installer profile and a list of settings that differ from the default. The step is done when a fresh installation, with no changes, shows encryption active on every store and interface in the classification register.
Verify with automated and manual tests
The quality and security teams build automated checks into the build and release pipeline that confirm encryption is active, that weak protocols and ciphers are rejected, and that data is unreadable in a raw read of the storage layer. Manual testing, including penetration testing of the interfaces and a review of the key handling, covers what automated checks miss. The output is a test plan, the test results for each release, and a list of findings with their status. The step is complete when failed checks block release or are accepted through a documented risk decision.
Record decisions and test results as evidence
The product owner assembles the technical documentation that connects the data inventory, classification register, cryptographic design records, key management specification, default configuration and test results. Each decision is traceable to the risk assessment, and each record names the person who approved it and the release it applies to. The output is a versioned evidence pack that is updated at every release through the support period. Ask your conformity assessment body or notified body which format they expect, and confirm with them whether the evidence pack is sufficient.

Which self-hosted open-source tools can support confidentiality evidence

Four self-hosted open-source tools each cover a different part of confidentiality: encrypting stored files, encrypting application data in transit and at rest, issuing certificates, and renewing TLS for workloads. Each one produces configuration and logs that can support evidence for Annex I Part I (2)(e), but none makes a product compliant on its own. Confirm each capability against your own version and configuration before you rely on it.

Nextcloud server-side encryption

Server-side encryption protects file contents at rest on local and external storage, with keys held on the server. It does not encrypt file names or folder structure, so metadata remains visible to anyone with access to the storage. Record that gap in the risk assessment and decide whether it is acceptable for the data you hold. Confirm the encryption settings and key handling in your deployment, since the configuration determines what is actually protected.

OpenBao transit secrets engine

The transit engine encrypts and decrypts application data without storing that data in OpenBao, so applications keep ciphertext in their own databases. It also signs and verifies data and supports versioned encryption keys with rotation. Check who can call the encrypt and decrypt endpoints, how key rotation is scheduled, and whether old key versions remain available to decrypt existing ciphertext. Confirm these behaviors against the version you run.

FreeIPA integrated certificate authority

FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates across an identity domain. This matters for confidentiality because TLS protection of data in transit depends on certificates that are issued, tracked and revoked under a known process. Document who may request certificates, how revocation works, and where the CA signing keys are protected. Confirm the CA setup and certificate lifecycle in your own environment.

cert-manager TLS in Kubernetes

cert-manager creates TLS certificates for workloads in Kubernetes or OpenShift from configured issuers, such as ACME, a CA key pair, HashiCorp Vault, CyberArk or self-signed issuers. It stores certificates in Kubernetes Secrets and renews them before they expire. Review which issuers are configured, who can read the Secrets that hold private keys, and how expiry alerts are handled. Confirm issuer configuration against the cert-manager release you deploy.

What meeting point (2)(e) costs in money and effort

This table compares the cost components of meeting Annex I Part I point (2)(e) for confidentiality of data, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to build a quote request, because most of the price difference between offers comes from the data inventory and key management scope. Figures are not given here, so ask each provider for a written scope before comparing numbers.

Cost component	One-time or recurring	What drives it	How to keep it down
Engineering time for data mapping and encryption design	One-time, revisited when data flows change	Number of data stores, interfaces, backups and third-party services that hold or move data	Keep an inventory of data stores and transfers up to date, and reuse the same design pattern across products
Engineering time for implementation and key management	One-time, with ongoing operations	Number of encrypted stores, key hierarchy complexity, and whether keys are generated, rotated and revoked automatically	Use existing key management services with documented rotation, and avoid bespoke cryptography
Tooling and licenses	Licenses recurring for commercial tools, infrastructure recurring for self-hosted tools	Commercial key management or secrets products, and the hosting capacity needed to run self-hosted open-source components	Self-hosted open-source licenses carry no license fee, but infrastructure and staff time remain. Confirm each component's license terms before deployment
Evidence upkeep per release	Recurring with every release and support period update	Number of test cases for encryption settings, the frequency of configuration changes, and how much evidence is collected by hand	Automate configuration checks in the build pipeline and store results with the technical documentation
External penetration testing or design review	Recurring, often tied to major releases or changes in data handling	Size of the attack surface for stored and transmitted data, and the depth of review requested	Scope the test to the data stores and interfaces named in the risk assessment, and ask for findings mapped to point (2)(e)
Auditor or notified body sampling	Recurring when the conformity route requires assessment	Route chosen under the conformity assessment, the number of products in scope, and the completeness of evidence	Prepare evidence in a form that can be sampled quickly, and confirm with the assessor which documents they will request

Who owns, implements and tests confidentiality of data

Your organization owns the confidentiality decisions. The manufacturer is responsible for the cybersecurity risk assessment that determines which data is sensitive, which encryption mechanisms count as state of the art for the product's context, and how residual risk is accepted. These decisions sit with product security, legal and the accountable product owner, because they carry regulatory consequences. Even when partners do the configuration work, the decisions and their reasoning must be recorded in your technical documentation.

Data classification: Decide which stored, transmitted and processed data is personal or otherwise sensitive, and record the classes in the risk assessment.
Key ownership: Name who owns root keys, who can request key rotation and who approves key recovery procedures.
Mechanism choices: Approve the algorithms, key lengths and protocol versions, and document why they are state of the art for your product.
Residual risk acceptance: Record who signs off on any remaining exposure, such as metadata that stays visible or keys held in a shared environment.
Evidence ownership: Keep the technical documentation current across the support period.

Before accepting any partner deliverable, check that every classification and key decision traces back to a named owner and a dated record.

Where confidentiality of data programs usually fall short

Most confidentiality failures under Annex I Part I (2)(e) do not come from weak cipher choices. They come from data the design never counted, keys kept next to the data they protect, and evidence that describes a release nobody shipped. The cards below pair each gap with the check that closes it.

Data stores missing from the inventory

Logs, caches, backups, crash dumps and temporary files often hold the same personal or other sensitive data as the primary database, yet they sit outside the data inventory that the risk assessment uses. Under point (2)(e), each store that holds processed data needs to be listed with its encryption method. Check every log sink, object-storage bucket, backup target and scratch volume against the inventory before you rely on encryption for the main store.

Unprotected file names and metadata

Teams often assume full encryption and then find that file names, folder structure and sizes are readable on disk. Nextcloud's server-side encryption, for example, protects file contents but does not encrypt file names or folder structure. Document which metadata stays visible, decide whether that exposure is acceptable in the risk assessment, and tell users what the product does not hide.

Keys stored beside the data

When the encryption key sits in the same volume, configuration file or database row as the ciphertext, encryption adds little protection against anyone who copies the store. Move key material into a dedicated key management service with its own access policy and audit trail. A transit encryption engine such as OpenBao can encrypt application data without storing it, and its versioned keys allow rotation without re-exposing old data.

Silent fallback to plaintext

Legacy interfaces, older API versions and migration paths often accept unencrypted connections so that old clients keep working. Each fallback quietly removes the protection that the design describes. Inventory every listening port and protocol version, disable plaintext where the product supports it, and record any remaining exception with its owner and removal date in the technical documentation.

Certificates that expire without renewal

Transport encryption fails when a certificate lapses, and manual renewal tends to be forgotten between releases. Automate issuance and renewal with a tool such as cert-manager, which creates TLS certificates for Kubernetes or OpenShift workloads from configured issuers, stores them in Kubernetes Secrets and renews them before expiry. Confirm which issuer each service uses and who owns the internal certificate authority, since certificate issuance software is itself a class I important product category.

Evidence that is never regenerated

Encryption configuration, cipher lists and key inventories are often captured once for an initial assessment and then left unchanged while the product ships new versions. Regulators and auditors will look at the release in front of them. Set up a process that regenerates the encryption evidence for each release and keeps it linked to the risk assessment, so the documentation describes what was actually shipped.

Questions buyers ask about confidentiality of data under the CRA

How much effort does the confidentiality requirement add to an existing product?

The effort depends on how much of the product already encrypts data and how well that encryption is documented. Most of the work sits in the inventory: identifying every store, queue, log, backup and network path that carries personal or other sensitive data, then checking whether each one is protected at rest and in transit by a state of the art mechanism. Products that already use TLS everywhere and encrypt their databases usually have a smaller gap than products that write plaintext files, caches or telemetry. Retrofitting key management is often the largest single driver, because it touches deployment, backup and recovery procedures. Ask any partner for a written gap analysis before agreeing a fixed scope, and ask what it will cover for each data flow.

Can an in-house team meet the confidentiality requirement without outside help?

Yes, many in-house teams can, provided they have engineers who understand cryptography, key lifecycle and the product's data flows, and provided they can document the result for an assessor. The harder parts are usually not the cipher choice but the consistency: every data path must be covered, keys must be rotated and revoked, and the reasoning behind each choice must be recorded in the risk assessment and technical documentation. Teams without a dedicated security architect often find that gap analysis and evidence gathering take longer than the engineering itself. An outside partner can prepare systems and evidence, but the manufacturer keeps ownership of the product and its conformity decisions.

What does the requirement ask from engineers and product owners?

Engineers need to map data flows, select and configure encryption for data at rest and in transit, and build key handling into deployment and recovery. Product owners need to decide which data the product truly stores or processes, because that decision shapes what must be protected, and to agree on how the product behaves when a user exports, deletes or transfers data. Both groups should expect to review the same artifacts:

A data flow inventory covering storage, transit, logs and backups
The encryption and key management design for each flow
Test results showing that data is unreadable without the authorized key
Records of decisions, including any mechanism that was judged not state of the art and why

How long does a typical scoped engagement take?

Timing depends on the written scope. The number of products, the number of data stores and flows, the state of the existing encryption and the amount of key management change all shape the schedule. Engagements that are limited to a single product with well-documented flows generally move faster than those that span several products or require new key infrastructure. Ask for milestones tied to deliverables, such as the gap analysis, the design, the implementation and the evidence pack, and confirm which items depend on your own review cycles or on decisions from your product owners.

Does encrypting data alone satisfy the confidentiality requirement?

No. Point (2)(e) asks for protection of confidentiality through encryption where it is relevant and through other technical means as well. Encryption protects content, but it does not control who can request decryption, which is why access control under point (2)(d) and key handling matter so much. Metadata, file names, folder structure, logs and error messages can leak information even when content is encrypted. For example, the Nextcloud server-side encryption documentation states that file names and folder structure are not encrypted, so a product built on it would need additional measures or a documented justification for that residual exposure. Your risk assessment should record each residual exposure and the reason it was accepted.

Can an open-source product rely on the same evidence as a commercial product?

The evidence types are the same, but the responsibility sits in a different place. Open-source components can supply strong encryption primitives and well-documented configuration options, and their public documentation can support parts of your analysis. However, the manufacturer, or the steward where that applies, must still show how the component is configured in the product, what it does not cover, and how keys are managed in the deployed system. Evidence should come from your own configuration, tests and records, not only from the upstream project's documentation. Confirm the license terms and the support status of each component before you rely on it in a product placed on the market.

Which parts of the confidentiality work should be outsourced?

Organizations commonly outsource the parts that need specialist depth or independent perspective: the data flow and gap analysis, the design of key management, the hardening of encryption configuration, and the preparation of test evidence. The manufacturer should keep the decisions about which data the product needs, the residual risks it accepts and the conformity documentation it signs. Independent assessors and notified bodies, where required, perform their own review, and no implementation partner issues reports or certificates. Ask a partner to state in writing which deliverables they prepare, which they review with you and which remain your responsibility.

How DeployOpen scopes and prepares confidentiality evidence

DeployOpen works on Annex I Part I (2)(e) by planning and implementing the encryption, key management and certificate controls inside your own infrastructure, then documenting them so your team and independent assessors can check them. DeployOpen prepares systems and evidence; the manufacturer owns the conformity decision and any notified body issues the outcome.

How we scope

Inventory the stored, transmitted and processed data flows the product handles, including personal data, and record them in the written scope.
Agree which encryption at rest and in transit mechanisms apply to each flow, tied to the manufacturer's cybersecurity risk assessment.
Confirm the key management and certificate issuance components in scope, and which ones your team keeps responsibility for.

How we build

Deploy and configure encryption at rest for file storage, keeping keys on the server side where the chosen platform supports it.
Configure a secrets and transit encryption service with versioned keys and a documented rotation schedule.
Set up internal certificate authority and TLS certificate automation so workloads renew certificates before they expire.

How we hand over

Deliver configuration records, key lifecycle procedures and a map of which data flows are encrypted and by which mechanism.
Document known limits, such as metadata or file names that some platforms do not encrypt, so the residual exposure is recorded.
Provide test results showing encryption and certificate settings were verified, in a format your assessor or notified body can review.

How we support

Fixed-scope engagements set deliverables and timelines in writing before work starts, so you know what is covered.
Ongoing support, upgrades and continuous testing are available as a retainer to keep encryption configuration current through the support period.
Confirm with your assessor which evidence they expect before the handover, since DeployOpen does not issue reports or certificates.