CRA Documentation: What Goes Into the CRA Technical File
If your product carries the CE marking and you’re now mapping your obligations under the Cyber Resilience Act, the technical documentation requirement is one of the first places where the two frameworks diverge in a meaningful way.
The CRA follows a recognizable structure, but several of its required elements have no equivalent in any existing EU product directive.
What Annex VII Actually Requires
The CRA technical documentation is defined in Annex VII of the regulation, and manufacturers must draw it up before placing the product on the market. The file covers several items that we have organized in 8 areas.
The FIRST is a general description of the product: its intended purpose, the software versions that affect compliance with the essential cybersecurity requirements, photographs or illustrations showing external features and internal layout, and the user information and instructions required under Annex II.
The SECOND covers the design, development, and production of the product, including drawings and schemes, a description of the system architecture, and an explanation of how software components build on or feed into each other and integrate into the overall processing.
The THIRD is vulnerability handling processes: the specifications of the procedures the manufacturer has put in place, the coordinated vulnerability disclosure policy, evidence of a contact address for vulnerability reporting, and a description of the technical solutions chosen for the secure distribution of updates.
The FOURTH covers production and monitoring processes, including validation of those processes.
The FIFTH is the cybersecurity risk assessment, which must explain how the essential cybersecurity requirements apply to the product and how the manufacturer addresses them across the product lifecycle.
The SIXTH covers the support period: the information used to determine how long the manufacturer commits to handling vulnerabilities and issuing security updates.
The SEVENTH is the list of harmonized standards, common specifications, or European cybersecurity certification schemes applied, either in full or in part. Where those have not been applied, the file must describe the solutions adopted to meet the essential requirements instead.
The EIGHTH is the software bill of materials, a machine-readable inventory of software components and their top-level dependencies.
test reports verifying both conformity with the essential requirements and the effectiveness of the vulnerability handling processes.
The manufacturer must keep the full file available to market surveillance authorities for at least ten years.
Where It Diverges from the CE Marking Technical File
The structure of the CRA file will feel familiar to anyone who has built a CE marking technical file under the LVD, RED, or Machinery Directive. General description, design documentation, risk assessment, test reports, Declaration of Conformity: the skeleton is the same.
The differences are in the content of each section.
Under the classic directives, the risk assessment addresses physical safety: electrical hazards, mechanical risks, EMC interference. The CRA risk assessment addresses cybersecurity threats: attack surfaces, exploitation scenarios, data integrity risks, denial-of-service exposure. The methodology draws on a different body of standards, and the output documents different things.
The design documentation under the classic directives focuses on hardware architecture, schematics, and materials. The CRA file adds a software architecture description that must explain how components interact and depend on each other. For a product with embedded software, that can be a significant additional body of documentation.
The vulnerability handling section has no parallel in any CE marking directive.
A coordinated vulnerability disclosure policy, evidence of a public contact address for reporting vulnerabilities, and documentation of the update distribution mechanism are entirely new requirements. They reflect the CRA’s premise that cybersecurity obligations extend through the product’s entire operational life, not just up to the point of market placement.
The test reports requirement is also broader. The file must include reports covering both conformity with the essential cybersecurity requirements and the vulnerability handling processes themselves, which means testing the organizational procedures, not just the product.
The Cybersecurity Risk Assessment
The cybersecurity risk assessment must be carried out before the product reaches the market, and its outcomes must inform every phase of development: planning, design, production, delivery, and maintenance. The assessment must be documented and updated throughout the support period as new vulnerabilities emerge or the threat context changes.
The assessment must address two specific questions.
First, whether and how the security requirements in Annex I apply to the product. Those requirements cover areas including secure default configuration, protection against unauthorized access, data confidentiality and integrity, denial-of-service resilience, attack surface minimization, and security logging.
Second, how the manufacturer addresses the lifecycle security requirement and the vulnerability handling obligations across the product’s operational life.
This differs structurally from a safety risk assessment under EN ISO 12100. The safety risk assessment identifies hazards and estimates probability and severity of harm to people. The cybersecurity risk assessment identifies threats, evaluates the likelihood of exploitation, assesses the impact on confidentiality, integrity, and availability, and documents the mitigating controls. Products that fall under both the Machinery Regulation and the CRA need to manage both assessments in parallel.
Manufacturers who already conduct security assessments as part of a SOC2 or ISO 27001 program will have transferable process knowledge, but the CRA assessment must be product-specific and tied explicitly to the Annex I requirements.
Designed your product years ago?You do not need to prove it was secure back then. The Commission’s July 2026 CRA guidance (C(2026) 5252 final) confirms that a risk assessment done today, one that shows the product’s existing security measures actually hold up now, is enough on its own, based on Article 13(2) of the CRA. The only job is showing that today’s design is safe today.
The SBOM Requirement
The SBOM (software bill of materials) appears twice in Annex VII: inside the vulnerability handling section and as an element of the file. Its inclusion in both places reflects its dual role: it supports vulnerability identification and management, and it serves as a document that market surveillance authorities can request directly.
The SBOM must be in a commonly used and machine-readable format and must cover at least the top-level dependencies of the product. The Commission will adopt a delegated act specifying the exact format and required elements, but the formats most aligned with current CRA expectations are CycloneDX and SPDX, both widely supported by automated generation tools. The German BSI has published TR-03183-2 as a more detailed technical specification that goes beyond the CRA minimum and serves as a useful reference for manufacturers who want to exceed the baseline.
Market surveillance authorities may request the SBOM directly from the manufacturer. It does not need to be published proactively, but it must be ready to provide.
Keeping the File Current
The CRA technical documentation is a living document in a way that the classic CE marking technical file typically is not (though it should be, given that product modifications and new harmonized standards can affect compliance at any point).
Under the classic directives, the technical file is assembled, reviewed during conformity assessment, and then largely static. Changes to the product that affect compliance require updates, but the main trigger is product modification.
Under the CRA, the cybersecurity risk assessment must be updated throughout the support period as new vulnerabilities emerge or the threat context changes.
Any newly discovered vulnerability that affects the product must be documented.
If the manufacturer issues a security update, the test reports covering the vulnerability handling processes may need to reflect the updated state of those processes.
This means the technical file requires active maintenance for as long as the product remains within its support period. The manufacturer must keep the file and the Declaration of Conformity available to market surveillance authorities for at least ten years from the date the product was last placed on the market.
For manufacturers accustomed to building a technical file once and archiving it, this ongoing maintenance obligation is one of the more significant operational adjustments the Cyber Resilience Act introduces.
Do I Need a Separate Technical File for Every Product Version?
A single risk assessment, technical documentation package, and EU Declaration of Conformity can cover multiple versions of the same product, as long as those versions share the same design and the same security risks, and each version stays clearly identified within the documentation itself.
The dividing line is whether the difference between versions changes something about the product’s actual security exposure. A different case color, a bigger memory chip, or a cosmetic feature does not require a separate file. A different communication protocol, a different authentication mechanism, or a different set of exposed network interfaces does, because each of those changes the threats the product actually faces.
The CRA applies from December 11, 2027, with the vulnerability and incident reporting obligations applying from September 11, 2026. The technical documentation must be complete before the product reaches the EU market, which means the work of building it needs to start well before the December 2027 deadline.
For manufacturers already managing a CE marking technical file, the starting point is an audit of what the existing file contains and what the CRA adds. The gap analysistypically focuses on three areas: the software architecture documentation, the vulnerability handling section, and the cybersecurity risk assessment. The Declaration of Conformity and the list of standards are familiar territory, though the applicable standards differ.
If you want to assess where your current documentation stands relative to CRA requirements, get in touch.
