Don’t write your first CRA technical file alone

Insights · cetome.com

Don't write your first CRA technical file alone

Sylvain DELAGRANGESenior product security advisor, cetome

12 April 2026 · Cyber Resilience Act · 5 min read

Ask a manufacturer what CRA compliance involves and the answer usually centres on the product: secure defaults, update mechanisms, vulnerability handling. Ask what a conformity assessment examines and the answer is different. It examines documents.

Under the Cyber Resilience Act, the technical documentation must exist before the product is placed on the market and be kept up to date throughout the support period. It is the evidence on which everything else rests, and it is where most manufacturers lose the most time.

Documentation is the assessment

We learned this on the Radio Equipment Directive. In EN 18031, the manufacturer’s required information and justifications are the basis for the conceptual and functional completeness assessments, before any functional testing begins. EN 303 645 works the same way with its implementation statements. A lab cannot assess what has not been described, and a weak description produces a failed assessment regardless of how secure the product is.

The CRA follows the same logic with a wider scope. The technical documentation covers the product’s design and architecture, the cyber security risk assessment, how each essential requirement applies, the vulnerability handling process, the rationale for the support period, the standards applied and the test evidence.

For important and critical products, a notified body will review this file. For the majority of products, which follow self-assessment, nobody reviews it before launch. That makes it more important, not less: the file is the only thing a market surveillance authority will see when it asks how you reached your declaration of conformity, and the manufacturer carries the full weight of what it says.

Why the first file is the hardest

Development teams asked to write compliance documentation for the first time face three problems at once. They do not know what level of detail an assessor expects. They are describing a product they know too well, so they skip what seems obvious and over-explain what is interesting. And they are doing it alongside their actual job.

The result is familiar: several months of effort, a long document, and no assurance that it answers the questions the regulation asks.

Our recommendation

Do not write your first technical file alone. Have a specialist draft it from your internal documentation, with your engineers reviewing and correcting. The manufacturer remains responsible for the content and must own it; what changes is who does the first draft and how long it takes.

An outside reader finds the gaps. A specialist reads your architecture documents, specifications and test reports against the requirements, and sees what is missing or unsupported. They also know where a standard leaves legitimate room for interpretation and how to justify a design choice in terms an assessor accepts.

Your team learns by reviewing. Reviewing a well-built file teaches engineers what the regulation expects far faster than drafting one from a blank page. By the second or third product, most teams maintain the documentation themselves.

The work continues past the writing. Someone who deals with labs and notified bodies regularly knows what they look for and can support you if an assessment raises questions. A failed assessment is difficult to recover from without that experience.

It is fast. On RED, our record for the full EN 18031 documentation of a multi-protocol device with several variants is one week: two days reading, two days writing, one day of review. Two to three weeks is typical, and up to six for complex products where the team has little time to support. A CRA file covers more ground, but the method is the same, and the elapsed time is still measured in weeks, not months.

You own the result. Product lines share platforms, components and processes. A well-structured file for the first product becomes the template for the rest of the portfolio, in a format you control, with no per-product or per-user cost. The investment falls sharply with each product.

Where tools fit

Documentation platforms have a place once you know what good looks like. Starting with one means configuring a tool to produce a document nobody on the team has yet seen done well. Do the first product properly, understand the structure, then decide what is worth automating.

If your products have already been through RED, most of the file exists: one technical file for RED and the CRA shows what carries over and what the CRA adds.

Summary

If you are preparing your first CRA file, evaluate your products with CRAted, see how we approach CRA readiness or talk to us. For RED and EN 18031 documentation, our free REDact toolkit covers the file.