What the CRA technical file has to contain
Short answer. Eight points, set out in Annex VII. Most of it is a written record of decisions you have already made about your product — how it is built, what could go wrong, and what you did about it.
For products in the default category you write it, you sign it, and nobody audits it — but you must be able to produce it for a market surveillance authority for at least ten years.
The eight points
| Point | What it has to contain |
|---|---|
| 1 | A general description of the product: its intended purpose, the software versions affecting compliance, photographs or illustrations where applicable, and the user information and instructions required by Annex II. |
| 2 | Design, development and production: the system architecture, your vulnerability-handling processes, the software bill of materials, your coordinated vulnerability disclosure policy, the contact address for reporting, and how you distribute updates. |
| 3 | A cybersecurity risk assessment showing how each of the essential requirements is addressed for your product. |
| 4 | The justification for your support period — the information you considered in determining it. |
| 5 | The harmonised standards, common specifications or certification schemes you applied — or, where you applied none, a description of the alternative solutions you adopted instead. |
| 6 | Test reports evidencing conformity with the essential requirements — both the product requirements and the vulnerability-handling requirements. |
| 7 | A copy of the EU declaration of conformity. |
| 8 | The software bill of materials, where requested by market surveillance authorities. |
Read as a list it looks heavy. In practice points 1, 2 and 7 are transcription — you know these things, they just have to be written down in one place. Point 6 is evidence you may already generate. The work is concentrated in points 3, 4 and 5.
Point three: the risk assessment, and why it comes first
This is the substantive one. You have to show how each essential requirement is addressed for your specific product — not assert that it is.
The essential requirements cover things like: shipping with a secure default configuration; protecting against unauthorised access; protecting the confidentiality and integrity of data; minimising attack surfaces; reducing the impact of incidents; recording and monitoring security-relevant activity; and allowing security updates to be distributed.
Several of them are qualified — they apply where applicable, or as appropriate, to the risks of your particular product. That matters, because it means the honest answer for some requirements is “not applicable to this product, and here is why”. A file that claims to satisfy every requirement in full, including ones that make no sense for your device, is less credible than one that reasons about which apply.
Point five: the one that goes stale
Point five asks which harmonised standards you applied. Here is the awkward part: most of them do not exist yet.
Tranches of harmonised standards are expected on 31 October 2026, 31 December 2026 and 30 October 2027 — and those dates have already moved once. Only a fraction will carry presumption of conformity, and several of the central technical references, including the IEC 62443 series, are not expected to be listed in the Official Journal at all.
Two consequences:
- Right now, the correct answer for many products is the alternative-solutions route. The annex explicitly allows for it: where you did not apply harmonised standards, you describe the solutions you adopted to meet the requirements instead. That is a legitimate answer, not a fallback.
- This point will need rewriting more than once. A file written today, citing no harmonised standard because none is listed, becomes out of date the first time a tranche publishes — and nothing tells you it happened. This is the single most perishable part of the technical file.
Where the software bill of materials appears — twice
The SBOM shows up in two different places in the annex, on two different triggers, and the difference matters:
- Point 2 — always. The SBOM is part of the design and development information you hold as a matter of course.
- Point 8 — on request. Separately, the SBOM must be provided when market surveillance authorities ask for it.
Citing point 8 for the routine case is a factual error, and it is a common one. You hold the SBOM because of point 2; you hand it over because of point 8.
On depth: the statutory floor is that the SBOM covers at the very least the top-level dependencies. That is a much lower bar than the full transitive dependency graph some tooling implies, and it means a documented list clears the requirement. Going deeper is a choice, not an obligation.
The simplified form for small companies
Microenterprises and small and medium-sized enterprises may provide the technical documentation in a simplified form, and the Commission is to provide a simplified format for them to use.
Two things to be clear about:
- The obligation is not reduced. You still have to hold the documentation, still have to address the essential requirements, still have to keep it for ten years. Only the form is simplified.
- It is not a size exemption. There is no company-size exemption anywhere in the regulation. A two-person manufacturer carries the same obligations as a large one.
Format, templates, and what actually matters
The regulation specifies contents, not format. There is no official Commission template for the general technical documentation, and at the time of writing the Commission's own guidance pages offer guidance and FAQs rather than fillable forms.
So a technical file can be a document, a set of documents, or an export from a system. What matters is:
- Every point of Annex VII is addressed, including the ones you decided are not applicable.
- It is specific to your product — a filled-in template, not a blank one.
- You can produce it on request for the whole retention period, which is at least ten years and possibly longer.
- You can tell which version was current when, because the product and the standards underneath it both change.
The order to do this in
- Decide your support period and write down why. Point 4, and almost everything else depends on the number — the retention clocks, the customer information, the line you have to publish at point of purchase.
- Do the risk assessment. Point 3. Requirement by requirement, including the ones that do not apply and the reason.
- Write down the architecture and processes. Point 2. Mostly existing knowledge.
- Assemble the SBOM. Top-level dependencies clears the floor.
- Answer the standards question honestly. Point 5. If none are listed, describe your alternative solutions — and diarise a review for each expected tranche date.
- Gather your test evidence. Point 6.
- Write the declaration of conformity and put a copy in the file. Point 7.
- Write the general description last. Point 1, which pulls in the Annex II user information, so it is easier once the rest exists.
Find out which documents apply to your product
Eight questions, two minutes, no email needed. Your conformity route, every document that applies, and where each requirement comes from.
Or have all five written from a questionnaire and kept current as the standards land — €390 a year.