CRA Technical Documentation: The Complete Checklist for Manufacturers

Photo by George Diama on Unsplash

Your product connects to the internet. It ships to EU customers. Under Regulation (EU) 2024/2847, that means assembling a CRA Technical Documentation package before it hits the market — one that proves your product was built securely, that its vulnerabilities get handled, and that someone accountable will still be patching it years from now.

Market surveillance authorities can request this file at any time. If you can’t produce it, the product comes off the shelf. CE marking denied. Fines up to €15 million or 2.5% of global annual turnover — whichever is higher.

Full compliance deadline: December 11, 2027. The first hard deadline — Article 14 vulnerability reporting — hits September 11, 2026. That’s 16 months from now.

At CRA Decoded, we’ve mapped Annex VII against the documentation most engineering teams already have. The gap is almost always the same: risk assessment and SBOM retention process, not product description. This article covers both and everything else Annex VII requires.

What “Technical Documentation” Actually Means Under the CRA

Not a single document. A structured evidence file — the audit trail your entire product security lifecycle needs to produce.

The legal basis is Article 31: documentation must contain all information demonstrating that the product and the manufacturer’s processes comply with the essential cybersecurity requirements in Annex I. The detailed contents are enumerated in Annex VII.

Annex VII has five sections:

1. Product description and architecture
2. Design, development, production, and vulnerability handling processes
3. Cybersecurity risk assessment
4. Support period rationale
5. Test reports and conformity evidence

Each section needs traceable, dated artifacts. “We follow best practices” is not an artifact.

Section 1: Product Description and Architecture

Annex VII §1 requires a general product description: intended use, product version, hardware photos or illustrations if applicable, and — critically — a system architecture description explaining how software components build on or feed into each other and integrate into the overall processing.

In practice:

• A component diagram showing all software layers (firmware, OS, middleware, application, libraries)
• Identified network interfaces and communication protocols
• Data flow diagrams covering authentication, update channels, and logging paths
• For hardware: labeled photographs of internal layout and external markings

If your product is integrated into someone else’s product with digital elements, the architecture documentation also needs to provide the integrator with enough information to meet their own CRA obligations. This matters if you ship modules, SDKs, or embedded components — your downstream customers become responsible for what you don’t document.

Products falling under Annex III (Important) or Annex IV (Critical) will have their architecture description scrutinized more closely. Notified Bodies use this diagram as their entry point into the technical file.

Section 2: Design, Development, and Vulnerability Handling Processes

The most operationally demanding section. Annex VII §2 requires documentation of:

• How the product was designed and developed (secure development lifecycle evidence)
• Vulnerability handling processes, including the Software Bill of Materials (SBOM)
• Your Coordinated Vulnerability Disclosure (CVD) policy
• Evidence of a contact address for vulnerability reporting
• A description of secure update distribution

The SBOM Requirement

Photo by Harshit Katiyar on Unsplash

SBOMs are mandatory for every product containing software. The SBOM requirement catches teams off guard more than anything else in Annex VII — not because it’s hard to generate one, but because the CRA requires it to be current, versioned, and stored for up to a decade. The CRA doesn’t specify a format, but **BSI TR-03183–2** (v2.1.0, August 2025) — Germany’s BSI technical guideline and currently the most detailed public interpretation of CRA SBOM requirements in the EU — requires:

• Machine-readable format: CycloneDX or SPDX (JSON or XML only, no YAML)
• Transitive dependency coverage, not just direct dependencies
• Recursive dependency resolution for every component in the delivery scope

Syft for a container image:

syft scan my-product:1.4.2 -o cyclonedx-json=sbom-1.4.2.cdx.json

Syft for a directory (firmware build output):

syft scan dir:/build/output -o spdx-json=sbom-1.4.2.spdx.json

Syft and Trivy handle direct and first-level transitive dependencies well. Deep transitive resolution for interpreted languages (Python, Ruby, Node.js) needs package-manager-specific analysis. For Python:

cdxgen -t python --output sbom.cdx.json .

Check quality against BSI TR-03183–2:

sbomqs score sbom-1.4.2.cdx.json --profile bsi-v2.0

BSI TR-03183–2 also requires version-controlled storage of SBOMs and a process for updating SBOMs with each release. If your CI/CD pipeline doesn’t generate a new SBOM on every tagged build, that’s a process gap — and it will show up in your technical documentation.

Coordinated Vulnerability Disclosure Policy

The CVD policy must be publicly accessible and cover how you receive reports, triage them, define your response timeline commitments, and notify users when patches are available. A security.txt at /.well-known/security.txt is the baseline:

Contact: mailto:security@your-company.com
Policy: https://your-company.com/security-policy
Preferred-Languages: en, de, fr

The policy document itself needs explicit timelines. Most teams reference ISO/IEC 29147 as their framework — auditors recognize it, and it saves you from inventing your own structure.

Secure Development Lifecycle Evidence

The CRA doesn’t mandate a specific SDL framework. What it requires is documented evidence that security was considered at the design stage, not just tested after the fact. Acceptable evidence:

• Threat model documents (STRIDE, PASTA, or DREAD-based) linked to architecture diagrams
• Security requirements in your product backlog or design specs
• SAST, DAST, fuzzing, and SCA results with tool names, versions, scan dates, and findings
• Penetration test reports, if conducted
• Code review records covering security-relevant changes

The European Commission published draft guidance in March 2026 clarifying the interpretation of several Annex I requirements. Not yet finalized, but the direction is clear: security review must be a distinct, documented step in the development process — not incidental to general QA.

Section 3: The Cybersecurity Risk Assessment

Article 13(2) requires a cybersecurity risk assessment. Article 13(4) requires it to be included in the Technical Documentation at the time of market placement.

This cannot be done retroactively. If the risk assessment doesn’t exist before the product ships, the product is non-compliant on day one.

The CRA doesn’t mandate a specific methodology. STRIDE for threat modeling combined with CVSS for severity scoring is a defensible combination. The assessment must:

• Identify relevant threats and attack surfaces
• Map threats to the essential requirements in Annex I, Part I
• Explain how each requirement is implemented, or justify why it doesn’t apply
• Be updated when the product changes substantially

If an Annex I requirement genuinely doesn’t apply to your product, you still can’t skip it — write a justification explaining why. Silence fails the audit.

There’s a meaningful difference between a risk assessment that says “we use TLS everywhere, authenticated updates, and no default passwords” and one that says “we assessed threats T1 through T14 using STRIDE, scored them with CVSS 3.1, and mapped mitigations to Annex I Part I points (1) through (13).” Auditors know the difference, too.

One gap to flag: harmonized standards for this process are still being developed. The Commission issued a standardization request to CEN/CENELEC and ETSI in February 2025 — the EN 40000 series is the target output. Until those ships, you’re self-certifying against the regulation text directly. BSI TR-03183–1 and ETSI EN 303 645 (consumer IoT) are the closest usable references right now.

Section 4: Support Period Documentation

Article 13(8) requires manufacturers to determine a support period “appropriate to the type of product.” The determination and the factors behind it must be documented in the technical file.

Five years is the practical floor for most products — based on recital language and the requirement that security updates remain available for at least 10 years after release (or the remainder of the support period, whichever is longer — Article 13(9)).

The documentation needs to cover:

• Declared end-of-support date per product version
• Update delivery mechanism (OTA, manual download, CDN)
• Commitment to security-only update availability for the full period
• How users are notified when support ends

For IoT and embedded products with long field lifetimes, this is where the CRA hits hardest. If customers keep your device for 10–15 years, but your support window has historically been 3 years, no documentation template fixes that. It’s a product architecture and commercial model decision that has to be made before launch, not after.

Section 5: Test Reports and Conformity Evidence

Annex VII §5 requires test reports or other evidence demonstrating conformity with the essential requirements. What that looks like depends on your product classification.

Default Category: Self-Assessment Under Module A

Products not listed in Annex III or Annex IV qualify for Module A self-assessment. You write the test reports yourself, retain them, and draw up the EU Declaration of Conformity in the Annex V format. No third party involved.

Module A still requires actual test evidence. A checklist without underlying test artifacts won’t survive a market surveillance inspection.

Important Class I Products: When a Notified Body Gets Involved

Operating systems, browsers, VPN clients, network management systems, identity management systems, smart home security devices, routers, switches. These require either conformity assessment against harmonized standards (when available) or third-party assessment by a Notified Body — Module B + C, or Module H.

Member States must designate Notified Bodies by June 11, 2026. Until the designation occurs, the third-party assessment can’t proceed formally. If your product is an Important Class I, start the documentation now and identify potential Notified Bodies early — engagement takes time.

Important Class II and Critical Products

Firewalls, hypervisors, intrusion detection systems (Class II). Smart meter gateways, hardware security modules (Critical/Annex IV). Notified Body involvement is required. No alternatives.

EU Declaration of Conformity: What Goes in It and When to Update

Separate from the technical documentation file. Structure defined in Annex V of the CRA. It must contain:

• Product name, type, batch, and serial number
• Manufacturer name and address
• Statement that the product meets essential requirements
• References to harmonized standards or common specifications used, if applicable
• Date and signature of authorized representative

Update the DoC whenever the product changes substantially. It travels with the product — or is made available digitally — and points back to the technical documentation file.

Annex VI provides a simplified DoC format for cases where the product itself doesn’t have room for the full version. A URL to the complete document suffices.

Retention: 10 Years or the Support Period

Photo by Yuriy Vertikov on Unsplash

Article 13(13) is unambiguous: technical documentation and the EU Declaration of Conformity must remain available to market surveillance authorities for at least 10 years after market placement, or for the support period — whichever is longer.

Five-year support period: 10-year retention obligation. Twelve-year support period: 12-year retention obligation.

Your S3 bucket or Confluence space from 2027 needs to still exist and be searchable in 2037. SBOM files, test reports, and risk assessment documents are compliance artifacts — not ephemeral build outputs. Treat them accordingly from day one:

# Tag and archive SBOM artifacts at release time
git tag -a v1.4.2 -m "Release 1.4.2"
aws s3 cp sbom-1.4.2.cdx.json s3://compliance-artifacts/sbom/ --storage-class GLACIER_IR

Set up the S3 lifecycle policy and tagging convention on day one of the project, not the week before launch.

What the Technical Documentation File Looks Like in Practice

Annex VII doesn’t mandate a folder structure — it mandates content. How you organize it is your call. That said, mapping folders directly to Annex VII sections has one practical advantage: when a market surveillance authority or Notified Body asks “where’s the risk assessment?”, the answer is 04-risk-assessment/, not "somewhere in Confluence, let me check."

Some teams keep SAST reports in their CI system and reference them by URL in the README. That works — as long as the URL resolves in 2037.

technical-documentation/
├── README.md                        # Document index with version history
├── 01-product-description/
│   ├── product-overview.md          # Intended use, versions, scope
│   ├── architecture-diagram.drawio  # System architecture
│   └── interface-specification.md   # Network interfaces, protocols
├── 02-sdl-evidence/
│   ├── threat-model-v1.2.md         # STRIDE threat model
│   ├── sast-report-2027-01.html     # Semgrep/Checkmarx results
│   ├── dast-report-2027-01.html     # OWASP ZAP results
│   ├── pentest-report-2026-Q4.pdf   # Penetration test
│   └── sbom-1.4.2.cdx.json         # CycloneDX SBOM
├── 03-vulnerability-handling/
│   ├── cvd-policy.md                # Coordinated Vulnerability Disclosure
│   ├── vulnerability-register.csv   # Active and resolved vulnerabilities
│   └── update-mechanism.md          # OTA process description
├── 04-risk-assessment/
│   ├── risk-assessment-v1.0.md      # Threats, mitigations, Annex I mapping
│   └── annex-i-compliance-matrix.md # Requirement-by-requirement mapping
├── 05-support-period/
│   └── support-period-rationale.md  # Declared period, update commitments
├── 06-test-reports/
│   ├── functional-security-test.md  # Internal test results
│   └── review-records.md            # Security review log
└── 07-conformity/
    ├── eu-declaration-of-conformity.pdf
    └── ce-marking-rationale.md

The README.md at the root is the first thing auditors open. Include a version history table, the product name and version the documentation covers, and a one-line status per folder: complete, in progress, or not applicable, with justification. That alone saves hours during an inspection.

CRA Standards Still in Development: What’s Not Settled Yet

Two things worth flagging before you build processes around them:

Harmonized standards are not yet published. The EN 40000 series from CEN/CENELEC will eventually give products a presumption of conformity with Annex I — but timelines remain open. Until then, self-certification against the regulation text is the only route, with BSI TR-03183 and ETSI EN 303 645 as non-binding references.

Article 14 reporting runs through ENISA’s Single Reporting Platform, which is still in development as of publication. The workflow you build now needs room to adapt. Watch the ENISA EUVD portal for updates on when the platform goes live and what format it accepts.

CRA Technical Documentation: Where to Start This Week

Run a gap analysis against Annex VII. Map your existing documentation — architecture docs, test reports, security policies — to each of the five sections. Gaps are what you need to build.

Generate and archive your first SBOM. Integrate Syft or cdxgen into your CI/CD pipeline on at least one product line. A CycloneDX JSON artifact on every tagged release, archived immediately. Takes less than a day to set up.

Start your risk assessment. Use STRIDE against your architecture diagram, score with CVSS 3.1, and map mitigations to Annex I Part I. A Google Doc with the right content beats a sophisticated tool with no output.

The December 2027 deadline looks manageable. September 2026 does not. Getting your CRA technical documentation right the first time saves rework closer to the deadline — and gives you a defensible file if market surveillance knocks. Start now.

Subscribe to CRA Decoded

Receive weekly technical guides on EU Cyber Resilience Act compliance directly in your inbox.

You will receive:

• Comprehensive implementation guides, including SBOM, vulnerability management, and CE marking.
• Updates on CRA regulations from ENISA and the European Commission.
• Tool reviews and practical recommendations.
• Actionable checklists and templates.

👉 Subscribe here

Free. Published every Sunday. Unsubscribe at any time.

About CRA Decoded

An independent engineering publication that translates EU cybersecurity regulations into practical guides for software teams.

📧 Newsletter: cradecoded.substack.com

🌐 Website: cra-decoded.com

✉️ Contact: contact@cra-decoded.com