Technical Documentation Requirements Under the CRA

Annex VII requires manufacturers to compile and maintain a technical file for each product with digital elements. The technical file is not a single document — it is a collection of documents, test reports, design specifications, and records that together constitute the evidence base for CRA compliance.

The technical file must contain sufficient information to demonstrate that the product meets the essential requirements in Annex I, and to enable a competent authority or notified body to assess that compliance independently. The documentation must be coherent, consistent with the actual product, and kept up to date when product changes occur.

For software products with frequent update cycles, maintaining an up-to-date technical file requires ongoing documentation discipline — not just a one-time documentation exercise at product launch.

The technical file must begin with a clear product description that covers:

• General description: What the product is, what it does, and who it is intended for
• Intended purpose and environment: The deployment context (residential, commercial, industrial, medical) and the user population
• Product versions and configurations: All hardware variants, firmware versions, and software configurations covered by the technical file
• Network connectivity: How the product connects to networks and other devices, including protocols used and network interfaces exposed
• Data handled: What data the product processes, stores, or transmits, including any personal data or sensitive information
• Dependencies: Hardware dependencies, third-party software components, and cloud services relied upon

A thorough product description forms the foundation for the cybersecurity risk assessment that follows — you cannot adequately assess risks without first understanding what the product does and in what environment it operates.

The Annex VII technical file must include a documented cybersecurity risk assessment for the product. This assessment must:

• Identify threats: Enumerate the realistic threats to the product — who might attack it, how, and with what goals
• Assess vulnerabilities: Identify weaknesses in the product design or implementation that could be exploited
• Evaluate impact: Assess the potential harm to users, third parties, and systems if an attack succeeds
• Document controls: Describe the security measures implemented to address each identified risk
• Residual risk: Identify any risks that cannot be fully mitigated and the rationale for accepting them

The risk assessment must be proportionate to the product's threat profile. A consumer smart light bulb requires a less extensive risk assessment than an industrial control system, but both require a genuine risk-based analysis.

The risk assessment also provides the justification for compliance decisions: why certain security measures were implemented, why certain Annex I requirements are addressed in specific ways, and why certain approaches were deemed sufficient.

The Annex VII technical file must include documentation of all software components in the product — effectively a Software Bill of Materials (SBOM). The SBOM must identify:

• All first-party software components developed by the manufacturer
• All third-party commercial components and their versions
• All open-source components and their versions, including licence information
• The dependency relationships between components

The SBOM must be accurate and up to date. When a product update is released that changes component versions, the SBOM in the technical file must be updated accordingly.

SBOMs should be produced in a machine-readable format — SPDX or CycloneDX are the dominant standards — to enable automated vulnerability monitoring and facilitate sharing with downstream customers on request.

The SBOM serves a dual purpose in the technical file: it documents the product's composition for compliance purposes, and it enables ongoing vulnerability monitoring under Article 15 by providing the definitive list of components against which new CVE disclosures must be checked.

The technical file must include evidence that the product has been tested against the essential requirements. This evidence typically includes:

Security testing reports: Results of penetration testing, vulnerability scanning, static and dynamic code analysis, and any other security testing conducted. Reports should be prepared by qualified security professionals and should document the testing scope, methodology, findings, and remediation actions taken.

Harmonised standard compliance evidence: Where harmonised standards were applied, documentation demonstrating that the product meets the standard's requirements — for example, test results from standard-specified test cases.

CVD policy reference: A copy of or reference to the manufacturer's publicly available CVD policy under Article 13. The technical file should document how the CVD policy meets the Article 13 requirements.

Security update mechanism description: Technical documentation explaining how security updates are delivered to users, including the update authentication mechanism, rollback prevention, and the process for testing updates before distribution.

Support period documentation: Documentation of the stated support period and the processes in place to deliver security updates throughout that period.