CRA Technical Documentation Template (Annex VII)

Use this template to assemble the technical documentation (the technical file) required by Article 31 and Annex VII of the EU Cyber Resilience Act (Regulation (EU) 2024/2847).

Key facts:

• Drawn up before market placement. The technical file must exist before the product is placed on the EU market and before the EU Declaration of Conformity is signed.
• Continuously updated. The file must describe the product as actually shipped, including updates released during the support period.
• Available on request. Market surveillance authorities can request the file, and notified bodies review it during third-party conformity assessment.
• Retention. Keep the file for at least 10 years after the last unit of the product is placed on the market, or for the duration of the support period, whichever is longer.
• Deadlines. Full conformity obligations, including the technical file, apply from 11 December 2027. Article 14 reporting obligations start earlier, on 11 September 2026.

Product name: [PRODUCT NAME] Model / type / SKU: [MODEL NUMBER] Software / firmware versions covered: [VERSION RANGE] Intended purpose: [What the product does and who it is intended for] Deployment environment: [Residential / Commercial / Industrial / Medical] CRA classification: [Default / Important Class I / Important Class II / Critical]

General description: [2-4 paragraphs describing the product, its main functions, and its security-relevant characteristics]

Network connectivity and interfaces: [Protocols used, exposed ports, wireless interfaces, associated cloud services and APIs] Data processed: [Categories of data stored, processed, or transmitted, including any personal data] Dependencies: [Hardware dependencies, third-party software components, cloud services relied upon] Hardware documentation: [For hardware products, photographs or illustrations showing external features, markings, and internal layout] User information: [Reference to the user information and instructions supplied with the product]

Document the design and development of the product in enough detail for an authority to assess conformity with the essential requirements in Annex I Part I.

Include:

• System architecture. [Architecture diagrams showing how software components relate to and build on each other, trust boundaries, and external interfaces]
• Security design decisions. [Authentication model, cryptography used, secure boot, isolation and hardening measures, secure-by-default configuration]
• Development process. [Secure development lifecycle description, code review practices, build and release controls]
• Production and monitoring. [Description of production processes and how conformity of series production with the documented design is monitored]
• Referenced documents: [Document ID, title, version, and storage location for each engineering document incorporated by reference]

Document the vulnerability handling processes required by Annex I Part II.

• CVD policy. [Copy of or reference to your published coordinated vulnerability disclosure policy under Article 13, including its public URL]
• Vulnerability contact. [The contact address for reporting vulnerabilities, e.g. your disclosure portal URL and security email]
• Software bill of materials. [SBOM in SPDX or CycloneDX format covering first-party, commercial, and open-source components, with versions, licences, and dependency relationships]
• Vulnerability monitoring. [How you monitor your components for newly disclosed vulnerabilities during the support period]
• Secure update distribution. [Technical description of how security updates are built, signed, tested, and distributed, including protection against tampering and rollback]
• Advisory publication. [Where and how you publish security advisories once fixes are available, e.g. a CSAF 2.0 feed]

Include the cybersecurity risk assessment drawn up under Article 13(2) and kept up to date under Article 13(3).

• Threat model. [Realistic threat actors, attack surfaces, and attack scenarios for the intended purpose and reasonably foreseeable use]
• Risk analysis. [Each identified risk with its likelihood and its potential impact on users, third parties, and connected systems]
• Security measures. [The measures implemented to address each identified risk, mapped to the Annex I Part I requirements they support]
• Applicability rationale. [Where an Annex I Part I requirement is assessed as not applicable to this product, the justification]
• Residual risks. [Risks that cannot be fully mitigated and the rationale for accepting them]
• Review history: [Dates and triggers of risk assessment reviews, e.g. new versions, new threat intelligence, reported vulnerabilities]

Declared support period: [START DATE] to [END DATE] ([X] years) Where the support period is communicated to users: [Product page URL, packaging, user information]

Factors considered in determining the support period:

• [Expected time the product will be in use]
• [Support periods of comparable products on the market]
• [Availability and support horizons of critical third-party components]
• [Deployment environment and user expectations, e.g. industrial equipment lifetimes]

Justification: [2-3 paragraphs explaining why the chosen support period is appropriate for this product]

List the standards and technical specifications applied to meet the essential requirements in Annex I.

| Standard / specification | Version | Applied in full or in part | Requirements covered | |---|---|---|---| | [e.g. IEC 62443-4-1] | [Edition] | [Full / Partial] | [Annex I Part I references] | | [e.g. ETSI EN 303 645] | [Version] | [Full / Partial] | [Annex I Part I references] | | [Internal specification] | [Version] | [Full / Partial] | [Annex I Part II references] |

For essential requirements without an applied standard: [Describe the solution adopted to meet each requirement, with references to the design documentation in Part 2 and the test reports in Part 6]

Include reports of the tests carried out to verify conformity with Annex I Parts I and II.

• Security testing. [Penetration test reports, vulnerability scans, fuzzing results, static and dynamic analysis reports, each with scope, methodology, findings, and remediation status]
• Requirement verification. [Test evidence mapped to each applicable Annex I Part I requirement]
• Process verification. [Evidence that the vulnerability handling processes operate in practice, e.g. records of a handled disclosure, update deployment logs]
• Regression evidence. [Tests demonstrating that security properties are preserved across updates]

For each report, record: [Title, author or testing firm, date, product version tested, storage location]

Include a copy of the signed EU Declaration of Conformity for the product.

Checklist for the enclosed DoC:

• [ ] Product identification matching Part 1 of this file
• [ ] Manufacturer name and address (and authorised representative, where applicable)
• [ ] Sole responsibility statement
• [ ] Reference to Regulation (EU) 2024/2847 and the requirements the declaration covers
• [ ] Standards and specifications listed, matching Part 5 of this file
• [ ] Conformity assessment procedure used (e.g. Module A internal control)
• [ ] Notified body name, number, and certificate reference, where applicable
• [ ] Place and date of issue, signatory name, function, and signature

[Attach the current signed DoC here. Annex V specifies the full field structure.]