A market surveillance authority may request the documentation required under the Cyber Resilience Act as part of its enforcement activities. Regulation (EU) 2024/2847 requires manufacturers to prepare technical documentation before placing a product with digital elements on the EU market and keep it at the disposal of market surveillance authorities. That obligation runs for at least 10 years after a product reaches the market, or for the full support period if that runs longer.
Failure to meet CRA obligations can result in significant administrative fines. The applicable penalty depends on the type of infringement. The CRA requires four distinct document types. The CRA provides different maximum fine levels for non-compliance with essential cybersecurity requirements, documentation and conformity obligations, and the supply of incorrect or misleading information.
In fact, that single phrase, at the disposal, changes how documentation actually needs to work. Because of that, it can’t be something you assemble reactively once a letter arrives. This guide walks through exactly which documents the CRA requires and which Annex governs each one. It also covers where most manufacturers discover a gap, usually only after an authority has already asked to see the evidence.
What Does Documentation-First Actually Mean Under the Cyber Resilience Act?
Documentation-first means building the technical file, risk assessment, and SBOM alongside the product itself, not compiling them after development finishes. The documentation should allow the manufacturer to demonstrate how the product and its development, production, and vulnerability-handling processes meet the applicable CRA requirements.
This distinction matters, particularly because of when the obligation kicks in. Article 31 of the EU Cyber Resilience Act requires manufacturers to draw up technical documentation before placing a product on the market. As a result, the document has to exist at launch, and it has to stay accurate every time the product changes afterwards. A technical file written once and never updated becomes a liability the moment a market surveillance authority compares it against the shipped product and finds a mismatch.
What Documents Make Up the Core Cyber Resilience Act Package?
What Documentation and Evidence Does the CRA Require? Let’s find out below:
| Documentation/evidence | CRA provision | Role |
| Technical documentation | Article 31 + Annex VII | Core technical evidence demonstrating conformity |
| EU Declaration of Conformity | Article 28 + Annex V | Manufacturer’s formal declaration |
| Simplified EU Declaration of Conformity | Article 28 + Annex VI | Simplified user-facing declaration where applicable |
| SBOM | Annex I Part II + Annex VII | Vulnerability-handling evidence incorporated into technical documentation |
Because these sit under separate Annexes, gaps can hide in plain sight. A manufacturer can have a complete SBOM and still fail a review. That happens when the technical documentation doesn’t reference Annex II’s user instructions, or when the declaration of conformity cites the wrong conformity assessment route for the product’s classification.
When Does Each Cyber Resilience Act Document Actually Need to Exist?
The core conformity documentation must be prepared before the product is placed on the EU market. The technical documentation must be continuously updated where appropriate, while declarations and supporting evidence must be maintained in accordance with their specific CRA requirements. Treating documentation as a pre-launch task with no ongoing obligation is where most manufacturers underestimate the work involved.
Technical documentation and the EU Declaration of Conformity both need retention for at least 10 years after the product reaches the market. If the full support period runs longer, that becomes the retention window instead. That’s a genuinely long stretch. Documentation practices built for a two-year product cycle simply won’t hold up if the product’s actual support commitment runs further.
However, open-source software creates a specific exception worth knowing. A special rule applies to certain free and open-source software products. For products qualifying as free and open-source software that fall within Annex III categories, Article 32 allows the relevant conformity route to be used with the Article 31 technical documentation made publicly available when the product is placed on the market. The CRA’s treatment of open-source software also depends on whether it is made available in the course of a commercial activity.
Is Cyber Resilience Act Certification Self-Assessed or Third-Party Audited?
For products outside the categories subject to stricter conformity-assessment procedures, manufacturers may generally use internal production control. Products in the important and critical categories have additional conformity-assessment requirements, with the applicable route depending on the product class, applicable standards or specifications, and the procedure available under Article 32. Specifically, getting this classification right at the documentation stage avoids assembling the wrong evidence package entirely.
Self-assessed documentation still has to be genuinely rigorous. That’s because a market surveillance authority can request it at any point, not only during a formal audit. Third-party conformity assessment adds a layer on top. A notified body reviews the same underlying technical documentation, plus additional evidence depending on which conformity route under Annex VIII applies. Even so, manufacturers sometimes assume third-party assessment replaces the need for solid internal documentation. Instead, it depends on that documentation being complete before the notified body even gets involved.
What Documentation Gaps Most Often Fail a CRA Review?
The most common failure isn’t a missing document. It’s a technical file that describes a version of the product that no longer matches what actually ships. A few specific patterns show up repeatedly.
A manufacturer may generate an SBOM during development and fail to update or revalidate it after dependency, build, or packaging changes, creating a gap between the documented components and the product actually shipped. Annex VII specifies the contents of the technical documentation, while Annex II sets out the user information and instructions that must accompany the product. The technical documentation should contain or identify the applicable user information and instructions required by the CRA.
Because of that link, a common failure is shipping updated user-facing security guidance without updating the corresponding entry in the technical file. The Declaration of Conformity sometimes references the wrong conformity assessment route entirely.
A change to a product’s functionality, intended use, or cybersecurity characteristics may affect its classification or conformity-assessment route. Where that occurs, the manufacturer should reassess the applicable route and update the relevant conformity documentation.
Vulnerable pattern, common in SBOM generation workflows:
# Lists packages installed in the environment but is not a complete SBOM
python -m pip freeze > installed-packages.txt
Fixed pattern, aligned to Annex VII’s evidence requirements:
# Illustrative: generate a CycloneDX SBOM from the current Python environment
cyclonedx-py environment --output-format json --output-file sbom.json
pip freeze produces an installed-package list, not necessarily a complete SBOM with identifiers, metadata, and dependency relationships. An SBOM generator such as CycloneDX or SPDX should be run against the actual build or runtime environment, and the output should be validated for completeness and accuracy.
How Does Qualysec Help Build Audit-Ready CRA Documentation?
Technical Documentation Review Against Annex VII
Qualysec reviews existing technical documentation against Annex VII’s specific content requirements. We check that the product description, design evidence, and Annex I conformity evidence actually match the shipped product, not an earlier development milestone.
SBOM Completeness and Currency Validation
Specifically, we test whether a generated SBOM captures the full dependency tree, not just direct dependencies, and confirm the output stays current as the product’s components change. This is exactly where automated tooling commonly falls short without ongoing validation.
Penetration Testing Evidence for CRA Technical Documentation
Annex VII requires technical documentation supporting the product’s conformity with the applicable CRA requirements. Qualysec’s penetration testing can provide supporting evidence for selected Annex I requirements, including documented findings, testing activities, and remediation verification, but it does not by itself demonstrate conformity with every Annex I requirement.
Penetration-testing reports can strengthen the technical file by providing documented security-test evidence, but they should be combined with the risk assessment, vulnerability-handling records, SBOM, user information, and other applicable conformity evidence.
Schedule a CRA documentation readiness review with Qualysec!
Conclusion
Cyber Resilience Act documentation isn’t a single filing exercise completed once and archived. It’s four connected document types, each governed by a different Annex. Each carries its own retention and disclosure rules. All of them are expected to reflect the product currently on the market, not an earlier version. Manufacturers that build documentation alongside development are the ones who benefit most. Keep it current every time a component or feature changes, and the technical file actually holds up when a market surveillance authority asks to see it.
Contact Qualysec to build audit-ready CRA documentation for your product line!
FAQs
1. What documentation will manufacturers need under the CRA?
The main CRA manufacturer obligations apply from 11 December 2027. The core documentation includes technical documentation under Article 31 and Annex VII, an EU Declaration of Conformity under Article 28, and the supporting evidence required by the applicable conformity-assessment procedure. The technical documentation includes, among other things, the cybersecurity risk assessment, vulnerability-handling information, SBOM, and test reports.
2. Is a CE marking the same as EU CRA certification?
No. However, CE marking is the manufacturer’s declaration that the product complies with the applicable EU legislation requiring CE marking after the relevant conformity-assessment procedure has been completed. Depending on the product category and route, that procedure may be internal production control or may require a notified body.
It indicates that the manufacturer declares conformity with the applicable EU requirements and has completed the required conformity-assessment procedure. The manufacturer remains responsible for maintaining the technical documentation and EU Declaration of Conformity. The marking itself isn’t a separate certification process; it’s the result of one.
3. What are the Cyber Resilience Act requirements for SBOM documentation?
The CRA requires an SBOM in a commonly used format covering at least the product’s top-level dependencies. Manufacturers must maintain the SBOM as relevant product components change. Manufacturers must include it in technical documentation and provide it to market-surveillance authorities upon request. The CRA does not generally require manufacturers to make the SBOM public. The SBOM forms part of the manufacturer’s broader CRA compliance evidence and technical documentation; it is not generally a separate public filing.
4. How long must manufacturers retain CRA compliance records?
Manufacturers must retain the technical documentation and EU Declaration of Conformity for market-surveillance authorities for 10 years after placing the product on the market or for the product’s support period, whichever is longer. If the support period runs longer than that, the longer window applies instead. Because support periods can extend well past that 10-year floor, some products require considerably longer retention in practice.
5. Do UK manufacturers need separate EU and UK documentation?
Yes, in practice. The EU CRA generally applies when a product with digital elements is placed on or made available on the EU market, regardless of whether the manufacturer is established inside or outside the EU.
As a result, a UK manufacturer placing products with digital elements on the EU market generally needs to comply with the CRA, in addition to complying with any applicable UK requirements. Brexit doesn’t create an exemption. Instead, UK manufacturers selling products in both markets should assess and document compliance with the EU CRA and the applicable UK product-security requirements separately; compliance with one regime does not automatically establish compliance with the other.
6. Is there a standard EU CRA checklist manufacturers can follow for technical documentation?
There are four key pillars that should be included in the checklist for successful EU CRA approval. These are the Article 31/Annex VII technical documentation, an SBOM with up-to-date information about the software dependencies, instructions complying with Annex II, and an EU Declaration of Conformity pursuant to Annex V or Annex VI. Using a well-designed checklist will make sure that your documentation always stays correct throughout the entire life cycle of the product.
