Technical Documentation
CRA technical documentation is the evidence file for the product and the manufacturer's cybersecurity processes. It must show how the product meets Annex I and how the manufacturer handles vulnerabilities.
Documentation duty
The technical documentation shall contain all relevant data or details of the means used by the manufacturer to ensure that the product with digital elements and the processes put in place by the manufacturer comply with the essential cybersecurity requirements set out in Annex I. It shall at least contain the elements set out in Annex VII.
Regulation (EU) 2024/2847, Article 31(1)
Article 31 is broad. The file must explain the means used to make the product and the manufacturer's processes comply with Annex I. It is not only a design file, a test report, or a user manual.
Evidence point
The product cybersecurity properties in Annex I, Part I, and the vulnerability-handling process in Annex I, Part II.
Timing and updates
The technical documentation shall be drawn up before the product with digital elements is placed on the market and shall be continuously updated, where appropriate, at least during the support period.
Regulation (EU) 2024/2847, Article 31(2)
The technical documentation must exist before placing on the market. It must then be kept current when changes matter during the support period.
- A changed product design, architecture, software version, or update method can require an update.
- A changed cybersecurity risk assessment can require an update.
- New vulnerability information can require an update.
- A redesigned or reassessed product should have documentation that identifies the changed versions.
Annex VII contents
Annex VII is the minimum content list. It is best read as evidence categories, not as a table template. The exact detail depends on the relevant product.
The file identifies the product, its intended purpose, the software versions that affect compliance, hardware images when relevant, and the user information in Annex II.
Annex VII asks for design, development, production, and vulnerability-handling information, including architecture, component information, the SBOM, coordinated vulnerability disclosure, a reporting contact, and secure update delivery.
The cybersecurity risk assessment is part of the file. Annex VII also asks for the information used to determine the support period.
The file records standards, common specifications, certification schemes, other technical solutions, test reports, and the EU declaration of conformity.
Annex VII includes the SBOM when a market surveillance authority makes a reasoned request and the SBOM is needed to check compliance with Annex I.
Evidence links
Technical documentation is easier to read when the main evidence streams are kept distinct. Annex VII pulls them into one file, but each stream answers a different question.
Risk assessment
Shows how Article 13 and Annex I apply to the product. Read Cybersecurity Risk Assessment.
Gap analysis
Compares current product evidence with applicable CRA requirements. Read Gap Analysis.
SBOM and components
Supports vulnerability handling and component visibility. Read SBOM and Component Records.
Vulnerability records
Shows vulnerability intake, remediation, disclosure, updates, and testing. Read Vulnerability Handling Records.
Risk assessment
Article 13(4) puts the cybersecurity risk assessment into the technical documentation. The risk assessment explains how Annex I applies to the product, including why a product-property requirement is not relevant if that is the manufacturer's conclusion.
The Commission FAQ says the file must be available when the product is placed on the market, whether it is made inside or outside the EU. It also says later redesigns and reassessments should be reflected in the technical documentation.
Conformity and authority use
Technical documentation is mainly for conformity assessment and market surveillance. The Commission FAQ states that it does not normally have to be made available to customers or the public.
The main public exception described in the FAQ concerns certain important free and open-source software products using the Article 32(5) self-assessment route.
Keep it clear enough to assess
A market surveillance authority may request the information needed to demonstrate conformity. Missing or unclear documentation can become a formal compliance problem.