EU Cyber Resilience Act FAQ Technical Documentation

CRA technical documentation is the product-level evidence file that shows how the manufacturer ensured conformity with the applicable essential cybersecurity requirements.

Article 31 requires the file to contain all relevant data or details of the means used by the manufacturer to ensure conformity. Annex VII then sets the minimum content, where applicable, for the relevant product with digital elements.

The file needs a traceable scope. It should identify the product variants and compliance-relevant software versions covered, the remote data processing and third-party components included in the assessment, and the evidence version that supported each market release. Without that mapping, a test report or risk assessment may be technically valid but attached to the wrong product configuration.

The manufacturer must draw up the technical documentation before placing the product with digital elements on the market.

After placing on the market, Article 31 requires the file to be continuously updated, where appropriate, at least during the support period. The Commission FAQ also treats the file as something that must be available when the product is placed on the market, regardless of where the records are physically stored.

Annex VII requires, as applicable, a general product description, intended purpose, software versions affecting compliance, relevant hardware images or illustrations, and the user information and instructions from Annex II.

It also requires design, development, production, and vulnerability handling information; the cybersecurity risk assessment; support-period determination information; standards, common specifications, certification schemes, or alternative technical solutions used; test reports; the EU declaration of conformity; and, where applicable, the software bill of materials for authority checks.

The record should show the product's intended purpose and reasonably foreseeable use, the risks assessed across design, development, production, delivery, and maintenance, and how those risks informed the implementation of Annex I Part I requirements.

Where a product-property requirement is treated as not applicable, Article 13(4) requires a clear justification in the cybersecurity risk assessment included in the technical documentation. That means the record should preserve the applicability decision, the reason for excluding the requirement, and any risk treatment used instead.

Yes. Annex VII expressly requires information and specifications for the manufacturer's vulnerability handling processes.

Useful CRA evidence includes the SBOM where applicable, the coordinated vulnerability disclosure policy, proof that a contact address exists for vulnerability reports, secure update distribution design, test reports for vulnerability handling processes, and the information used to determine the support period under Article 13(8).

For module A, the manufacturer relies on internal control, verifies conformity, draws up the technical documentation, affixes CE marking, and declares conformity on its own responsibility.

For module B+C, the manufacturer draws up the technical documentation and a notified body assesses the design based on that documentation and a specimen or sample. For module H, the manufacturer operates a full quality system and draws up technical documentation through that system while the notified body assesses the quality system.

Yes, but the file must be explicit. Annex VII requires the list of harmonised standards, common specifications, or European cybersecurity certification schemes applied in full or in part.

If the manufacturer did not use them, the documentation must describe the alternative solutions used to meet Annex I requirements and list other relevant technical specifications. If a standard, common specification, or scheme was applied only partly, the file must say which parts were applied.

Yes, for products with digital elements referred to in Article 12 that are also subject to other Union legal acts requiring technical documentation.

Article 31(3) requires one technical-documentation set in that case, containing both the CRA information and the information required by the other Union acts. The combined dossier must still let each applicable law's conformity case be assessed.

Yes. The Commission FAQ says technical documentation may form part of the quality-system documentation where a manufacturer uses a quality-system-based route such as module H.

Under CRA Annex VIII Part IV, the quality system covers design, development, final product inspection and testing, and vulnerability handling. The application to the notified body includes technical documentation for one model of each product category intended to be manufactured or developed.

For conformity assessment, Article 31(4) requires the technical documentation and related correspondence to be in an official language of the Member State where the notified body is established or in a language acceptable to that body.

For market surveillance, the separate practical rule is authority comprehension: Article 13(22) and Article 53 require information, documentation, or data to be provided in a language easily understood by the requesting authority. The Commission FAQ says the file can be written in any language, but must be provided in an authority-understandable language when requested.

Generally, no. The Commission FAQ states that there is no general obligation to make technical documentation available to customers or the public.

Article 32(5) provides an alternative route for qualifying Annex III free and open-source software: the manufacturer may use any Article 32(1) procedure, including Module A, if Article 31 technical documentation is public at market placement. A class I FOSS product may also use Module A under the ordinary Article 32(2) conditions without relying on that special route.

Authorities are not limited to a neat front-office dossier. On a reasoned request, manufacturers must provide the information and documentation necessary to demonstrate conformity.

Article 53 allows market surveillance authorities, where necessary to assess conformity, to access data needed to assess product design, development, production, and vulnerability handling, including related internal documentation. For SBOMs, Annex VII includes them where applicable and further to a reasoned authority request when necessary to check compliance with Annex I.

Yes, where the change affects the conformity case. Article 31(2) requires continuous updating where appropriate, at least during the support period.

The Commission CRA guidance applies the Blue Guide approach: technical documentation has to be updated to the extent the modification affects applicable requirements, while unaffected aspects do not need to be retested or redocumented. Security updates that do not amount to substantial modifications can still require the file to remain accurate and complete.

Not automatically. The Commission CRA guidance says manufacturers should not be read as having to recreate original design and development test evidence for products designed before CRA application where doing so would not improve the product's security.

That does not remove the current conformity burden. The manufacturer still needs a current CRA technical file that demonstrates conformity, including the cybersecurity risk assessment, test reports or other verification evidence, and Annex VII content that is available for conformity assessment and market surveillance.

Yes, but only in the way Article 33(5) provides.

Microenterprises and small enterprises may provide the Annex VII elements using a simplified format once the Commission specifies that form by implementing act. Notified bodies must accept that simplified form for conformity assessment purposes.

No. The CRA specifies the information that must be present, not one filing structure.

A manufacturer can organise the file across tools, repositories, suppliers, and quality-system records, but the assembled evidence still has to be complete, clear, versioned, and producible when a notified body or market surveillance authority needs to assess conformity.

The technical file should make clear which product version, software version, model, variant, or redesign each conformity record supports.

The Commission CRA guidance allows reuse of one cybersecurity risk assessment, one technical-documentation set, and one conformity assessment for variants in a product family only where the products share the same architecture, security-relevant design, intended purpose, and cybersecurity risks. Differences that affect cybersecurity, such as communication interfaces, software stacks, update mechanisms, or remote connectivity, must be reflected in the risk assessment, technical documentation, and conformity assessment where necessary.

If a product has a remote data processing solution (RDPS) or relies on relevant third-party cloud solutions, the technical documentation should identify and describe those solutions.

The Commission CRA guidance says the same RDPS documentation may be reused across product conformity assessments, but the RDPS must still be declared in each product's technical documentation. The risk assessment should also cover RDPS risks, third-party cloud-service risks treated similarly to third-party components, and relevant product-environment risks.

Yes, in principle, but the responsibility remains with the manufacturer.

The CRA requires the documentation to be drawn up, contain the required Annex VII content, be available before placing on the market, be kept up to date where appropriate, and be provided to authorities on reasoned request. The statute does not require one physical folder, but fragmented storage is risky if it prevents the manufacturer from producing a coherent, complete, authority-readable file.