‍The Cyber Resilience Act requires compliance documentation for every product you sell in the EU. Here's what goes in it, how to structure it, and what you can start building today.

What is the technical file?

It's your evidence folder. The master document that proves your product meets CRA cybersecurity requirements. You compile it before placing the product on the EU market, keep it for 10 years after placing the product on the market (or the full support period, whichever is longer), and hand it over if a market surveillance authority asks.

You claim your product is secure. The technical file is the proof.

Who needs it?

Every manufacturer of a product with digital elements sold in the EU. Hardware, firmware, software, IoT - if it connects and you sell it in Europe, the EU cybersecurity documentation requirements apply to you. The category (Default, Class I, Class II, Critical) determines who checks it - you or a notified body - but the file itself is required for all categories.

What's in it?

Annex VII of the CRA lists 8 required elements. No official template exists as of 4th May 2026. Here's what each one actually means and what you need to produce.

1. Product description

Tell someone who's never seen your product what it is and what it does.

Include:

• Product name, model, version numbers (hardware and software)
• What it does and who it's for (intended use)
• Photos or diagrams of the physical product (if hardware)
• Network interfaces: WiFi, BLE, Ethernet, cellular, USB, serial - list them all
• User instructions: how to install, configure, operate, and securely decommission

Don't overcomplicate this. A clear product datasheet with a network architecture diagram covers most of it. If you already have a product brief for your sales team, start there.

2. Design and development information

This is the biggest section. It proves your product was built securely - not by accident, but by process.

Include:

• ‍Architecture diagrams - system design, component interactions, data flows. Where does data enter? Where does it go? Where is it encrypted, where isn't it? Important: if your product depends on a cloud backend you designed or had designed for you, that backend is part of the product scope under CRA. It's called a Remote Data Processing Solution (RDPS) - and it must be included in the architecture, the risk assessment, and the technical file.‍
• SDLC description - how your team builds software. If you follow IEC 62443-4-1 or a similar framework, reference it here. Threat modeling, secure coding standards, code review process, security testing before release.‍
• Vulnerability handling process - how you receive, triage, fix, and communicate vulnerabilities. Who owns it? What's the SLA?‍
• Coordinated vulnerability disclosure policy - your public-facing document that tells security researchers how to report bugs. A `security.txt` file (RFC 9116), a security contact page, a response timeline, and a safe harbor statement ("we won't sue you for responsible reporting").‍
• SBOM - Software Bill of Materials in machine-readable format (CycloneDX or SPDX). At minimum: top-level dependencies with names, versions, and suppliers.‍
• Secure update distribution - how you deliver firmware/software updates. Signed? Encrypted? Through what channel? How does the device verify authenticity?

If you follow IEC 62443-4-1, most of this section writes itself. The 8 practices produce exactly these artifacts. If you don't follow a formal framework - you still need the artifacts, you just have to document your own process.

3. Risk assessment

The cybersecurity risk assessment of your specific product. Not your company, not your office network - the product itself.

What it covers:

• ‍Assets - what's worth protecting? Firmware, user data, credentials, communication channels, physical device integrity.‍
• Attack surface - every interface and entry point. WiFi, BLE, UART, JTAG, debug ports, cloud API, OTA channel, physical access. For each: who can reach it, and is it exposed in production?‍
• Threats - per interface, what can an attacker do? STRIDE works well here (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege).‍
• Likelihood and impact - how probable is each threat? What's the damage? A simple low/medium/high matrix is enough.‍
• Mitigations - what's in place to address each threat? TLS, signed updates, per-device authentication, disabled debug ports, etc.‍
• Residual risk - after mitigations, what's left? Is it acceptable?‍
• Map to Annex I - map each CRA essential requirement to your mitigations. This is the bridge between "we assessed risks" and "we meet the regulation."

Risk assesment is continuous process - it must be updated throughout the support period - when new vulnerabilities are found, when the product is updated, when new threats emerge, or at regular intervals. Build it in a format your team will actually maintain long-term: a spreadsheet, a markdown document, a threat modeling tool output. The key is traceability: every Annex I requirement should point to a mitigation, and every mitigation should point to evidence.

Don't forget foreseeable use - the CRA requires you to assess risks not just for the intended purpose but also for "reasonably foreseeable use" - ways people will predictably use your product that you didn't design for. A battery monitor plugged into a network with internet access. A diagnostic tool connected to a laptop with remote desktop. If it's predictable, it's in scope.

Risk sharing with suppliers and users  - you don't have to mitigate every risk yourself. If your product uses a third-party module (cellular modem, WiFi chip), you can share risks with the supplier - but only if they're legally obliged (CRA-compliant themselves) or contractually committed to handling their part. You can also share risks with users by providing clear guidance - but only if it's within their reasonable expectations. "Configure the firewall yourself" is acceptable for a professional integrator, not for a consumer.

4. Support period justification

You must declare how long you'll provide security updates. The CRA says minimum 5 years or expected product lifetime, whichever is shorter.

Include:

• The declared support period and its end date
• How you determined the expected product lifetime (industry data, component lifetime, customer contracts)
• How you'll deliver security updates throughout (OTA, manual download, distributor notification)
• Where this information is published (product page, datasheet, point of sale)

Support period vs documentation retention - these are separate. The support period (5 years at minimum) is how long you provide security updates. Documentation retention (10 years after placing on the market, or the full support period, whichever is longer) is how long you keep the technical file. A product with a 7-year support period means 10 years of documentation retention.

For industrial products - a sensor on a factory floor might run 15+ years. You're not required to support it for 15 years - but you need to justify why your declared period is appropriate. "Our components have a 7-year expected lifetime, we're committing to 7 years of security updates" is a defensible position.

5. Standards applied

Which standards did you follow, and do they carry legal weight?

If you followed harmonised standards (as of 4th May 2026 they're still under development):

• Reference the standard number, version, and OJ publication reference
• This gives you presumption of conformity - a legal shortcut that says "following this standard means you meet the CRA requirements it covers"

If harmonised standards aren't available yet (which is the situation right now - the 41 CRA-specific standards are being developed):

• List the standards you followed anyway (IEC 62443, EN 303 645, ISO 27001, etc.)
• Reference common specifications published by the European Commission (hasn't been activated yet)
• Reference EU cybersecurity certifications like EUCC (EU Common Criteria scheme) - Critical Category
• Document how these standards map to CRA Annex I requirements - the ENISA/JRC CRA Requirements Standards Mapping document is your reference here

Practical reality today: Nobody has full presumption of conformity yet because the harmonised standards aren't published. Document what you follow, map it to CRA requirements, and update this section when the standards are officially listed. You're not penalised for using the best available standards before the official ones exist.

6. Test reports

Evidence that the product meets the essential cybersecurity requirements. Not claims - proof.

What counts:

• ‍Static analysis reports - Coverity, Cppcheck, SonarQube, CodeChecker output showing the codebase was scanned and findings were addressed‍
• Dependency/vulnerability scan results - Trivy, Grype, or OSV-Scanner output against your SBOM showing no known critical CVEs at release‍
• Functional security tests - "We tested that authentication works, unsigned firmware is rejected, default passwords don't exist, debug ports are disabled"‍
• Penetration test results - independent testing against your product's interfaces. Findings and remediation evidence‍
• Fuzz testing - input parser testing with coverage metrics‍
• The key is traceability. A mapping table that connects each Annex I requirement to a specific test:

"We designed it securely" is a claim. That table, with the attached reports, is evidence.

7. EU Declaration of Conformity

A formal document where you, the manufacturer, declare that your product meets CRA requirements. The format is defined in Annex V - it's one of the few things the CRA actually prescribes.

Required fields:

• Product name, type, and unique identification (model number, serial range, etc.)
• Your company name and address (or your EU authorized representative)
• Statement: "This declaration is issued under the sole responsibility of the manufacturer"
• Product identification enabling traceability (may include a photo)
• References to the harmonised standards or specifications applied
• If third-party assessed: notified body name, number, and certificate ID
• Date, place, signature of a responsible person

One page. Sign it, include it in the file, and keep a copy with the product documentation. If you sell multiple products, each one gets its own declaration. A single declaration can cover multiple EU regulations if the product falls under more than one (e.g., CRA + Radio Equipment Directive).

A note on self-assessment: Even when you're doing the conformity assessment yourself (Default and Class I with harmonised standards), the person doing the assessment should be impartial - ideally not the developer who built the feature. An internal security team member, a QA engineer, or an external consultant. The goal is an honest evaluation, not a rubber stamp.

8. SBOM (for authorities)

The SBOM appears twice in the file. Once in section 2 (as part of design documentation) and once here - specifically for market surveillance authorities who may request it.

Requirements:

• Machine-readable format: CycloneDX v1.6+ or SPDX v3.0.1+ (BSI TR-03183-2 recommendation)
• At minimum: top-level dependencies - component name, version, supplier
• Generated per build, not once
• Kept up to date with each release

You don't need to publish your SBOM publicly. It must be available to market surveillance authorities on request. But generating it on every build and scanning it for CVEs is your own operational necessity - that's how you meet the ongoing vulnerability monitoring obligation.

‍

The folder structure

No official format, but a clean structure helps - especially when an authority asks for it.

technical-file
├── 01-product-description
│   ├── product-brief.pdf
│   ├── network-architecture.pdf
│   └── user-instructions.pdf
├── 02-design-and-development
│   ├── architecture-diagrams
│   ├── sdlc-process.pdf
│   ├── vulnerability-handling-policy.pdf
│   ├── vulnerability-disclosure-policy.pdf
│   ├── update-distribution.pdf
│   └── sbom/
│       └── product-v1.2.3.cdx.json
├── 03-risk-assessment
│   ├── risk-assessment.pdf
│   └── annex-i-traceability-matrix.pdf
├── 04-support-period
│   └── support-period-justification.pdf
├── 05-standards-applied
│   └── standards-mapping.pdf
├── 06-test-reports
│   ├── static-analysis
│   ├── dependency-scan
│   ├── functional-security-tests
│   ├── penetration-test
│   └── traceability-matrix.pdf
├── 07-declaration-of-conformity
│   └── eu-declaration-of-conformity.pdf
└── 08-sbom
     └── product-v1.2.3.cdx.json

‍

Version everything. When you release a new product version, the technical file gets a new version too. Keep the old ones - retention rules apply to every version.

A note on reporting timelines. The technical file should include your reporting procedures, and it's worth knowing the deadlines differ:

Actively exploited vulnerabilities: 24h early warning, 72h detailed notification, 14 days for the final report.

Severe incidents: 24h early warning, 72h detailed notification, 1 month for the final report.

Both go to your CSIRT and ENISA through the single reporting platform. This obligation starts September 2026 - before full CRA compliance is required.

What you can start today

You don't need to wait for harmonised standards or official templates. Most of this file is built from artifacts your engineering team should already be producing - or can start producing now.

Quick wins (days, not weeks):

• Write a `security.txt` and put it on your website
• Generate an SBOM from your build system (Syft, CycloneDX CLI)
• Run a dependency scan against it (Trivy, Grype)
• Document your support period commitment

Medium effort (weeks):

• Conduct a product risk assessment using STRIDE
• Set up static analysis in CI (Cppcheck, CodeChecker)
• Document your SDLC - you probably have a process, you just haven't written it down

Larger effort (months):

• Implement firmware signing and verification if you don't have it
• Set up per-device identity and credential management
• Commission a penetration test
• Build the complete traceability matrix

Start with the quick wins. Each one fills a section of the technical file. By the time you get to the larger items, half the file is already done.

The bottom line

CRA technical documentation sounds intimidating. It's not. It's a structured collection of things you should already have - architecture docs, test results, an SBOM, a security policy. The CRA just says: put them in one place, keep them for 10 years, and be ready to show them.

The hard part isn't the documentation. It's having something worth documenting. If your product is secure by design, the technical file writes itself. If it isn't - the file is the least of your problems.

Further reading

• ‍What does CRA require that no standard covers? ‍
• What it takes to be CRA compliant
• How to categorize your product for CRA?

‍

‍