# CRA technical documentation: what goes in the technical file (Annex VII)

Source: https://scadable.com/blog/cra-technical-documentation-annex-vii
Published: 2026-07-07

---

**The CRA technical file is the documented proof that your product meets the essential requirements. Under Annex VII it must contain a description of the product, its design, development, and production, the cybersecurity risk assessment, the standards or other solutions applied, the SBOM, test reports, and the EU declaration of conformity, kept up to date for 10 years or the support period, whichever is longer.**

The Cyber Resilience Act, [Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj), makes this file mandatory for every product with digital elements placed on the EU market once the full requirements apply on 11 December 2027. It is item eight on our [CRA compliance checklist](/blog/cra-compliance-checklist), and it is last there for a reason: a good technical file is assembled from work you are already doing, not written as a separate project. For the full requirement set, see the [Cyber Resilience Act framework page](/frameworks/cyber-resilience-act).

## What must the technical documentation contain?

Annex VII sets out the contents. In practical terms, the file has seven parts.

| Annex VII element | What it means in practice | Where teams usually stand |
| --- | --- | --- |
| General description of the product | Intended purpose, supported hardware and software versions, photos or illustrations, user information and instructions | Mostly exists in marketing and support material, rarely consolidated |
| Design, development, and production information | Architecture drawings, how components interact, the build and release process, and the vulnerability-handling process | Scattered across wikis, repos, and heads |
| Cybersecurity risk assessment | The assessment that drove which essential requirements apply and how they are met | Often missing entirely or done once and never revisited |
| Standards and solutions applied | The harmonised standards applied in full or in part, or a description of the other means used to meet the requirements | Blocked on harmonised standards still being finalised; document your chosen means now |
| Test reports | Reports of the tests carried out to verify conformity, including vulnerability-handling checks | Usually exists as CI output, rarely retained as evidence |
| Software Bill of Materials | An SBOM covering the components in the product, per shipping version | The single most common gap on fielded product lines |
| EU declaration of conformity | A copy of the signed declaration | Cannot be issued until everything above holds together |

None of these are exotic artifacts. The difficulty is that they must describe the product as actually shipped, per version, and stay accurate as the product changes.

## How long does the technical file have to be kept?

At least 10 years after the product is placed on the market, or for the support period, whichever is longer, and it must be kept up to date across that window. That word "current" is the operational load. A firmware release that swaps a TLS library invalidates the old SBOM, a design change can shift the risk assessment, and a new test campaign produces new reports. Treating the file as a launch-day PDF is the most common structural mistake; it is a living record with the same lifetime as the product.

## Who asks to see the technical file?

Two audiences, with different postures. **Market surveillance authorities** can request the documentation, and for a non-EU manufacturer the authorised representative typically holds it as the EU point of contact. **Notified bodies** work through the file during third-party conformity assessment, which applies to products in the important and critical classes; within the important class, the higher Class II categories in particular should expect the file to be examined rather than skimmed. Default-class products self-assess, but the file is not optional for them, it is the substance behind the [EU declaration of conformity](/blog/cra-conformity-assessment-self-or-notified-body) the manufacturer signs.

## What does a good technical file look like in practice?

The teams that handle this well converge on the same structure: one file per product line, organised by Annex VII heading, with each section pointing at generated evidence rather than duplicating it.

1. **A top-level index** mapping each Annex VII element to where the evidence lives and when it was last updated.
2. **Generated, not written, wherever possible.** The SBOM comes from the build, test reports come from CI, the update history comes from the release process. Hand-written sections are limited to the product description and the risk assessment narrative.
3. **Versioned alongside the product.** The file for firmware 3.2 is reconstructable even after 4.0 ships, because authorities can ask about anything within the retention window.
4. **The reporting trail included.** Records of vulnerability handling and any [Article 14 reports](/blog/cra-vulnerability-reporting-article-14) filed demonstrate the vulnerability-handling process is real, not aspirational.

## What are the most common gaps?

Four show up repeatedly. First, no SBOM for older shipping versions, which makes the design and vulnerability-handling sections unverifiable; our guide to [CRA SBOM requirements](/blog/cra-sbom-requirements) covers what the file actually needs. Second, a risk assessment that was never written down, because the team made sensible security decisions but kept the reasoning in Slack. Third, test evidence that was produced and discarded, since CI results expire with the build retention policy. Fourth, staleness: everything was accurate at launch and nothing was touched afterwards. All four have the same fix, wiring the file to the systems that already produce the evidence instead of copying evidence into a document.

## Do small manufacturers get any relief?

Some. Microenterprises and small companies get simplified documentation options for the technical file, a lighter administrative format rather than a different security bar. The evidence still has to exist, as we cover in [CRA exemptions for legacy products and small business](/blog/cra-exemptions-legacy-products-small-business); there is no company-size exemption from the requirements themselves.

## Frequently asked questions

**What is the CRA technical file?** The technical documentation a manufacturer must draw up before placing a product with digital elements on the EU market. It contains the evidence that the product meets the essential requirements, from the product description and cybersecurity risk assessment to the SBOM, test reports, and the EU declaration of conformity.

**What must CRA technical documentation contain?** A general description of the product, information on its design, development, and production and on vulnerability handling, the cybersecurity risk assessment, the list of harmonised standards applied or the other solutions used, test reports from the conformity checks, the SBOM, and a copy of the EU declaration of conformity.

**How long must the technical file be kept?** It must be kept available and up to date for at least 10 years after the product is placed on the market, or for the support period, whichever is longer. It is a living file across that window, not a snapshot from launch day.

**Who can ask to see the technical file?** Market surveillance authorities can request it, and a notified body works through it during third-party conformity assessment for products in the important and critical classes. Default-class products still need the same file to support their self-assessment.

**Do small companies get simplified technical documentation?** Microenterprises and small companies get some simplified documentation options for how the technical file is prepared. The evidence still has to exist; the flexibility is in the format and administrative burden, not in the security requirements themselves.

## Where Scadable fits

Scadable is the compliance engine for connected-product companies, and the technical file is a by-product of it doing its job: the live SBOM per shipped version, the component-to-vulnerability mapping, the fix and backport history, and the report trail accumulate as evidence while it identifies what is actively exploited, fixes it, files the report, and keeps you certified. Run the free two minute [CRA readiness check](/cra-readiness-check) to see which obligations apply to your product, or [book a walkthrough](https://cal.com/rahbaral/quick-chat).