What the EU Cyber Resilience Act requires in your technical documentation

The Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU law that sets baseline cybersecurity requirements for products with digital elements sold into the EU market. This page covers two specific parts of it in detail — Annex VII (the content of the technical documentation, referenced by Article 31) and Annex V (the EU declaration of conformity, referenced by Article 28) — not the whole regulation. Every requirement below is quoted or closely paraphrased from the consolidated regulation text and cited to its exact point.

Annex VII: the technical documentation (Article 31)

Article 31 requires manufacturers to draw up technical documentation before a product is placed on the market and to keep it updated throughout the support period. Annex VII sets the minimum content: eight numbered points, the first two of which are broken down further into lettered sub-points.

1. General description of the product

Four sub-points, each required "as applicable":

• (a) Intended purpose — what the product is for. Annex VII, point 1(a)
• (b) Software versions affecting compliance — which software versions affect compliance with the essential cybersecurity requirements. Annex VII, point 1(b)
• (c) Hardware photographs or illustrations — for hardware products, images showing external features, marking and internal layout. Annex VII, point 1(c)
• (d) User information and instructions — as set out in Annex II. Annex VII, point 1(d)

2. Design, development, production and vulnerability handling

• (a) Design and development information — including, where applicable, drawings, 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. Annex VII, point 2(a)
• (b) Vulnerability handling process specifications — including the software bill of materials, the coordinated vulnerability disclosure policy, evidence of a contact address for reporting vulnerabilities, and a description of the technical solution used for secure distribution of updates. Annex VII, point 2(b)
• (c) Production and monitoring process information — including validation of those processes. Annex VII, point 2(c)

3. Cybersecurity risk assessment

An assessment of the cybersecurity risks against which the product is designed, developed, produced, delivered and maintained under Article 13, including how the essential cybersecurity requirements in Part I of Annex I apply. Annex VII, point 3

4. Support-period rationale

The relevant information taken into account to determine the product's support period under Article 13(8). Annex VII, point 4

5. Standards applied

A list of the harmonised standards applied (in full or in part) whose references are published in the Official Journal, or common specifications (Article 27) or European cybersecurity certification schemes applied instead. Where such standards, specifications or schemes were not applied, a description of the alternative solutions used to meet the essential cybersecurity requirements, including any other relevant technical specifications. If a standard was only partly applied, the documentation must specify which parts. Annex VII, point 5

6. Test reports

Reports of the tests carried out to verify conformity of the product and of its vulnerability handling processes with the applicable essential cybersecurity requirements. Annex VII, point 6

7. Copy of the EU declaration of conformity

A copy of the Annex V declaration itself, included in the technical documentation package. Annex VII, point 7

8. Software bill of materials, on request

Where applicable, the SBOM, to be provided further to a reasoned request from a market surveillance authority where necessary for that authority to check compliance with the essential cybersecurity requirements. Annex VII, point 8

Annex V: the EU declaration of conformity (Article 28)

Article 28 requires manufacturers to draw up an EU declaration of conformity stating that the applicable essential cybersecurity requirements in Annex I have been demonstrated, using the model structure set out in Annex V. Unlike Annex VII, Annex V is not organised into lettered sub-points under each item — it is a flat list of eight points, all at the same level.

• 1. Product identification — name, type and any additional information enabling unique identification of the product. Annex V, point 1
• 2. Manufacturer identity — name and address of the manufacturer or its authorised representative. Annex V, point 2
• 3. Sole-responsibility statement — a statement that the declaration is issued under the sole responsibility of the provider. This is fixed regulatory text that doesn't vary by product. Annex V, point 3
• 4. Object of the declaration — identification of the product allowing traceability, which may include a photograph where appropriate. Annex V, point 4
• 5. Conformity statement — a statement that the declared object is in conformity with the relevant Union harmonisation legislation. Annex V, point 5
• 6. Standards referenced — references to any relevant harmonised standards used, or any other common specification or cybersecurity certification against which conformity is declared. Annex V, point 6
• 7. Notified body details — where applicable, the name and number of the notified body, a description of the conformity assessment procedure performed, and identification of the certificate issued. Annex V, point 7
• 8. Signature block — additional information, plus "signed for and on behalf of," place and date of issue, and name, function and signature. Annex V, point 8

See a real Annex V DoC draft generated by ceproof.

What a repository scan can and can't derive

ceproof works through the 21 items across Annex VII and Annex V (13 from Annex VII, 8 from Annex V) and sorts each one into one of four categories, based on whether it can be resolved from evidence a scan can actually find:

• Derivable / partial — resolved by checking real signals in the repository: things like whether a security policy file exists, whether a release is tagged in version control (as opposed to a bare commit hash — ceproof deliberately does not treat a commit hash as a real version), or whether the dependency tree resolves to known licenses. An item is marked DERIVED only if every relevant signal resolves; if some signals resolve and others don't, it's marked PARTIAL. Nothing is ever marked DERIVED off zero evidence.
• Human-required — needs an answer from you, collected via ceproof init into a ceproof.config.json file. Manufacturer identity, product description, risk-assessment narrative, and the reasoning behind a chosen support period fall here — a scan genuinely cannot infer these from source code.
• Boilerplate — fixed regulatory text that never varies by product. Only one item across both annexes qualifies: the Annex V "issued under the sole responsibility of the provider" statement. It's always resolved automatically and needs no input.

Concretely, a scan of your repository can surface: whether a SECURITY.md or security.txt file is present, whether a vulnerability disclosure policy exists, your git release identity (a real tag versus just a commit hash), your declared project license, the full npm or Python dependency tree with resolved licenses, and SBOM readiness — how many packages you depend on and whether all of their licenses are known.

It cannot derive: the product's intended purpose in prose, hardware photographs, a system architecture narrative, the actual cybersecurity risk assessment, the reasoning behind a chosen support period, which harmonised standards were applied, test reports, or the declaration-of-conformity signatory block. Those require a human who understands the product.

On a typical repository with a tagged release and a resolved dependency lockfile, this means 2 of the 13 Annex VII items resolve fully from scan evidence alone (DERIVED), and a 3rd gets partial evidence and is flagged PARTIAL for review. The rest — the majority of both annexes — are correctly flagged as needing your input, not silently guessed at.

When these obligations apply

Article 71 sets the Regulation's entry into force and application dates. The general application date is 11 December 2027 — this is when the Annex VII technical documentation obligation (Article 31) and the Annex V declaration of conformity obligation (Article 28) take effect for products placed on the market. Two provisions apply earlier:

Provision	Applies from	What it covers
Article 14	11 September 2026	Manufacturer reporting of actively exploited vulnerabilities and severe incidents to ENISA and the coordinating CSIRT
Chapter IV (Articles 35–51)	11 June 2026	Notification of conformity assessment bodies (notified bodies)
General application date	11 December 2027	All remaining obligations, including Annex VII technical documentation (Article 31) and Annex V declaration of conformity (Article 28)

Article 71(2): "This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026."