The CRA Technical File: Assembling the Evidence Pack a Market Surveillance Authority Will Ask For

The CRA technical documentation is not a form you fill in before an audit. It is the file a market-surveillance authority asks to see first, and by the time they ask, whatever is missing is already missing.

The Cyber Resilience Act — Regulation (EU) 2024/2847 — entered into force in December 2024. Its reporting duties for actively exploited vulnerabilities and severe incidents start to apply from 11 September 2026, and the substantive manufacturer obligations, including conformity assessment and CE marking, apply from 11 December 2027. Most of the writing about the CRA treats it as a conformity checklist. It is more useful to treat it as an evidence problem: what does a manufacturer of a product with digital elements have to be able to put on the table, on demand, and how does that file stay true as the product keeps shipping.

What the technical file actually is

The CRA requires a manufacturer to draw up technical documentation before a product with digital elements is placed on the market, and to keep it at the disposal of market-surveillance authorities for at least ten years after placing, or for the support period, whichever is longer. The contents are specified in Annex VII, and the file is the underlying evidence for the EU declaration of conformity — the document in which the manufacturer asserts, in its own name, that the product meets the essential cybersecurity requirements in Annex I.

That framing matters because it tells you who the file is really for. It is not for your engineers, though they write most of it. It is for an authority who has never seen your product, may be looking at it because someone complained or because a vulnerability was exploited, and who will judge your compliance almost entirely by what the file demonstrates. If the file cannot show it, for CRA purposes it did not happen.

What Annex VII asks the file to contain

Annex VII sets out the minimum the file must hold. In substance, an authority expects to find:

• A general description of the product — what it is, its intended purpose, versions, and the software and hardware in scope, including how it processes and stores data.
• The design, development and production account — architecture, system diagrams, and a description of how the product is built and maintained, including the vulnerability-handling processes required by Annex I, Part II.
• The cybersecurity risk assessment — the assessment the CRA requires you to carry out and to take into account across the design, development and vulnerability-handling of the product. This is the spine of the file; the essential requirements you applied, and the ones you judged not to apply, both trace back to it.
• The software bill of materials — the SBOM referred to in Annex I, Part II, covering at minimum the top-level dependencies of the product. Where components carry known vulnerabilities, the file needs to show you knew and how you handled them.
• The support period and how it was determined — the period during which you will supply security updates, and the reasoning behind it.
• Standards and conformity evidence — the harmonised standards or other specifications applied, the results of tests carried out to verify conformity, and the EU declaration of conformity itself.

None of this is exotic to a competent engineering organisation. The difficulty is not producing any one element. It is producing all of them, consistent with each other, for the version currently on the market, on the day someone asks.

The support period is a design decision, not a footnote

The CRA sets the support period at a minimum of five years, unless the product is expected to be in use for less, in which case it matches the expected use time. That single figure carries more downstream cost than anything else in the file. It is a commitment to handle vulnerabilities and ship free security updates for that whole period, which means it is also a commitment to keep a build pipeline, a test environment and a release channel alive for that long — for versions your product roadmap would otherwise have retired.

Write the support period into the file as a number you can defend, not a number that sounds reasonable. An authority, and increasingly an enterprise buyer, will read it as a promise. The questions your first serious enterprise customer asks already circle this ground; the CRA turns the answer into a documented, enforceable obligation rather than a line in a sales call.

Why “living” is the whole game

A technical file assembled once, for the launch version, is worthless six months and four releases later. The product it describes no longer exists. The SBOM is the clearest example: dependencies change with almost every build, and a bill of materials that reflects last quarter’s tree tells an authority nothing true about the binary a customer is running today. The same decay hits the risk assessment when the architecture shifts, and the test results when the code moves on.

The only sustainable answer is to generate the volatile parts of the file from the pipeline that builds the product, rather than maintaining them by hand alongside it. This is the same discipline as treating technical documentation as living code: the file is an output of the build, versioned with the release it describes, not a document someone remembers to update. For the SBOM specifically, that means generating, signing and attesting it in the pipeline so that every release carries a bill of materials you can prove corresponds to that exact build. Do that, and “produce the current technical file” becomes a query, not a project.

Assign an owner to every section

The failure mode is not ignorance; it is diffusion. The risk assessment sits with security, the SBOM with the build team, the support period with product, the declaration of conformity with legal, and the test results with QA. When no single person owns the file as a whole, each part is individually plausible and the file collectively does not hang together — the SBOM lists a component the risk assessment never mentions, the support period in the declaration differs from the one in the release notes.

Name an owner for each Annex VII section and one owner for the file’s coherence. Put the file under version control next to the product, so that a release which changes the architecture or the dependency tree cannot ship without the corresponding sections moving with it. Decide, now, how a request from a market-surveillance authority is answered — who assembles it, from where, and how quickly — because the honest test of the file is not whether it exists but whether you can hand over the current version, for the version on the market, in days rather than weeks.

The manufacturers who struggle in December 2027 will not be the ones who misunderstood Annex VII. They will be the ones who built the file once, for the launch, and let the product walk away from it.