Cyber Resilience Act
Technical documentation
Practical term
Technical documentation is the evidence behind the declaration of conformity. Article 31 of the Cyber Resilience Act (CRA) requires it to be drawn up before placing on the market. It is a precondition of market access, not paperwork that follows it.
Its purpose is narrow: it has to make it verifiable that the product and the manufacturer’s processes meet the essential cybersecurity requirements in Annex I. Anything that does not support that demonstration does not belong in it.
What goes in
Annex VII sets the frame, each item only as far as it is applicable to the product concerned. In essence:
- a general description of the product, including its intended purpose, the software versions affecting compliance and the user information under Annex II
- design and manufacturing information, and the architecture as far as it bears on security
- the cybersecurity risk assessment the product was developed against
- a description of how each individual Annex I requirement is met
- information on vulnerability handling, including the Software Bill of Materials (SBOM)
- the harmonised standards applied in full or in part whose references have been published in the Official Journal, and, where none were applied, a description of the solutions adopted instead
- the test reports evidencing compliance
- a copy of the EU declaration of conformity
The mapping is the actual work
The most common mistake is gathering existing artefacts and declaring them to be the technical documentation. Architecture diagrams, test reports and backlogs are valuable building blocks, but only a traceable mapping to individual requirements turns them into evidence.
A plain overview works well in practice: the Annex I requirements in one column, and in the other a pointer to where in the product and in which document compliance is evidenced. That overview is the first thing needed when market surveillance asks.
Retention and currency
Technical documentation and the EU declaration of conformity must be kept available to market surveillance authorities for at least ten years after placing on the market, or for the support period where that runs longer.
“Kept available” means more than archived: under Article 31(2) the documentation has to be continuously updated, where appropriate, at least during the support period, because the risk assessment and the vulnerability picture keep changing.
Who else has to hold it
Where a manufacturer has appointed an authorised representative, keeping the documentation available to market surveillance authorities is among that representative’s minimum tasks. Importers, in turn, must satisfy themselves before placing a product on the market that the manufacturer drew the documentation up at all.
It is therefore not an internal paper but a precondition checked along the supply chain.
Practical questions
-
At least ten years from placing on the market. Where the support period runs longer, that period governs. The same applies to the EU declaration of conformity. For long-lived products that can run well beyond ten years.
-
Usually not without additions. Development documentation describes how something was built; technical documentation has to evidence that the essential requirements are met. The difference is the mapping: every requirement in Annex I needs a traceable link. Existing artefacts can be folded in, but they do not replace the mapping.
-
Yes. Article 31(2) requires it to be continuously updated, where appropriate, at least during the support period. That applies in particular to the risk assessment and to vulnerability handling, both of which change continuously over a product’s life. Documentation frozen at launch does not serve its purpose.
This glossary is for orientation and does not constitute legal advice. The wording of Regulation (EU) 2024/2847 prevails.