This guide explains what the CRA Declaration of Conformity is, how it fits into the wider EU product compliance framework, which elements it must contain, and how you can structure a practical DoC template for your products with digital elements. It is written for manufacturers, IoT vendors, embedded system teams and software suppliers preparing for CRA compliance.

For broader context on documentation, see our guide Cyber Resilience Act Technical Documentation: Complete Guide. For component inventory, you can also review CRA SBOM Requirements.

1. What Is the CRA Declaration of Conformity?

In EU product regulation, a Declaration of Conformity (DoC) is a legal document signed by the manufacturer stating that a specific product complies with the relevant EU legislation. Under the Cyber Resilience Act, the CRA Declaration of Conformity plays the same role for products with digital elements, focusing on cybersecurity and lifecycle security obligations.

By signing the CRA Declaration of Conformity, the manufacturer takes legal responsibility for ensuring that:

• The product meets the essential cybersecurity requirements defined in the CRA
• Appropriate conformity assessment procedures have been followed
• Technical documentation is available and supports the claim of conformity
• Security obligations will be maintained throughout the product’s lifecycle

The DoC is not a marketing document. It is a legally binding statement that can be requested by market surveillance authorities and used in enforcement actions if the product is found to be non-compliant.

2. How the CRA Declaration of Conformity Fits into EU Compliance

The CRA Declaration of Conformity does not exist in isolation. It sits alongside other elements of EU product compliance:

• Cyber Resilience Act – Establishes cybersecurity obligations for products with digital elements
• Other EU product legislation – For example, RED, EMC, LVD, machinery or medical devices regulations, where applicable
• Technical file – Holds the detailed evidence demonstrating how CRA and other requirements are met
• CE marking – The visible mark on the product or packaging signalling conformity with applicable EU acts

In many cases, you will issue a single Declaration of Conformity that lists multiple pieces of EU legislation, including the Cyber Resilience Act and any other acts relevant to your product. The CRA Declaration of Conformity section then becomes the cybersecurity-focused part of that broader DoC.

For a high-level overview of CRA obligations and how they interact with other regulations, see our article CRA Conformity Assessment: Internal Control vs Third-Party Assessment.

3. When Do You Need a CRA Declaration of Conformity?

You need a CRA Declaration of Conformity for any product with digital elements that falls under Cyber Resilience Act scope and that you, as a manufacturer, place on the EU market. Typical cases include:

• IoT devices and smart home products
• Industrial sensors, gateways and controllers
• Embedded systems and firmware-driven devices
• Software products with network connectivity distributed as part of a product

Before issuing the CRA Declaration of Conformity, the manufacturer must:

• Perform a CRA scope and applicability assessment for the product
• Classify the product (default, important or critical)
• Complete the relevant conformity assessment procedure
• Prepare a CRA technical file supporting the declaration

If a product is exclusively covered by another set of EU rules (for example, certain medical devices under MDR or automotive systems under specific type-approval regulations), CRA may not apply. In such cases, its cybersecurity obligations are covered by those sector-specific frameworks instead of a CRA Declaration of Conformity.

4. Mandatory Elements of a CRA Declaration of Conformity

While exact layout may vary, a compliant CRA Declaration of Conformity should contain at least the following elements. This structure mirrors the logic found in other EU product regulations, adapted to Cyber Resilience Act specifics.

4.1 Manufacturer identification

• Full legal name of the manufacturer
• Registered trade name or trademark (if different)
• Full postal address (including country)
• Contact details such as website or email

If an authorised representative is used in the EU, their details will also be relevant, but the manufacturer remains primarily responsible for the CRA Declaration of Conformity.

4.2 Product identification

• Product name and model
• Type, batch or serial number, or other identifying elements
• Short description of the product with digital elements (PDE)
• Version(s) of hardware and/or software covered by this DoC

Clarity here is critical. The CRA Declaration of Conformity must unambiguously identify which product and which versions are being declared compliant.

4.3 Statement of responsibility

The heart of the CRA Declaration of Conformity is a clear statement along the lines of:

“We, [manufacturer name], take full responsibility for the compliance of the product [product identification] with the requirements of the legislation listed below.”

This statement ties the manufacturer’s identity to the claims of conformity under the Cyber Resilience Act and any other referenced legislation.

4.4 List of applicable EU legislation

The DoC must specify which EU acts apply. For a CRA-focused product, this will include the Cyber Resilience Act, usually in combination with other acts depending on the product type (for example, Radio Equipment Directive, EMC Directive, etc.). A typical listing in the CRA Declaration of Conformity looks like:

• Regulation (EU) [XXX/XXXX] – Cyber Resilience Act (Cybersecurity requirements for products with digital elements)
• Directive [YYYY/YY/EU] – [Other applicable legislation, e.g. Radio Equipment Directive]

You should track the exact formal references as they appear in the Official Journal and update your template when new acts or amendments become applicable.

4.5 Reference to standards and technical specifications

To demonstrate compliance, manufacturers normally rely on harmonised standards or other recognised technical specifications. The CRA Declaration of Conformity should list the standards that have been applied, for example:

• EN ISO/IEC 27001 – Information security management systems (for selected scopes)
• EN 303 645 – Cyber security for consumer internet of things (if applicable)
• Other product or domain-specific cybersecurity standards used

Using harmonised standards aligned with the Cyber Resilience Act can provide a presumption of conformity for those aspects covered by the standard.

4.6 Reference to the technical file

The DoC should indicate that a technical file is available and can be provided to competent authorities on request. This links the high-level CRA Declaration of Conformity to the detailed evidence contained in your CRA technical file structure.

4.7 Place, date, name and signature

Finally, the DoC must include:

• Place and date of issue
• Name and function of the signatory
• Signature (and company stamp if you use one)

The signatory should be a person with appropriate authority to bind the manufacturer, such as a senior executive or the person with ultimate responsibility for product compliance.

5. Suggested Structure for a CRA Declaration of Conformity Template

Although you will adapt your layout to internal standards, the following outline provides a practical structure for a CRA Declaration of Conformity template:

• Title: EU Declaration of Conformity
• 1. Product: Identification of the product with digital elements, including type and model
• 2. Manufacturer: Legal name, address and contact details
• 3. This declaration is issued under the sole responsibility of the manufacturer
• 4. Object of the declaration: Short description of the product, purpose and main features
• 5. The object of the declaration described above is in conformity with the relevant Union legislation: List CRA and other applicable acts
• 6. References to the relevant harmonised standards and other technical specifications
• 7. Where applicable: reference to the conformity assessment procedure or notified body involvement
• 8. Additional information: links to the technical file, security support period or specific CRA-relevant notes
• Place and date of issue
• Name and function
• Signature

This template can be reused across product lines, with the CRA section adjusted for each product’s specific situation.

6. Link Between the CRA Declaration of Conformity and the Technical File

The CRA Declaration of Conformity is a summary; the technical file contains the underlying evidence. Authorities or notified bodies may request the technical documentation to verify that the claims in the DoC are justified.

In practice, this means that:

• Every standard or specification listed in the DoC should be traceable to specific sections in the technical file
• Every product version mentioned in the DoC should have a corresponding technical file or a clearly identified configuration
• Risk assessment, security controls, SBOM and testing evidence must be available and linked to the DoC claims

For detailed guidance on building a solid CRA technical file structure, see our article CRA Technical File Structure: Complete Guide.

7. Drafting a CRA Declaration of Conformity: Step-by-Step

To make the process actionable, you can approach the creation of a CRA Declaration of Conformity in these steps:

7.1 Confirm CRA scope and classification

Validate that the product is in CRA scope and confirm its classification (default, important or critical). Use your CRA applicability assessment and classification results.

7.2 Verify that the technical file is complete enough

Ensure that core technical documentation is ready: architecture, risk assessment, SBOM, security controls mapping, testing evidence, vulnerability handling and lifecycle documentation. The DoC should not be issued before these elements exist.

7.3 Identify applicable legislation

List all applicable EU acts beyond the Cyber Resilience Act, such as electromagnetic compatibility or radio equipment requirements, depending on the product. This defines the scope of your combined Declaration of Conformity.

7.4 Compile standards and technical specifications

Gather the list of harmonised standards and other technical references you rely on to demonstrate compliance with CRA security requirements and other relevant legislation.

7.5 Populate your CRA Declaration of Conformity template

Using the template structure, fill in product details, manufacturer information, legal references, standards, and the link to the technical file. Check that product identifiers match labels and documentation.

7.6 Review, sign and store

Have the DoC reviewed by your compliance or legal team, obtain the signature of an authorised person, and store the signed document in your document management system alongside the technical file. Ensure that your retention period meets CRA expectations.

8. Common Mistakes in CRA Declarations of Conformity

When organisations start issuing CRA Declarations of Conformity, they often repeat similar mistakes. Being aware of these helps you avoid rework and audit findings.

8.1 Incomplete legislation list

Listing only the Cyber Resilience Act and forgetting other applicable EU acts can create confusion. The DoC should reflect the full regulatory landscape for the product, not just CRA.

8.2 Product identification that is too vague

Using generic names or missing model identifiers makes it hard to know which exact configuration the DoC covers. Your CRA Declaration of Conformity should be precise enough to avoid ambiguity during audits or incidents.

8.3 No alignment with technical documentation

Sometimes the standards, versions or product descriptions listed in the DoC do not match the technical file or marketing materials. This lack of consistency weakens your CRA compliance posture.

8.4 Issuing the DoC before the technical file is ready

Under time pressure, teams sometimes sign the CRA Declaration of Conformity while the technical documentation is incomplete. This exposes the manufacturer to risk if authorities request evidence and find gaps.

8.5 Forgetting to update the DoC when the product changes

Significant changes in architecture, components or security posture may require an update to the technical file, renewed assessment and eventually an updated DoC. Treat the CRA Declaration of Conformity as a living document, not a one-time formality.

9. How Regulus Helps with CRA Declaration of Conformity and Documentation

Regulus is building tooling to help manufacturers, IoT vendors and embedded system teams manage Cyber Resilience Act compliance in a structured way. Instead of juggling scattered documents and spreadsheets, our goal is to provide:

• Guided workflows for CRA scope assessment and product classification
• A requirements matrix that maps Cyber Resilience Act obligations to product-specific controls
• Structured CRA technical file templates aligned with your product portfolio
• Support for documenting SBOM, vulnerability handling, updates and lifecycle commitments
• Assistance in generating consistent CRA Declaration of Conformity content from existing documentation

To get started:

1. Use our CRA Readiness Checklist to identify gaps in your CRA documentation and DoC process.
2. Review our CRA documentation resources in the Resources section.
3. Join the Regulus Early Access program to get priority access to CRA documentation workflows as they become available.

La entrada CRA Declaration of Conformity (DoC) Guide: How to Build a Compliant CRA DoC se publicó primero en Regulus.

This guide explains how to design a practical CRA technical file structure that works for manufacturers, IoT vendors, embedded system teams and software suppliers. It shows how to organise your technical documentation, what sections to include and how to connect the technical file with your risk assessment, SBOM, vulnerability handling and conformity assessment workflow.

For a broader view of CRA documentation requirements, you can also refer to our guide Cyber Resilience Act Technical Documentation: Complete Guide, and for component transparency, see CRA SBOM Requirements.

1. What Is the CRA Technical File?

Under the Cyber Resilience Act, manufacturers must prepare and keep technical documentation that demonstrates conformity of the product with digital elements to the CRA’s essential cybersecurity requirements. This set of documentation is often referred to informally as the CRA technical file.

The CRA technical file structure is not just a legal formality. It is the central place where you:

• Describe what the product is and how it is intended to be used
• Explain the architecture and components, including third party and open source software
• Document your cybersecurity risk assessment and the rationale for your controls
• Show how you meet the CRA security requirements in Annex I
• Provide evidence of testing, validation and vulnerability handling
• Record your lifecycle commitments, such as update support and end of life policy

A good CRA technical file is readable, traceable and easy to maintain. It enables a regulator, a notified body or an internal auditor to understand your product and to see how each requirement is covered without searching through fragmented spreadsheets and emails.

2. Principles for a Good CRA Technical File Structure

Before defining specific sections, it is useful to align on a few core principles that should guide your CRA technical file structure:

2.1 Traceability from risk to controls

Your technical file should link product risks to the security measures you selected. A reviewer should be able to follow the chain: threat → risk → control → evidence. This traceability is at the heart of Cyber Resilience Act compliance and will matter even more for important and critical products.

2.2 Consistency across products

If you manufacture several products with digital elements, the CRA technical file structure should be consistent across them. Reusing the same template and section layout saves time, reduces errors and makes internal reviews much easier.

2.3 Separation of product specific and reusable content

Some information is product specific (architecture diagrams, test results), while other content is reusable (corporate secure development lifecycle, generic vulnerability handling process). A good CRA technical file structure reuses global policies where possible and adds product specific annexes instead of duplicating everything.

2.4 Up to date and lifecycle oriented

The CRA technical file is not a one time snapshot. It must be maintained as the product evolves: new versions, new features, security patches, changes in components. Your structure should make it easy to track versions and to keep documentation aligned with the actual product.

3. Recommended CRA Technical File Structure

There is no single mandatory format, but most organisations converge on a similar CRA technical file structure. Below is a recommended layout that aligns with the Cyber Resilience Act and can be adapted to your internal tools (DMS, wiki, GRC platform or a specialised CRA documentation tool such as Regulus).

3.1 Section 1 – Product overview and identification

The first part of your CRA technical file structure should introduce the product clearly:

• Product name and model(s)
• Version(s) covered by this technical file
• Intended purpose and use cases
• Target users or environments (consumer, enterprise, industrial, etc.)
• Regions and markets (EU, specific Member States)
• High level description of main features

This section anchors the technical file and provides context for the rest of the documentation. It should also clarify if the product is a complete system, a component, a software module or a combination of hardware and software.

3.2 Section 2 – Roles and CRA applicability summary

In this section, you summarise your CRA applicability and role analysis:

• Whether the product is in scope as a product with digital elements
• CRA product category (default, important or critical) and justification
• Economic operator role(s) assumed by your organisation (manufacturer, importer, distributor)
• Any relevant sector specific frameworks that modify or complement CRA (e.g. MDR, automotive regulations)

Here it is useful to reference internal analysis based on our article Cyber Resilience Act Applicability: Does the CRA Apply to Your Product? and CRA Scope: What Products Are In and Out.

3.3 Section 3 – System architecture and data flows

This part of the CRA technical file structure explains how the product is built and how it interacts with other systems:

• Logical architecture diagrams (components, modules, services)
• Network architecture and trust boundaries
• Data flow diagrams (what data moves where, and under which protection)
• Interfaces exposed (APIs, management ports, protocols)

Architecture and data flow diagrams are critical for understanding attack surfaces, responsibilities and where specific CRA security requirements are implemented.

3.4 Section 4 – Cybersecurity risk assessment

The CRA requires manufacturers to carry out a cybersecurity risk assessment as part of the design and development process. This section:

• Describes the methodology used (e.g. threat modelling, STRIDE, attack trees, IEC 62443 inspired)
• Lists threats and scenarios relevant to the product
• Identifies assets, potential impacts and likelihood
• Prioritises risks and links them to the security controls applied

If you already follow a structured approach to risk under NIS2 or ISO 27001, you can reuse parts of that framework here, but the analysis must focus on the specific product with digital elements. For a conceptual overview of risk work under CRA, see our CRA Risk Assessment Guide.

3.5 Section 5 – Mapping to CRA security requirements

One of the key elements of a CRA technical file structure is a clear mapping between the product and the CRA essential security requirements. A typical way to present this is a requirements matrix that:

• Lists the CRA security requirements (for example, secure by default, access control, logging, update mechanisms)
• Describes how each requirement is implemented in the product
• References specific design documents, code modules or configuration standards
• Links to test cases and evidence showing that the requirement is effectively met

In Regulus, this mapping is part of the Requirements Matrix module, which helps you move from abstract CRA text to concrete, product specific obligations.

3.6 Section 6 – Software Bill of Materials (SBOM) and components

Because the CRA expects manufacturers to maintain an inventory of software components, the technical file should include or reference an up to date SBOM:

• List of all relevant software components and libraries
• Version and supplier for each component
• Open source and third party identifiers (e.g. package names, repositories)
• Licensing information when relevant to security and support

The SBOM section of your CRA technical file structure should also explain how the SBOM is generated, maintained and used for vulnerability correlation. For more depth on expectations, see CRA SBOM Requirements.

3.7 Section 7 – Secure development lifecycle (SDL)

This section documents how the product is built securely over time:

• Overview of your secure development lifecycle (SDL) or equivalent framework
• Security activities per phase: design reviews, threat modelling, secure coding guidelines, code review, SAST/DAST, dependency scanning
• Roles and responsibilities (product security champions, security reviewers)
• Integration of security in CI/CD pipelines

You can reference a corporate SDL policy and then include product specific details in this technical file. When you later create a dedicated article on Secure Development Lifecycle under the CRA, you can link to it from this section.

3.8 Section 8 – Security testing and validation evidence

Regulators and notified bodies will expect to see evidence that security controls have been tested. This section of the CRA technical file structure typically contains:

• Security test strategy and scope
• Results of functional security tests
• Results of fuzzing, penetration testing or red teaming where applicable
• Dependency scanning and vulnerability scanning reports
• Fix tracking for critical findings before product release

It is good practice to summarise conclusions in a short security validation report and attach detailed reports as annexes.

3.9 Section 9 – Vulnerability handling process and CVD

The CRA explicitly requires a structured vulnerability handling process. This part of your technical file should:

• Describe how vulnerabilities are reported, triaged and prioritised
• Explain your Coordinated Vulnerability Disclosure (CVD) policy
• Identify your public contact channels for vulnerability reporting
• Document timelines and SLAs for addressing vulnerabilities
• Show how you document and communicate resolved vulnerabilities

For a detailed breakdown of what this entails, see CRA Vulnerability Handling Requirements (Annex I – Section 2).

3.10 Section 10 – Update and patch management

This section of the CRA technical file structure explains how the product receives updates:

• Update architecture (over the air, local updates, staged rollouts)
• How update packages are signed, validated and applied securely
• Segregation between security updates and feature updates where possible
• Notification mechanisms to inform users about security updates
• Support period and end of security updates for each version

Update and patch management are central to ongoing Cyber Resilience Act compliance. They connect your design assumptions to real world operations and incident exposure.

3.11 Section 11 – Post-market monitoring and incident handling

Post-market monitoring is how you detect problems once the product is in use. This section should cover:

• How you collect signals about security issues (logs, telemetry, customer reports)
• How you track and investigate incidents affecting the product
• How you coordinate CRA related incident notifications where required
• How you feed lessons learned back into risk assessment and product improvement

3.12 Section 12 – Lifecycle, support and end-of-life

The CRA is explicit about lifecycle security. In this part of your technical file, document:

• Planned lifetime of the product versions covered
• Period during which you commit to provide security updates
• End-of-life policy and communication to customers
• Migration or replacement recommendations when security support ends

3.13 Section 13 – EU Declaration of Conformity (DoC) and references

Finally, your CRA technical file structure should point to your EU Declaration of Conformity and any other declarations or certificates (for example, under other EU product regulations or cybersecurity certification schemes). It is common to:

• Include a copy of the DoC as an annex
• Reference harmonised standards or specifications you rely on
• List relevant certificates and assessment reports from notified bodies

4. How the CRA Technical File Fits into Your Compliance Workflow

The CRA technical file is not an isolated document; it sits at the intersection of product development, security and regulatory compliance. In a mature workflow:

• Product managers use it to understand constraints and obligations
• Engineering teams contribute architecture, code level and testing details
• Security teams contribute risk assessments, SBOMs and vulnerability handling evidence
• Compliance teams coordinate structure, versioning and conformity assessment outputs

Ideally, your CRA technical file structure mirrors the way your teams work. If you try to maintain it only as a static PDF, it will quickly become outdated. Many organisations choose to manage the technical file in a documentation system, GRC tool or a specialised CRA platform such as Regulus.

5. Common Mistakes in CRA Technical File Structure

When organisations start building CRA technical documentation, they often make similar mistakes. Typical issues include:

5.1 Mixing policy and product detail without structure

Global security policies and product specific implementations are mixed together in an unstructured way, making it difficult for reviewers to understand what applies to which product. A clearer CRA technical file structure separates global policies from product level details and links them instead of merging everything into one document.

5.2 No clear mapping to CRA requirements

Technical documentation often describes many security features but fails to explicitly show how each CRA requirement is covered. A requirements matrix or mapping table is essential to make Cyber Resilience Act compliance visible and auditable.

5.3 SBOMs not integrated into the technical file

Some teams generate SBOMs as standalone artefacts but never integrate them into the CRA technical file. The result is a gap between component inventory and other documentation. In a robust CRA technical file structure, the SBOM is referenced, explained and linked to vulnerability handling and testing processes.

5.4 Documentation created too late

Teams wait until just before release to start the technical file, which leads to guesswork and missing evidence. The CRA technical file should evolve together with the product, starting from architecture and risk assessment through to validation and post-market monitoring.

6. How Regulus Helps You Build a CRA Technical File Structure

Regulus is designed to make Cyber Resilience Act compliance more manageable for manufacturers of IoT devices, embedded systems, firmware based products and other connected solutions. Instead of maintaining a patchwork of spreadsheets and documents, Regulus provides:

• A structured CRA requirements matrix aligned with your product profile
• Guided workflows for CRA scope and applicability
• Support for documenting your CRA technical file structure in a consistent way
• Templates for risk assessment, SBOM, vulnerability handling and update management documentation
• Roadmap views that connect documentation work with 2025–2027 CRA timelines

If you are starting to design your CRA technical file structure and want to avoid reinventing everything from scratch, you can:

1. Download our CRA Readiness Checklist to identify your main gaps.
2. Review our documentation focused guides in the Resources section.
3. Join the Regulus Early Access program to get priority access to CRA documentation workflows.

La entrada CRA Technical File Structure: Complete Guide for Cyber Resilience Act Compliance se publicó primero en Regulus.

This guide explains in detail what the CRA requires under Annex II (technical documentation for conformity) and Annex VII (post-market documentation and vulnerability handling records). Most companies underestimate the scale and depth of this obligation. This document covers everything you must prepare before 2027 to avoid market disruption, non-compliance penalties and product recalls.

For templates and checklists, see our CRA Readiness Checklist.

1. What Is CRA Technical Documentation?

Under the Cyber Resilience Act, Technical Documentation is the complete package of evidence, security controls, lifecycle processes and product information required to demonstrate conformity with the Essential Cybersecurity Requirements in Annex I. It must:

• Be created before placing the product on the market
• Be kept updated throughout the lifecycle of the product
• Be available to authorities upon request
• Include design, implementation, testing, and vulnerability handling evidence
• Be sufficient for authorities or notified bodies to assess conformity

Failure to produce this documentation can prevent a product from being sold in the EU, even if it meets all technical requirements.

2. Why CRA Technical Documentation Matters

The CRA is designed to eliminate inconsistent and insufficient cybersecurity documentation across the EU. Historically, manufacturers submitted uneven evidence, lacked security lifecycle records, or kept undocumented processes. Under CRA, documentation plays three critical roles:

• Demonstrates compliance with Annex I requirements
• Enables audits and investigations by market surveillance authorities
• Supports vulnerability management and incident reporting

Authorities consider documentation to be the foundation of cybersecurity assurance. Inadequate documentation can itself be a violation.

3. What Documentation Is Required Under Annex II?

Annex II defines the core Technical Documentation for conformity assessment. Manufacturers must produce a complete set of documents describing how the product meets the Essential Cybersecurity Requirements.

The documentation must include:

3.1 Product Description and Intended Use

• Product type, model, version
• Intended use cases and operational environment
• Connectivity features (wired, wireless, protocols)
• Dependencies on cloud services or external systems

3.2 Architecture and System Design

• High-level software architecture
• Module breakdown
• Firmware architecture
• Network architecture diagrams
• Data flow diagrams (DFDs)
• Third-party components and open-source libraries

3.3 Security Controls and Annex I Requirements Mapping

Manufacturers must demonstrate how each cybersecurity requirement in Annex I is fulfilled, including:

• Secure boot and integrity mechanisms
• Authentication and authorization controls
• Protection against injection, memory corruption and exploitation
• Network security measures
• Security of update mechanisms
• Cryptographic functions
• Secure storage of sensitive data

A full requirements matrix is recommended: See CRA Requirements Mapping.

3.4 Update and Patch Management Documentation

• Software update architecture
• Firmware update mechanisms
• Secure update validation (signing, authenticity, rollback prevention)
• Lifecycle support policy (how long updates are guaranteed)

3.5 Vulnerability Handling Documentation

• Internal vulnerability intake process
• Assessment and prioritization methods
• Remediation workflows and timelines
• Incident reporting to authorities (within mandated deadlines)

3.6 Testing and Validation Evidence

Manufacturers must provide proof of security testing:

• Penetration testing summaries
• Static and dynamic code analysis results
• Fuzzing results (if applicable)
• Third-party testing (if used)

3.7 SBOM (Software Bill of Materials)

The SBOM is mandatory for products containing software. It must include:

• Component name, version, supplier
• Known vulnerabilities
• Licensing information
• Dependency relationships

4. What Documentation Is Required Under Annex VII?

Annex VII focuses on post-market monitoring and vulnerability handling documentation.

This covers all evidence a manufacturer accumulates after the product is placed on the market, including security updates and incident reporting records.

4.1 Post-Market Monitoring Plan

• Security monitoring strategy
• Sources of threat intelligence
• Automated monitoring tools and manual processes
• How security alerts are prioritized

4.2 Vulnerability Database / Register

• List of vulnerabilities discovered post-release
• Discovery date, reporting date, remediation date
• Impact assessment
• Interaction with ENISA or CSIRTs (if required)

4.3 Incident Reporting Documentation

For exploited vulnerabilities or severe cybersecurity incidents, manufacturers must keep:

• Incident timeline
• Evidence of exploitation
• Mitigation actions performed
• Notices sent to authorities
• User notifications (if applicable)

4.4 Update & Patch History

• Version history of firmware/software
• Security patches released
• Reason for updates
• Validation steps performed

5. CRA Technical Documentation Checklist

This checklist summarizes the full scope:

• Product description and intended use
• Architecture diagrams
• Security design documents
• Annex I requirements mapping
• Threat modelling (recommended)
• Update and patch management plan
• Secure development lifecycle documentation
• Vulnerability handling processes
• Security testing evidence
• SBOM with full dependency mapping
• Risk assessment report
• Conformity assessment documentation
• Post-market monitoring plan (Annex VII)
• Incident report logs
• Update history and remediation records

Download the full templates here: Cyber Resilience Act Resources

6. Who Must Produce Technical Documentation?

Technical documentation is required from all manufacturers of CRA-regulated products. However, importers and distributors also have obligations:

6.1 Manufacturers

They must create and maintain the full documentation package.

6.2 Importers

Must verify the existence and completeness of the documentation before placing the product on the EU market.

6.3 Distributors

Must ensure no known non-compliance exists and must cooperate with authorities.

7. The Difference Between Default Class and Critical Class Documentation

Both classes require full Annex II documentation, but Critical Class products require additional scrutiny:

• Stricter conformity assessment
• Possible third-party evaluation
• More detailed evidence for security controls
• Longer retention of post-market documentation

Critical Class includes:

• Security products
• Routers, gateways, connectivity infrastructure
• Industrial systems supporting essential services

For classification rules, see: CRA Applicability & Classification Guide.

8. How to Structure Your CRA Documentation (Recommended Template)

The following structure is commonly used in conformity assessment under other EU frameworks (e.g., RED, MDR, Machinery Regulation). It adapts perfectly to CRA:

Part 1 — Product Overview

Part 2 — Engineering Documentation

Part 3 — Cybersecurity Requirements Mapping

Part 4 — Secure Development Lifecycle

Part 5 — Testing & Validation Summary

Part 6 — Conformity Assessment Evidence

Part 7 — Post-Market Monitoring Plan

Part 8 — Annexes (SBOM, test logs, vulnerability registers)

9. Common Mistakes Companies Make When Preparing Documentation

• Starting documentation too late
• Not mapping Annex I requirements explicitly
• No SBOM or incomplete SBOM
• Lack of vulnerability handling procedures
• No evidence of secure update validation
• Overlooking third-party components and supply-chain security
• No post-market monitoring strategy
• No logging of security testing results

These gaps are among the most common causes of non-compliance findings.

10. Should You Automate CRA Technical Documentation?

Most manufacturers will struggle to maintain documentation manually. Automated CRA documentation tools — such as Regulus — solve three key problems:

• Mapping Annex I requirements correctly
• Keeping documentation updated during the lifecycle
• Linking vulnerabilities, updates and evidence in one place

Try a starter automation here: CRA Applicability Checker

11. External Resources

• European Commission – CRA Announcement
• ENISA – EU Cybersecurity Agency
• NIST Secure Software Development Framework

Conclusion

Technical Documentation is one of the most significant obligations introduced by the CRA. It requires continuous security evidence, lifecycle monitoring, vulnerability management and explicit mapping of cybersecurity requirements.

Companies that begin preparing early will be better positioned for compliance, market access and product reliability in the 2025–2027 window.

Explore templates and checklists here: Cyber Resilience Act Resources

Technical documentation is a core component of Cyber Resilience Act compliance. To see how it fits with scope, SDL, SBOM and deadlines, review our CRA compliance roadmap.

La entrada CRA Technical Documentation (Annex II & VII): Complete Guide for Manufacturers, Software Teams and IoT Vendors se publicó primero en Regulus.