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.
Document control
| 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
| 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
1. General description 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
2.1 Design and system architecture
[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
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
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
| 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
| 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
| 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
| 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
| 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
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
| 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
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 |
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.