# CRA Technical Documentation: [Product with digital elements] [version]

> Technical documentation file and EU declaration of conformity for a
> product with digital elements under the EU Cyber Resilience Act
> (Regulation (EU) 2024/2847). Sections 1 to 3 and 5 to 8 cover Annex VII
> points 1 to 6 and 8, and section 10 covers point 7 (the declaration);
> section 3 holds the cybersecurity risk assessment of Article 13;
> section 4 is the checklist of the essential cybersecurity
> requirements of Annex I Parts I and II; section 9 records the conformity
> assessment procedure of Article 32; section 10 is the EU declaration of
> conformity with the content of Annex V. The main obligations apply from
> 11 December 2027 (Article 71); reporting under Article 14 already applies
> from 11 September 2026. Check the consolidated text on EUR-Lex for the
> dates and wording that apply to you.
> Replace every `[bracketed]` value and every row marked *Example*.
> This is a documentation format, not legal advice.

<!--
Guidance: How to use this template
- Confirm that the product is in scope and determine its category first
  (section 1.3): default, important class I or class II (Annex III), or
  critical (Annex IV). The category decides the conformity assessment
  procedure in section 9.
- The file must exist before the product is placed on the market and be
  kept up to date at least during the support period (Article 31(2)).
- Link controlled, versioned evidence rather than copying it: risk
  register, test reports, SBOM, vulnerability handling procedure.
- If the product is also subject to other Union law with its own
  technical documentation (for example the AI Act or the Radio Equipment
  Directive), keep one combined file (Article 31(3)) and add the other
  headings as appendices.
- Write the file in a language acceptable to the notified body when a
  third-party procedure is used (Article 31(4)).
- Read the Regulation itself for binding wording; this template only
  summarises the provisions in its own words.
-->

## Document control

<!-- Guidance: An authority must be able to tell which product version this file describes, who the manufacturer is and where the signed declaration is kept. -->

| Field | Value |
|---|---|
| Document ID | [TD-CRA-001] |
| Product name, type and version | [Name] [type] [version] |
| Unique identification | [Type, batch or serial number, or other identifying element (Article 13(15))] |
| Manufacturer | [Legal name, registered trade name or trademark, postal address, email] |
| Authorised representative (if appointed) | [Name, address, mandate reference] |
| Product category | [Default / Important class I / Important class II / Critical] |
| Conformity assessment procedure | [Module A / Modules B and C / Module H / European cybersecurity certification scheme] |
| Notified body (if any) | [Name, number] |
| Support period end | [Month and year] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@product-compliance-owner] |
| Approvers / reviewers | [@product-security-lead], [@quality-manager], [@legal-regulatory] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] |
| Retention | At least 10 years after placing on the market or for the support period, whichever is longer (Article 13(13)) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Product security lead | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Head of engineering | [@name] | [Decision] | YYYY-MM-DD |
| Quality manager | [@name] | [Decision] | YYYY-MM-DD |
| Legal and regulatory affairs | [@name] | [Decision] | YYYY-MM-DD |
| Person signing the declaration | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Every change that affects compliance creates a revision. Record whether a change is a substantial modification, which can trigger a new conformity assessment. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Baseline for conformity assessment of firmware 4.0 |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Risk assessment updated after vulnerability VH-2027-008; not a substantial modification |

## Contents

<!-- Guidance: Sections 1 to 3 match Annex VII points 1 to 3, section 4 is the Annex I checklist, and sections 5 to 8 match points 4, 5, 6 and 8. Section 10 holds the declaration (point 7); sections 9, 11 and 12 hold the assessment route, retention and appendices. -->

1. [General description of the product](#1-general-description-of-the-product)
2. [Design, development, production and vulnerability handling](#2-design-development-production-and-vulnerability-handling)
3. [Cybersecurity risk assessment](#3-cybersecurity-risk-assessment)
4. [Essential cybersecurity requirements checklist](#4-essential-cybersecurity-requirements-checklist)
5. [Support period determination](#5-support-period-determination)
6. [Harmonised standards, common specifications and certification](#6-harmonised-standards-common-specifications-and-certification)
7. [Test reports](#7-test-reports)
8. [Software bill of materials](#8-software-bill-of-materials)
9. [Conformity assessment procedure](#9-conformity-assessment-procedure)
10. [EU declaration of conformity](#10-eu-declaration-of-conformity)
11. [Retention and updates of this file](#11-retention-and-updates-of-this-file)
12. [Appendices](#12-appendices)

## 1. General description of the product

<!-- Guidance: Annex VII point 1. Describe the product so that an assessor understands what it does, how it is delivered and which software versions affect compliance. Pitfall: forgetting the remote data processing solution (cloud backend) that is part of the product. -->

### 1.1 Intended purpose

[State the intended purpose, the users and the operating environment.
Example: "A home and small-office Wi-Fi router that connects up to 64
devices to the internet, managed through a local web interface and an
optional mobile app with a cloud companion service. Intended for
consumers and small businesses."]

### 1.2 Identification and versions

| Item | Value |
|---|---|
| Product name and type | *Example:* [Router X200], wireless router |
| Hardware revisions | *Example:* Rev. B and Rev. C |
| Software versions affecting compliance | *Example:* Firmware 4.0.x; mobile app 2.x; cloud companion API v3 |
| Remote data processing solutions | *Example:* Cloud companion service for remote management and update delivery |
| Forms of supply | *Example:* Retail box; operator-branded variant (same firmware) |
| Photographs or illustrations (hardware) | [Link to images showing external features, marking and internal layout] |
| Information and instructions to the user (Annex II) | [Document reference and URL] |

### 1.3 Scope and category

| Question | Answer |
|---|---|
| Product with digital elements in scope (Article 2) | *Example:* Yes: hardware with software, data connection to a network |
| Excluded by sector legislation | *Example:* No: not a medical device, vehicle, aircraft or marine equipment |
| Core functionality matches an Annex III category | *Example:* Yes: routers and modems intended for connection to the internet (class I) |
| Core functionality matches an Annex IV category | *Example:* No |
| Technical description checked | [Reference to the Commission implementing act under Article 7(4) giving technical descriptions of the categories, and the clause relied on] |
| Resulting category | *Example:* Important product, class I |

### 1.4 User information summary (Annex II)

| Annex II item | Where provided |
|---|---|
| Manufacturer name and contact | *Example:* Label, quick start guide, website |
| Single point of contact for vulnerabilities and CVD policy location | *Example:* Quick start guide, `security.txt`, admin UI About page |
| Unique identification | *Example:* Label, admin UI |
| Intended purpose, security environment, essential functions and security properties | *Example:* User manual chapter 1 |
| Foreseeable circumstances leading to significant cybersecurity risks | *Example:* User manual chapter 9 |
| Address of the EU declaration of conformity | *Example:* Product page URL |
| Type of security support and end date of support period | *Example:* Box, product page, admin UI |
| Secure commissioning, effect of changes, installing updates, decommissioning and data removal, turning off automatic updates, information for integrators | *Example:* User manual chapters 2, 6, 7, 10 |
| Where the SBOM can be accessed (if made available to users) | *Example:* Not made available to users |

## 2. Design, development, production and vulnerability handling

<!-- Guidance: Annex VII point 2. Explain how the product is built and maintained: architecture, development process, vulnerability handling, production and monitoring. This is the core engineering evidence. -->

### 2.1 Design and system architecture

```mermaid
flowchart LR
  user["User devices"] --> lan["LAN and Wi-Fi interfaces"]
  lan --> fw["Firmware: network stack, firewall, admin web UI"]
  fw --> wan["WAN interface"]
  fw --> boot["Secure boot and update agent"]
  boot --> cloud["Cloud companion service (remote data processing)"]
  app["Mobile app"] --> cloud
  cloud --> upd[("Signed update repository")]
```

[Describe how software components build on or feed into each other and
how they integrate into the overall processing. Example: "The firmware
runs on a Linux-based operating system with a hardened network stack.
The admin interface is served only on the LAN by default. The update
agent verifies signatures against a key fused at manufacture. The cloud
service authenticates devices with per-device certificates."]

### 2.2 Development process

| Practice | Description | Evidence |
|---|---|---|
| Secure development lifecycle | *Example:* Threat modelling per feature, code review, SAST and dependency scanning in CI | SDL procedure SDL-01 |
| Third-party component due diligence (Article 13(5)) | *Example:* Approved component list, licence and vulnerability check before adoption, maintenance status reviewed | Component policy CP-03 |
| Build integrity | *Example:* Reproducible builds; signed release artefacts; build provenance | Supply chain assessment SCA-2027 |
| Configuration management | *Example:* All firmware releases tagged and archived | Release register |

### 2.3 Vulnerability handling processes

| Item required by Annex VII point 2(b) | Where documented |
|---|---|
| Vulnerability handling process | CRA vulnerability handling procedure [CRA-VH-001] |
| Software bill of materials | Section 8 |
| Coordinated vulnerability disclosure policy | [URL and document reference] |
| Evidence of a contact address for vulnerability reports | [Screenshot or URL of the contact page and `security.txt`] |
| Technical solutions for secure distribution of updates | *Example:* Signed update packages over TLS from the update repository; automatic installation by default with opt-out; rollback protection |

### 2.4 Production and monitoring processes

[Describe production and monitoring processes and their validation.
Example: "Factory provisioning writes a unique device certificate and
random admin password; end-of-line test verifies secure boot is
enabled and debug ports are fused off. Production lots are sampled
monthly for configuration drift. Field telemetry (opt-in) monitors
update adoption."]

## 3. Cybersecurity risk assessment

<!-- Guidance: Annex VII point 3 and Article 13(2) to (4). The assessment must consider intended purpose, reasonably foreseeable use, conditions of use, operational environment, assets to protect and expected time in use. It must state whether and how each requirement of Annex I Part I point (2) applies, and justify any requirement that does not apply. Pitfall: a generic threat list not connected to design decisions. -->

### 3.1 Method and context

| Item | Description |
|---|---|
| Method | *Example:* Asset-based threat modelling (STRIDE per interface) with likelihood and impact scales from procedure RA-02 |
| Intended purpose and foreseeable use | *Example:* Home and small office; foreseeable use includes exposing the admin UI to the internet against advice |
| Operational environment | *Example:* Untrusted WAN, semi-trusted LAN, consumer administrators with low security expertise |
| Assets | *Example:* Admin credentials, user traffic, device integrity, Wi-Fi keys, cloud account tokens |
| Expected time in use | *Example:* 6 years or more |
| Inputs | *Example:* Threat intelligence, vulnerability history of prior models, penetration test results |
| Review frequency | *Example:* Each release and at least annually during the support period |

### 3.2 Risk register

| ID | Threat | Asset | Likelihood | Impact | Risk | Treatment | Annex I reference | Residual |
|---|---|---|---|---|---|---|---|---|
| RA-001 *(Example)* | Credential stuffing on admin UI | Admin credentials | High | High | High | Unique random default password, rate limiting, LAN-only admin by default | Part I (2)(b), (2)(d) | Low |
| RA-002 *(Example)* | Malicious firmware installed through update channel | Device integrity | Medium | Critical | High | Signed updates, secure boot, rollback protection | Part I (2)(f), Part II (7) | Low |
| RA-003 *(Example)* | Denial of service from WAN floods | Availability | High | Medium | Medium | Rate limiting, SYN cookies, watchdog recovery | Part I (2)(h) | Low |
| RA-004 *(Example)* | Device used as botnet node against third parties | Other networks | Medium | High | High | Minimal open services, outbound anomaly limits | Part I (2)(i), (2)(j) | Medium |
| [RA-nnn] | [Threat] | [Asset] | [L] | [I] | [Risk] | [Treatment] | [Reference] | [Residual] |

## 4. Essential cybersecurity requirements checklist

<!-- Guidance: One row per requirement in Annex I. Point numbers match the Annex; the wording is a summary. For each, say whether it applies, how it is met and where the evidence is. A requirement marked "not applicable" needs a clear justification (Article 13(4)). -->

### 4.1 Part I: properties of the product

| Point | Requirement (summary) | Applies | How it is met | Evidence |
|---|---|---|---|---|
| (1) | Designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks | Yes | *Example:* Risk assessment in 3 drives design | RA-02 records |
| (2)(a) | Placed on the market without known exploitable vulnerabilities | Yes | *Example:* Release gate: no open known exploitable vulnerability in SBOM matching | Release checklist, scan reports |
| (2)(b) | Secure by default configuration, with the possibility to reset to the original state | Yes | *Example:* Unique credentials, WPA3 default, admin LAN-only, factory reset button | Configuration baseline CB-4.0 |
| (2)(c) | Vulnerabilities can be addressed through security updates, automatic by default where applicable, with opt-out, notification and postponement | Yes | *Example:* Automatic nightly security updates; opt-out in settings; postpone up to 7 days | Update design UD-03 |
| (2)(d) | Protection from unauthorised access by appropriate control mechanisms, and reporting of possible unauthorised access | Yes | *Example:* Authentication, role separation, lockout, login alerts | Test TR-07 |
| (2)(e) | Confidentiality of stored, transmitted and processed data, for example by state-of-the-art encryption | Yes | *Example:* TLS 1.3 to cloud, encrypted configuration storage | Crypto inventory CI-01 |
| (2)(f) | Integrity of data, commands, programs and configuration against unauthorised manipulation, and reporting of corruption | Yes | *Example:* Secure boot, signed configuration backups, integrity alerts | Test TR-08 |
| (2)(g) | Process only data that are adequate, relevant and limited to the intended purpose (data minimisation) | Yes | *Example:* Telemetry opt-in; no browsing history collected | Data inventory DI-02 |
| (2)(h) | Availability of essential and basic functions, also after an incident, including resilience against denial of service | Yes | *Example:* Rate limiting, watchdog, safe mode | Test TR-09 |
| (2)(i) | Minimise negative impact on the availability of services of other devices or networks | Yes | *Example:* Outbound rate limits, no open resolvers | Test TR-10 |
| (2)(j) | Limit attack surfaces, including external interfaces | Yes | *Example:* No WAN services by default; debug interfaces disabled in production | Port scan report TR-11 |
| (2)(k) | Reduce the impact of an incident through exploitation mitigation mechanisms | Yes | *Example:* ASLR, stack protection, process isolation | Build hardening report TR-12 |
| (2)(l) | Record and monitor relevant internal activity, including access or modification of data, services or functions, with a user opt-out | Yes | *Example:* Security log of logins and configuration changes; opt-out in settings | Test TR-13 |
| (2)(m) | Allow users to remove all data and settings securely and permanently, and transfer data securely where transfer is possible | Yes | *Example:* Factory reset wipes keys and configuration; encrypted export | Test TR-14 |

### 4.2 Part II: vulnerability handling by the manufacturer

| Point | Requirement (summary) | How it is met | Evidence |
|---|---|---|---|
| (1) | Identify and document vulnerabilities and components, including a machine-readable SBOM of at least top-level dependencies | SBOM per release (section 8) | SBOM archive |
| (2) | Address and remediate vulnerabilities without delay, including through security updates, separate from feature updates where feasible | Remediation targets and patch line in CRA-VH-001 | Case records |
| (3) | Apply effective and regular security tests and reviews | Test programme (section 7) | Test reports |
| (4) | Publicly disclose fixed vulnerabilities once an update is available, with justified delay possible | Advisory process in CRA-VH-001 | Advisory archive |
| (5) | Put in place and enforce a coordinated vulnerability disclosure policy | Published CVD policy | Policy URL |
| (6) | Facilitate sharing of vulnerability information, including a contact address for reports | Single point of contact, `security.txt`, upstream reporting | Contact page |
| (7) | Provide mechanisms for secure distribution of updates, automatic where applicable | Signed update channel | Update design UD-03 |
| (8) | Disseminate security updates without delay and free of charge (unless agreed for tailor-made business products), with advisory messages | Release and notification process | Release records |

### 4.3 Traceability matrix

| Requirement | Risk IDs | Design element | Test | Status |
|---|---|---|---|---|
| Part I (2)(b) *(Example)* | RA-001 | Configuration baseline CB-4.0 | TR-06 | Met |
| Part I (2)(f) *(Example)* | RA-002 | Secure boot, signed updates | TR-08 | Met |
| Part I (2)(i) *(Example)* | RA-004 | Outbound limits | TR-10 | Met, residual risk accepted |
| Part II (1) *(Example)* | All | SBOM generation in build | TR-15 | Met |
| [Requirement] | [RA-nnn] | [Element] | [TR-nn] | [Met / Partly met / Not applicable with justification] |

## 5. Support period determination

<!-- Guidance: Annex VII point 4 and Article 13(8). Record the information used to set the support period. The period is at least five years unless the product is expected to be in use for less. Pitfall: choosing the minimum without considering how long users actually keep the product. -->

| Factor (Article 13(8)) | Information considered | Conclusion |
|---|---|---|
| Expected time in use | *Example:* Field data: median replacement after 6.5 years | Supports at least 6 years |
| Reasonable user expectations | *Example:* Consumer survey and competitor public statements | 6 years |
| Nature and intended purpose | *Example:* Internet-facing security-relevant device | Longer period justified |
| Relevant Union law on product lifetime | [Applicable law or "none identified"] | [Conclusion] |
| Support periods of similar products | *Example:* Competitors publish 5 to 7 years | 6 years within range |
| Availability of the operating environment | *Example:* Chipset vendor support confirmed until 2033 | Supports 6 years |
| Support of core third-party components | *Example:* Operating system long-term branch until 2032 | Mitigation plan for final year |
| ADCO and Commission guidance | [Reference, if published] | [Conclusion] |
| **Support period decided** | | *Example:* 6 years from placing on the market of each unit, end date shown as month and year |

## 6. Harmonised standards, common specifications and certification

<!-- Guidance: Annex VII point 5. List standards whose references are published in the Official Journal and that you applied, in full or in part. Where none is applied, describe the solutions adopted for each requirement. As of October 2026 the European standardisation organisations are still developing the standards requested by the Commission (standardisation request M/606); check the Official Journal and the Commission's CRA standardisation page for cited references. -->

| Reference | Type | Applied | Requirements covered | Notes |
|---|---|---|---|---|
| [Harmonised standard reference, once published in the Official Journal] | Harmonised standard | [Full / Partial] | [Annex I points] | Presumption of conformity only for cited references |
| [Common specification, if adopted by implementing act under Article 27] | Common specification | [Full / Partial] | [Points] | [Notes] |
| [European cybersecurity certification scheme under Regulation (EU) 2019/881] | Certification scheme | [Level] | [Points] | [Certificate number] |
| *Example:* IEC 62443-4-1 | Other standard (not cited) | Partial | Part II process requirements | Used as good practice; no presumption of conformity |
| *Example:* ETSI EN 303 645 | Other standard (not cited) | Partial | Part I consumer IoT baseline | Used as good practice |
| [Other specification] | [Type] | [Full / Partial] | [Points] | [Notes] |

Where no harmonised standard, common specification or certification
scheme has been applied: [describe, for each Annex I requirement, the
solution adopted and the evidence that it meets the requirement; refer to
section 4].

## 7. Test reports

<!-- Guidance: Annex VII point 6. List the tests that verify conformity of the product with Part I and of the vulnerability handling processes with Part II. Each report must be dated, identify the version tested and the tester. -->

| ID | Test | Scope and version | Requirement | Performed by | Date | Result |
|---|---|---|---|---|---|---|
| TR-06 *(Example)* | Default configuration review | Firmware 4.0.2 | Part I (2)(b) | Internal QA | YYYY-MM-DD | Pass |
| TR-08 *(Example)* | Secure boot and update tampering tests | Rev. C, firmware 4.0.2 | Part I (2)(f), Part II (7) | [External lab] | YYYY-MM-DD | Pass |
| TR-11 *(Example)* | External port scan and attack surface review | Firmware 4.0.2 | Part I (2)(j) | Internal security | YYYY-MM-DD | Pass |
| TR-16 *(Example)* | Penetration test | Firmware 4.0.2, cloud API v3 | Part I (1), (2)(a), (2)(d) | [External lab] | YYYY-MM-DD | 2 medium findings fixed in 4.0.3 |
| TR-07, TR-09, TR-10, TR-12 to TR-14 *(Example)* | Access control, denial of service, outbound traffic, hardening, logging and factory reset tests | Firmware 4.0.2 | Part I (2)(d), (h), (i), (k), (l), (m) | Internal security | YYYY-MM-DD | Pass |
| TR-15 *(Example)* | SBOM completeness check against the firmware image | Firmware 4.0.2 | Part II (1) | Internal QA | YYYY-MM-DD | Pass |
| TR-20 *(Example)* | Vulnerability handling process audit, including a reporting drill | Process CRA-VH-001 | Part II (1) to (8) | Internal audit | YYYY-MM-DD | Pass with 1 observation |
| [TR-nn] | [Test] | [Scope] | [Requirement] | [Who] | YYYY-MM-DD | [Result] |

## 8. Software bill of materials

<!-- Guidance: Annex VII point 8. The SBOM is part of the file and must be provided to a market surveillance authority on reasoned request. Record where each version's SBOM is kept and what it covers. -->

| Item | Value |
|---|---|
| Format | *Example:* CycloneDX 1.7 JSON |
| Coverage | *Example:* All firmware components, including transitive dependencies and the base operating system packages; mobile app; cloud service |
| Location | [Controlled archive path per released version] |
| Binding to release | *Example:* SBOM digest recorded in the release register and signed |
| Implementing act on SBOM format (Article 13(24)) | [Reference if adopted, otherwise "none adopted as of YYYY-MM-DD"] |
| Provision to authorities | On reasoned request, through [secure channel] |

## 9. Conformity assessment procedure

<!-- Guidance: Article 32 and Annex VIII. Record the procedure chosen, why it is allowed for the product category, and the certificates issued. Default products may use internal control (module A). Important class I products may use module A only when harmonised standards, common specifications or a certification scheme at assurance level at least substantial are applied in full; otherwise a third-party procedure is needed. -->

| Category | Procedures allowed (summary of Article 32) |
|---|---|
| Default | Module A (internal control); modules B and C; module H; or a European cybersecurity certification scheme where available |
| Important, class I (Annex III) | As default if harmonised standards, common specifications or a certification scheme at assurance level at least substantial are applied in full; otherwise modules B and C, or module H |
| Important, class II (Annex III) | Modules B and C; module H; or a certification scheme at assurance level at least substantial |
| Critical (Annex IV) | A European cybersecurity certification scheme where required by delegated act under Article 8(1); otherwise as for class II |
| Free and open-source software in Annex III categories | Any procedure in Article 32(1), if the technical documentation is made public (Article 32(5)) |

| Item | Value |
|---|---|
| Procedure chosen | *Example:* EU-type examination (module B) followed by conformity to type based on internal production control (module C) |
| Reason | *Example:* Class I product; no harmonised standard cited yet, so module A is not available |
| Notified body | [Name, identification number] |
| Certificate | [EU-type examination certificate number, date, validity] |
| Production control | *Example:* Module C: production follows the approved type; end-of-line checks in 2.4 |
| CE marking | [Affixed on product, packaging, and with notified body number where required; date] |

## 10. EU declaration of conformity

<!-- Guidance: Article 28 and Annex V. Draw up the declaration in the model structure below, translate it into the languages required by the Member States where the product is made available, and keep it updated. The product is accompanied by this declaration or by the simplified declaration of Annex VI with the internet address of the full text (Article 13(20)). If several Union acts require a declaration, draw up one declaration covering all of them (Article 28(3)). -->

**EU declaration of conformity** No. [DoC-CRA-001]

| Annex V item | Content |
|---|---|
| 1. Product identification | [Name, type and any additional information enabling unique identification] |
| 2. Manufacturer or authorised representative | [Name and address] |
| 3. Responsibility statement | This declaration of conformity is issued under the sole responsibility of the manufacturer. |
| 4. Object of the declaration | [Identification allowing traceability, which may include a photograph] |
| 5. Conformity statement | The object of the declaration described above is in conformity with Regulation (EU) 2024/2847 [and other relevant Union harmonisation legislation: list with publication references]. |
| 6. Standards and specifications | [References of harmonised standards, common specifications or cybersecurity certification in relation to which conformity is declared] |
| 7. Notified body (where applicable) | [Name and number, description of the procedure performed, certificate identification] |
| 8. Additional information | [Support period end date; link to user information] |
| Signed for and on behalf of | [Manufacturer] |
| Place and date of issue | [Place], YYYY-MM-DD |
| Name, function, signature | [Name], [function], [signature] |

Simplified declaration (Annex VI), if used with the product:

> Hereby, [manufacturer] declares that the product with digital elements
> type [designation] is in compliance with Regulation (EU) 2024/2847. The
> full text of the EU declaration of conformity is available at the
> following internet address: [URL].

## 11. Retention and updates of this file

<!-- Guidance: Article 13(13) and Article 31(2). Keep the file and the declaration available to authorities for at least ten years after placing on the market or for the support period, whichever is longer, and update them during the support period. -->

| Item | Rule |
|---|---|
| Retention | At least 10 years after the product is placed on the market or for the support period, whichever is longer |
| Location | [Controlled document system, access list] |
| Update triggers | *Example:* New release affecting compliance; new vulnerability changing the risk assessment; change in cited standards; change in support period; notified body request |
| Substantial modification check | *Example:* Each release assessed against criteria in procedure CM-05; outcome recorded in the revision history |
| Series production | Procedures ensure ongoing conformity of products in series (Article 13(14)) |
| Requests from authorities | Provided in a language easily understood by the authority (Article 13(22)) |
| Cessation of operations | Authorities and users informed before cessation takes effect (Article 13(23)) |

## 12. Appendices

<!-- Guidance: Index of supporting evidence and the terms used. -->

### 12.1 Evidence index

| Ref | Document | Version | Location |
|---|---|---|---|
| E-01 | Information and instructions to the user (Annex II) | [v] | [Link] |
| E-02 | Risk assessment records | [v] | [Link] |
| E-03 | CRA vulnerability handling procedure | [v] | [Link] |
| E-04 | Coordinated vulnerability disclosure policy | [v] | [Link] |
| E-05 | SBOM archive | [v] | [Link] |
| E-06 | Test reports TR-nn | [v] | [Link] |
| E-07 | Notified body certificate | [v] | [Link] |
| E-08 | Signed EU declaration of conformity | [v] | [Link] |

### 12.2 Glossary

| Term | Meaning in this document |
|---|---|
| Product with digital elements | Software or hardware product and its remote data processing solutions |
| Important product | Product whose core functionality matches a category in Annex III, class I or II |
| Critical product | Product whose core functionality matches a category in Annex IV |
| Module A, B, C, H | Conformity assessment modules: internal control; EU-type examination; conformity to type based on internal production control; full quality assurance |
| Substantial modification | A change after placing on the market that affects compliance with the essential requirements or changes the intended purpose |
| Support period | Period during which vulnerabilities must be handled in line with Annex I Part II |

References:

- Regulation (EU) 2024/2847 (Cyber Resilience Act), OJ L, 20.11.2024, ELI http://data.europa.eu/eli/reg/2024/2847/oj
- European Commission, CRA standardisation, https://digital-strategy.ec.europa.eu/en/policies/cra-standardisation
- Related templates: `security/cra-vulnerability-handling`, `security/supply-chain-security`, `dev/security-policy`, `ai-data/ai-act-technical-documentation`, `ai-data/ai-bom`

## Standard and licence note

Based on Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 13,
28, 31, 32 and 71 and Annexes I, II, V, VI, VII and VIII, as published in
the Official Journal of the European Union on 20 November 2024; EU
legislative texts are free to reuse. The provisions are summarised in
original wording; only the short model statements of Annexes V and VI are
followed so that the declaration has the required form. Check the
consolidated text on EUR-Lex, Commission implementing and delegated acts,
and harmonised standard references in the Official Journal for current
requirements. This is a documentation format, not legal advice. Template
licence: MIT.