CRA Annex VII: the technical documentation, explained section by section
A plain-language walk through Annex VII of the EU Cyber Resilience Act: the eight elements your technical documentation must contain, what artifact satisfies each, and how the file connects to CE marking.
Not sure if you’re in scope?
Run the free 3-minute scope check for your product and get your risk class, deadlines and obligations.
Check if the CRA applies to youIn short
Annex VII of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) lists what your technical documentation must contain: a general description of the product, a description of its design, development, production and vulnerability-handling processes, the cybersecurity risk assessment, the essential requirements of Annex I and how you met them, the harmonised standards applied, test reports, a copy of the EU Declaration of Conformity, and the SBOM where relevant. For a Default-class product you assemble this file yourself, sign the Declaration, and affix the CE marking — no notified body. It must be ready by 11 December 2027 and kept current for the product’s support period.
The technical documentation is the file that proves your product complies with the CRA. For a Default-class product — roughly 90% of products with digital elements — nobody external checks it before you go to market: you compile it, sign the Declaration of Conformity, and affix the CE marking on your own authority. That makes the file the single most important thing you produce, because it is the evidence a market-surveillance authority will ask for if they ever come knocking.
Annex VII of the regulation is the checklist for what goes inside. It reads as a dense legal list, so this guide walks through each of its eight elements in plain language, and tells you what artifact actually satisfies it.
Not sure the CRA applies to your product, or which class it lands in? Run the free 3-minute scope check first — the higher classes have heavier evidence rules.
What does Annex VII actually require?
Annex VII sets out the minimum contents of the technical documentation. Here is each element, and the artifact a small manufacturer produces to satisfy it.
| Annex VII element | What you actually produce |
|---|---|
| 1. General description of the product | A short product dossier: intended purpose, the versions covered, type/batch/serial identification, and a description of the hardware and software |
| 2. Description of design, development, production and vulnerability-handling processes | Your development and release process notes plus a written vulnerability-handling policy |
| 3. Assessment of cybersecurity risks | The documented security risk assessment (threats, mitigations, accepted risks) |
| 4. Essential requirements applied and how | A mapping table: each relevant Annex I requirement → how your product meets it |
| 5. Harmonised standards applied | A list of the standards you relied on (and which parts), or a note where none were applied |
| 6. Reports of tests performed | Test and verification evidence — scan results, pen-test summaries, functional security tests |
| 7. Copy of the EU Declaration of Conformity | The signed Declaration, per Annex V |
| 8. SBOM, where relevant | A machine-readable Software Bill of Materials (CycloneDX or SPDX) |
The sections below explain what each one means in practice.
1. A general description of the product
This is the “what is this thing” section. State the product’s intended purpose, list the software versions and hardware revisions the file covers, and give the identifiers a customer or an inspector would use to pin down exactly which unit they are holding — type, batch or serial numbering. Include a description of the hardware components and the software elements. Practically, this is one to three pages of prose plus a photo or diagram; the discipline is keeping the version list current as you ship releases.
2. Design, development, production and vulnerability-handling processes
Here you describe how the product is made and maintained, not just what it is. Two things go together: an outline of your design, development and production process, and — the part regulators care most about — your vulnerability-handling process. That means how you receive reports, triage them, fix them, and ship security updates separately and free of charge for the support period (at least five years). A one-to-two-page written policy plus a published coordinated disclosure page satisfies this. See our compliance checklist for how the handling process ties into the 24-hour reporting duty.
3. The cybersecurity risk assessment
The CRA is a security-by-design regulation, and the risk assessment is where you show you designed for the threats your product actually faces. List the product’s interfaces and data flows, identify the threats against each, and record your mitigation or your reasoned decision to accept the risk. This assessment is what justifies the design choices you claim in element 4 — the two are read together. For an existing product, run it as a structured review; the output is a living document, not a one-time form.
4. The essential requirements of Annex I, and how you met them
Annex I is the list of essential cybersecurity requirements — secure default configuration, no known exploitable vulnerabilities at release, protection of data in transit and at rest, access control, attack-surface minimisation, and so on. This element of the file is a mapping: for each requirement that applies to your product, a line explaining how you satisfy it (or why it does not apply). A simple two-column table is the clearest format. This is the heart of the technical file and the section an inspector reads most closely.
5. The list of harmonised standards applied
Where you relied on a harmonised standard to meet an essential requirement, you list it — the standard reference and which parts you applied. Harmonised standards give a “presumption of conformity”: apply them correctly and you are presumed to meet the matching requirement. For Default-class products the CRA harmonised standards are still being published, so it is entirely acceptable to note where no harmonised standard was applied and point to your own design measures instead.
6. Reports of the tests performed
Evidence that you actually verified the product, not just claimed compliance. For most small manufacturers this is a folder of artifacts: vulnerability-scan output against your SBOM, a penetration-test summary if you commissioned one, results of functional security tests (authentication works, encryption is on, default passwords are not shipped). You do not need a notified body’s lab report for a Default-class product — your own documented testing is the evidence.
7. A copy of the EU Declaration of Conformity
The Declaration of Conformity (its required contents are set out in Annex V) is the formal statement, signed by you, that the product meets the CRA. A copy lives inside the technical file. Signing it is the act that lets you affix the CE marking — more on that below.
8. The SBOM, where relevant
The Software Bill of Materials is the machine-readable list of the components inside your product, covering at least the top-level dependencies, in CycloneDX or SPDX format. It belongs in the technical documentation and it is also the operational backbone of everything else: it feeds your vulnerability monitoring and your 24-hour reporting readiness. If you are new to it, start with our guide on what an SBOM is.
Assembling eight Annex VII sections by hand — and re-editing the version list, SBOM and test reports on every release so the file never goes stale — is exactly the kind of manual upkeep small teams let slip.
Nordchecks generates the technical file and the EU Declaration of Conformity from your product data and SBOM, and regenerates them each release so the documentation stays current on its own.
Try Nordchecks freeHow the technical file connects to CE marking
For a Default-class product the path is short and entirely internal. You assemble the Annex VII documentation, satisfy yourself that the essential requirements of Annex I are met, sign the EU Declaration of Conformity, and affix the CE marking. There is no notified body, no external certificate, no waiting list — this is what self-assessment means, and it is why getting your product class right matters so much. Class I products may need harmonised standards or a notified body; Class II always needs one; Critical products need European certification. Everyone else does the work described above and signs.
After 11 December 2027, a product with digital elements cannot legally be placed on the EU market without CE marking under the CRA, and the technical file is what stands behind that mark. You must keep it for ten years after the product is placed on the market (or the support period, if longer), and keep it current: every release that changes the software changes the version list, the SBOM and possibly the test evidence.
The part software should do for you
Nothing in Annex VII is conceptually hard for a small team — it is a description, a process note, a risk assessment, a mapping table, a standards list, some test output, a signed declaration and an SBOM. The burden is not writing it once; it is keeping eight linked documents in sync across every release, for years, without letting any of them drift out of date. That is mechanical work, and mechanical work is what software removes. Purpose-built CRA compliance software can generate the technical file and the Declaration from your product data, pull the SBOM and vulnerability evidence in automatically, and reissue the whole package each release — so keeping the file current is a review, not a rebuild. Our guide on how to automate CRA compliance covers the wider workflow.
Before you build the file, confirm what applies to you: check your product’s scope and class free — three minutes, no signup.