Cyber Resilience Act Technical Documentation: Building the Evidence File

Julian Meroi · Published 22 October 2026 · Last reviewed 22 October 2026

Before a product with digital elements is placed on the EU market, its manufacturer must draw up technical documentation showing how the product and the manufacturer’s vulnerability handling processes meet the essential cybersecurity requirements in Annex I. Annex VII lists what that documentation must contain at a minimum. This guide explains how to assemble the evidence for a specific product release, check it against Annex VII and keep it current. Article 31, Article 13(12), Annex VII.

The obligation applies from December 11, 2027. Products placed on the market before that date fall under the CRA’s requirements only if they are substantially modified from that date. The Article 14 reporting obligations already apply, including to those earlier products. Article 71(2), Article 69(2)-(3), CRA reporting requirements guide.

What the technical documentation has to show

Article 31(1) requires the technical documentation to contain all relevant data or details of the means the manufacturer uses to ensure that the product and its processes comply with Annex I. It must contain at least the elements in Annex VII, as applicable to the product. The documentation therefore covers two things: the product itself, against Part I of Annex I, and the vulnerability handling processes, against Part II. Article 31(1), Annex I.

Market surveillance authorities can request the documentation, so the Commission services’ FAQ advises that it be comprehensive and clear. The CRA sets no single general-purpose file format or software tool for it. The one specified format is the simplified form for micro and small enterprises described below: an enterprise that opts for it must use the form the Commission specifies. A collection of policies or a passing vulnerability scan does not on its own show how a specific product meets the requirements. Commission FAQ, section 6.6.

Define the product and release the file covers

Start by fixing what the documentation describes. Annex VII point 1 asks for the product’s intended purpose, the versions of software affecting compliance with the essential requirements, photographs or illustrations of external features, marking and internal layout where the product is hardware, and the Annex II user information and instructions. Annex VII, point 1, Annex II.

The cybersecurity risk assessment needs the same boundary. Article 13(3) bases it on the intended purpose and reasonably foreseeable use, the conditions of use such as the operational environment and the assets to be protected, and the length of time the product is expected to be in use. Record which hardware, firmware, software and supplied components the release includes, and which remote data processing forms part of the product. Our CRA product classification guide explains how to settle the product boundary and its category. Article 13(3).

A practical way to keep this boundary stable is a release baseline: the product name and model, the release identifier and the exact software versions it ships with, frozen when the evidence is compiled.

This is an example of implementation based on CRA Annex VII point 1 and Article 13(3). The CRA does not mandate a release baseline, a particular version identifier, a Git commit reference or a specific tool.

Check Annex VII against the evidence you already have

Most teams already hold part of the required material: architecture documents, a risk register, test reports, a security policy. The table maps each Annex VII point to the questions that decide whether existing material covers it. The Annex VII page carries the full legal wording.

Two points need care. The support period reflects the length of time the product is expected to be in use, taking into account reasonable user expectations and the product’s nature. It must be at least five years unless the product is expected to be in use for less time, and the manufacturer records the information used to set it. Existing evidence prepared for other frameworks, such as IEC 62443 assessments or NIST SSDF practices, can be reused only within its actual product, version and process scope. Presumption of conformity comes only from harmonized standards whose references are published in the Official Journal, common specifications and the relevant certification schemes, and only for the requirements they cover. Article 13(8), Article 27.

Connect risks, requirements, measures and test results

An assessor reading the file needs to follow a path from each requirement to the evidence for it. Article 13(3) requires the risk assessment to indicate whether, and if so how, the Part I(2) requirements apply to the product and how they are implemented, as informed by the assessment. It must also indicate how the manufacturer applies Part I(1) and the vulnerability handling requirements of Part II. Where an essential requirement does not apply, Article 13(4) requires a clear justification in the technical documentation. Our CRA risk assessment guide shows how to work through the Annex I requirements and record these decisions. Article 13(3)-(4).

Some requirements can be met only partly because of the product’s intended purpose. The Commission guidance gives the example of a product that must interoperate with existing systems supporting only an older, less secure protocol. In such cases the manufacturer documents the constraint, assesses the associated risks and implements alternative or compensatory measures. Where the product can support both protocols, the secure one is expected to be implemented and enabled by default. The guidance also expects manufacturers to reassess periodically whether such constraints still exist. This covers genuine constraints only: it does not allow a requirement to be set aside for convenience. Commission guidance, paragraph 32 and example 10.

A traceability chain makes these relationships visible: requirement, identified risk, implemented measure or justification, and the test report that verifies the measure.

This is an example of implementation based on CRA Article 13(3)-(4), Annex VII points 3 and 6 and Commission guidance paragraph 32. The CRA requires the risk assessment, justifications and test reports; it does not mandate this chain format or a particular test method.

Example: an evidence index for one release

Example Product 2.3 is a hypothetical network-connected device with firmware 2.3.0 and a companion mobile app supplied with it. Its classification is assumed to have been determined already; nothing below depends on its category. Four rows of its evidence index:

This is an example of implementation based on CRA Article 31, Article 13 and Annex VII. The CRA does not mandate these index fields, owners or this workflow, and the index is not an official form.

The last row shows a single measure verified for a single release. One test report does not demonstrate conformity with Annex I as a whole; the index is useful precisely because it shows which requirements still lack evidence.

Review the file before conformity assessment

Before the conformity assessment procedure starts, check the file for internal consistency:

• product names, model numbers and version identifiers are identical across the description, risk assessment, SBOM and test reports;
• every Part I(2) requirement is addressed or justified as not applicable;
• the vulnerability handling evidence covers the SBOM, the coordinated vulnerability disclosure policy, the reporting contact and secure update distribution;
• standards and specifications are listed with the parts applied;
• open findings are recorded with their status.

This checklist is an example of implementation based on Annex VII and Article 13(3)-(4). The CRA does not mandate this internal checklist; the documentation contents and the applicable conformity assessment procedure remain mandatory.

Compiling the documentation is not the conformity assessment itself. The manufacturer carries out the chosen procedure under Article 32 or has it carried out, depending on the product’s category. Where a notified body is involved, the technical documentation and correspondence relating to the procedure must be in an official language of the Member State where the notified body is established, or in a language acceptable to that body. Article 32, Article 31(4).

Our CRA conformity assessment guide explains each procedure and the evidence to prepare.

The EU declaration of conformity is drawn up once the procedure has demonstrated compliance, and a copy then becomes part of the technical documentation. A declaration prepared earlier should stay clearly marked as a draft. Article 13(12), Article 28.

Keep, update and provide the documentation

Updating. The technical documentation must be continuously updated, where appropriate, at least during the support period. Manufacturers must also document relevant cybersecurity aspects of the product, including vulnerabilities they become aware of, and update the risk assessment where applicable. For series production, changes in design, production or the standards applied must be taken into account. When a supplier provides a certificate or report for a component, check which version and scope it covers before relying on it. Article 31(2), Article 13(7), Article 13(14).

Retention. Updating and retention are separate duties. The technical documentation and the EU declaration of conformity must remain at the disposal of market surveillance authorities for at least 10 years after the product is placed on the market, or for the support period, whichever is longer. This is also distinct from the duty to keep each security update available for at least 10 years after it is issued, or for the remainder of the support period, whichever is longer. Article 13(13), Article 13(9).

Authority requests. On a reasoned request, the manufacturer must provide a market surveillance authority with the information and documentation necessary to demonstrate conformity, in paper or electronic form and in a language that authority can easily understand. The FAQ confirms the documentation itself can be written in any language. Article 13(22), Commission FAQ, section 6.6.

Customers and the public. According to the FAQ, there is no obligation to make the technical documentation available to customers or the public. The exception concerns manufacturers of free and open-source software in an Annex III category (important products, class I or II) that rely on Article 32(5) to use one of the Article 32(1) procedures: they must make the technical documentation available to the public when the product is placed on the market. The user information and instructions (Annex II) and the EU declaration of conformity, in full or simplified form with the address of the full version, accompany the product under separate duties. Article 32(5), Article 13(18), Article 13(20).

The SBOM. The SBOM belongs in the technical documentation as part of the vulnerability handling evidence, and Annex I Part II(1) requires it in a commonly used, machine-readable format covering at least the top-level dependencies. Our CRA SBOM requirements guide covers building, checking and sharing it. Annex VII point 8 separately covers providing it, where applicable, further to a reasoned request from a market surveillance authority that needs it to check compliance. Authorities may also request SBOMs for a Union-wide dependency assessment decided by the Administrative Cooperation Group (ADCO). Outside the Article 32(5) case above, sharing the SBOM with users is the manufacturer’s choice; if it does, the user information must say where to find it. Article 63 requires everyone involved in applying the CRA to respect the confidentiality of information they obtain, protecting in particular confidential business information and trade secrets, including source code, subject to the exceptions it sets out. Annex I Part II, Article 13(25), Annex II, point 9, Article 63.

The SBOM is one part of the vulnerability handling evidence. Our CRA vulnerability handling guide explains the whole process, from receiving reports to issuing security updates and recording decisions.

A simplified format for micro and small enterprises

Microenterprises and small enterprises may provide all the Annex VII elements in a simplified format. The Commission specifies that form by implementing acts. An enterprise that opts for the simplified format must use that form, and notified bodies must accept it. The mechanism covers microenterprises and small enterprises only, and the content requirements stay the same. Before relying on it, check that the implementing act specifying the form has been adopted and which version applies. Article 33(5).

How Meroi Security can help

Meroi Security can assess an existing documentation set against Annex VII, organize product and process evidence for each release, and prepare it for the applicable conformity assessment procedure. Where a notified body is required, its assessment is a separate step. Explore our Cyber Resilience Act compliance services.