CRA Technical Documentation: Annex VII Requirements
The Technical File is the documentary backbone of CRA compliance. Annex VII specifies exactly what it must contain. This guide walks through each required section with practical guidance on what to include and how to structure it.
What Is the Technical File?
The Technical File (sometimes called the Technical Documentation) is the comprehensive body of evidence that demonstrates a product's conformity with the CRA's essential requirements. It is an internal document — you do not submit it to any authority proactively. Instead, you must make it available to market surveillance authorities on request.
10 years
Retention period
From the date the product is placed on the market (or the end of the support period if longer)
Member State language
Language
Must be provided in the official language(s) of the member state whose MSA requests it
Any structured format
Format
No prescribed format — but must be organised, searchable, and complete
Annex VII: Required Content
1.General description of the product
- Product name, model number, type designation, and batch/serial number
- Intended purpose and intended use environment
- Version number of software, firmware, or hardware
- Description of the product's essential functions and digital components
- List of hardware and software components included in the product
- Product user manual and installation instructions
2.Design and development documentation
- Overall product architecture diagram showing components and data flows
- Description of the development lifecycle and security-by-design processes applied
- List of design choices made to address each Annex I security requirement
- Threat modelling documentation — identified threats and mitigations
- Cryptographic choices — algorithms, key lengths, implementation libraries
- Third-party components used and their provenance
3.Software Bill of Materials (SBOM)
- Machine-readable SBOM in CycloneDX or SPDX format
- SBOM covering at minimum all top-level dependencies (full transitive preferred)
- Version of each component and its licence
- SBOM must reflect the version of the product placed on the market
- Process for maintaining and updating the SBOM across product versions
4.Risk assessment and Annex I conformity
- Cybersecurity risk assessment methodology used
- List of identified risks and threat actors
- Annex I, Part I: For each of the 13 requirements — whether it applies, how it is met, or justification for non-applicability
- Annex I, Part II: Vulnerability handling procedures including CVD policy reference
- Residual risks and any accepted limitations
5.Security testing documentation
- Test plan covering all Annex I requirements
- Test results — penetration testing reports, fuzzing results, code review findings
- How identified vulnerabilities were remediated before market placement
- References to any harmonised standards applied and evidence of conformity
- Third-party test lab reports where applicable
6.Vulnerability management and post-market processes
- CVD policy URL and a copy of the policy as published
- Security update process — how updates are developed, tested, and delivered
- Support period commitment — how long security updates will be provided
- Incident response procedures (linked to Article 14 reporting process)
- Process for scanning new CVEs against the SBOM and assessing impact
7.EU Declaration of Conformity
- A copy of the signed EU Declaration of Conformity
- References to all applicable EU legislation (at minimum: CRA Regulation 2024/2847)
- References to harmonised standards or technical specifications applied
- Notified Body certificate number and details where applicable
Maintaining the Technical File Over Time
The Technical File is not a one-off document. It must be kept current throughout the product's lifecycle. Changes that require file updates include:
Trigger
New product version released
Required update
Update SBOM, component list, design documentation, and test results for the new version
Trigger
Significant security update issued
Required update
Document the vulnerability addressed, update the SBOM if components changed, add remediation evidence
Trigger
New CVE affecting a component
Required update
Document the assessment of impact (VEX statement), and either the remediation or accepted risk justification
Trigger
CVD policy updated
Required update
Replace the CVD policy reference and copy in the file
Trigger
Notified Body certificate renewed or updated
Required update
Replace the certificate copy and update the DoC reference
Common Technical File Mistakes
Treating the SBOM as a one-off exercise rather than a living document updated on each release
Failing to document the risk assessment methodology — not just the results
Incomplete Annex I coverage — skipping requirements deemed 'not applicable' without justification
Storing the file in a single person's email rather than a controlled document management system
Not retaining historical versions — market surveillance authorities may ask for documentation from a past product version
Forgetting to update the Declaration of Conformity when a Notified Body certificate is renewed
CRAReady's Technical File module provides a structured framework for compiling and maintaining your Annex VII documentation — with automated SBOM integration and version tracking.
Start building your technical file