VII

Annex VII

CONTENT OF THE TECHNICAL DOCUMENTATION

Regulation (EU) 2024/2847 — published 10 December 2024 · Last reviewed by Kunnus: March 2026

Quick Answer for Manufacturers

Annex VII defines the content of the technical documentation: general product description, design aspects, risk assessment, test reports, vulnerability handling process, SBOM, EU declaration of conformity. It is the evidence of CRA conformity.

This quick answer + FAQ supplements the original legal text with practice-oriented interpretation. Only the original text is legally binding.

The technical documentation referred to in Article 31 shall contain at least the following information, as applicable to the relevant product with digital elements:

a general description of the product with digital elements, including:

its intended purpose;

versions of software affecting compliance with essential cybersecurity requirements;

where the product with digital elements is a hardware product, photographs or illustrations showing external features, marking and internal layout;

user information and instructions as set out in Annex II;

a description of the design, development and production of the product with digital elements and vulnerability handling processes, including:

necessary information on the design and development of the product with digital elements, including, where applicable, drawings and schemes and a description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing;

necessary information and specifications of the vulnerability handling processes put in place by the manufacturer, including the software bill of materials, the coordinated vulnerability disclosure policy, evidence of the provision of a contact address for the reporting of the vulnerabilities and a description of the technical solutions chosen for the secure distribution of updates;

necessary information and specifications of the production and monitoring processes of the product with digital elements and the validation of those processes;

an assessment of the cybersecurity risks against which the product with digital elements is designed, developed, produced, delivered and maintained pursuant to Article 13, including how the essential cybersecurity requirements set out in Part I of Annex I are applicable;

relevant information that was taken into account to determine the support period pursuant to Article 13(8) of the product with digital elements;

a list of the harmonised standards applied in full or in part the references of which have been published in the Official Journal of the European Union, common specifications as set out in Article 27 of this Regulation or European cybersecurity certification schemes adopted pursuant to Regulation (EU) 2019/881 pursuant to Article 27(8) of this Regulation, and, where those harmonised standards, common specifications or European cybersecurity certification schemes have not been applied, descriptions of the solutions adopted to meet the essential cybersecurity requirements set out in Parts I and II of Annex I, including a list of other relevant technical specifications applied. In the event of partly applied harmonised standards, common specifications or European cybersecurity certification schemes, the technical documentation shall specify the parts which have been applied;

reports of the tests carried out to verify the conformity of the product with digital elements and of the vulnerability handling processes with the applicable essential cybersecurity requirements as set out in Parts I and II of Annex I;

a copy of the EU declaration of conformity;

where applicable, the software bill of materials, further to a reasoned request from a market surveillance authority provided that it is necessary in order for that authority to be able to check compliance with the essential cybersecurity requirements set out in Annex I.

European Commission Interpretation

Guidance of 27 July 2026

The EU Commission guidance of 27 July 2026 provides official interpretation notes on this provision. Each section: summary, key takeaways, and what it means for you in practice.

Section 2.6Complex systems and interoperability constraints

Complex systems with long development cycles, legacy components and interoperability constraints are not excluded from the CRA — but those constraints feed into the risk-based approach. Where specific essential requirements cannot (fully) be met (see recital 55), manufacturers must document the constraints, assess the risks and implement compensatory measures.

Key takeaways

A less secure legacy protocol may be implemented where necessary for interoperability, provided the risks are mitigated by other means; where the product supports both protocols, the secure one must be the default (Example 10).
Constraints, risks and mitigations must be transparently described in the technical documentation (Art. 31, Annex VII) and user information (Annex II).
Constraints must be periodically reassessed during the support period; where they can be lifted, the product should be updated accordingly.
Components purchased before the CRA applies may be integrated where the risk assessment identifies no specific risks and the product as a whole meets the requirements (Example 11).

In practice

Create a constraint dossier for every requirement you cannot (fully) meet: why it is not implementable (e.g. interoperability constraints), what risk arises, which compensatory measure applies — and schedule the reassessment. This is exactly the documentation market surveillance will want to see.

Section in the guidance overview

Section 2.7Products designed before the CRA applies — no forced redesign

Products designed before 11 December 2027 but placed on the market after that date do not necessarily require redesign. The manufacturer carries out a current risk assessment; where it shows that existing measures address the risks, compliance can rest on those measures. Historical design and test documentation need not be recreated.

Key takeaways

The conformity assessment procedure, EU declaration of conformity and CE marking remain mandatory in any case.
No obligation to provide test results covering the original design phase; tests can be grouped across product families (Section 7.4 of the guidance).
Vulnerability handling (Annex I Part II), keeping the risk assessment updated (Art. 13(3)) and user information (Art. 13(18)) apply without restriction.

Example from the guidance

A microcontroller designed before the CRA applies may continue to be placed on the market without redesign where a current risk assessment shows that existing security measures address the identified risks (Example 12).

In practice

Do not plan a redesign for legacy designs unless the risk assessment demands one: a current risk assessment plus evidence that existing measures cover the risks is sufficient. You need not recreate historical design and test documentation — but the declaration of conformity and CE marking remain mandatory.

Section in the guidance overview

Section 7.4Product families — one risk assessment, one documentation set, one declaration

Variants sharing the same architecture, security-relevant design, intended purpose and risk exposure may share a single risk assessment, technical documentation set, conformity assessment procedure and EU declaration of conformity. The sole decisive factor is whether the differences between variants are relevant to cybersecurity.

Key takeaways

Irrelevant: colour, form factor, memory size and other non-security-relevant characteristics.
Relevant: differing communication interfaces, software stacks, update mechanisms or remote connectivity — such differences must be reflected in the risk assessment and documentation.
The shared declaration of conformity must clearly identify the covered variants; new variants introducing new risks require an update.

In practice

Group your product variants by security-relevant differences: everything sharing architecture, interfaces and risk profile can share one risk assessment, documentation set and EU declaration of conformity — colour, form factor and memory size do not separate variants. This drastically reduces per-variant effort; the declaration must simply identify the covered variants unambiguously.

Section in the guidance overview

Section 8.2RDPS in documentation, risk assessment and conformity assessment

RDPS must be covered in the product's risk assessment, technical documentation and conformity assessment — limited to the software modules responsible for the product's functionality and the interfaces those modules use. Downstream back-end systems the product does not directly interact with are not RDPS, but remain external dependencies whose risks must be mitigated at product level.

Key takeaways

An RDPS serving several products must be declared in each product's technical documentation — the RDPS documentation may be reused across conformity assessments.
Reusable assurance artefacts for third-party services: NIS 2 evidence (IR (EU) 2024/2690), DORA evidence, certificates under EU cybersecurity certification schemes, ISO/IEC 27001/27017.
Major changes to third-party services are not a substantial modification of the product — but manufacturers should secure information and security guarantees contractually (SLAs) and revise the risk assessment accordingly.

In practice

Create a central RDPS dossier — affected software modules, interfaces, providers used with evidence (ISO 27001/27017, NIS 2 or DORA evidence, EUCC certificates) — and reference it from every product's documentation. Anchor in provider SLAs that you are informed about major changes: they do not trigger a new conformity assessment, but they do require updating your risk assessment.

Section in the guidance overview

Browse all guidance chapters

EU Commission Guidance (C(2026) 5252 final) — The guidance reflects the European Commission's interpretation and is not legally binding. An authoritative interpretation of the EU CRA may only be given by the Court of Justice of the European Union.

Common Manufacturer Questions

What must the technical documentation contain?

Product description with purpose and intended use, design documentation, risk assessment, test reports, vulnerability handling process including SBOM, list of applied harmonized standards, EU declaration of conformity, reports from any involved notified bodies.

Must the SBOM be in the technical documentation?

Yes. Annex VII references Annex I Part II, which defines the SBOM obligation. The SBOM is therefore part of the technical documentation and must be presented during market surveillance audits.

In what form must the documentation be retained?

Structured, complete, legible, archived. The format is not prescribed — paper or electronic are both possible, as long as authenticity and integrity are preserved. Versioning recommended.

Who has access to the technical documentation?

Primarily market surveillance authorities and, where applicable, the notified body. It is not a public publication — but B2B customers can request excerpts in the course of procurement.

This text is reproduced from Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024. It is provided for informational purposes only and does not constitute legal advice. Only the text published in the Official Journal of the European Union is legally binding. Original text on EUR-Lex