Cyber-Resilience Act (CRA)
1. Why the CRA matters now
The Cyber-Resilience Act (CRA)—Regulation (EU) 2024/2847—is the EU's first horizontal law that legally mandates Secure-by-Design for every "product with digital elements" (PDE). It introduces objective-oriented and technology-neutral essential cybersecurity requirements that manufacturers must follow (CRA Art. 1, CRA Rec. 39).
- Official Journal – legally binding record as published on 20 Nov 2024: OJ:L_202402847 HTML.
- Consolidated Version – integrates subsequent corrections: CELEX:02024R2847-20241120 HTML.
The consolidated version is easier for clause citations, but in case of doubt the official journal prevails.
While harmonised standards are still under development, Germany's Federal Office for Information Security (BSI) has published a detailed technical guideline that serves as a practical playbook for CRA compliance.
| CRA milestone | Legal basis | Date |
|---|---|---|
| Text adopted by Parliament & Council | Signing date | 2024-10-23 |
| Published in the Official Journal (OJ L 2024/2847) | CRA Official Journal | 2024-11-20 |
| Regulation entered into force (Art. 71 § 1 + 20 d) | CRA Art. 71 § 1 | 2024-12-10 |
| Early duties for importers, distributors & authorised reps begin | CRA Art. 71 § 2 | 2026-06-11 |
| Vulnerability & incident reporting applies to manufacturers (CRA Art. 14) | CRA Art. 69 § 3 | 2026-09-11 |
| First set of harmonised standards published See The Role of Harmonised Standards | CRA Art. 27 | Q2 2027 (est.) |
| All CRA requirements apply (Annex I/II, CE-marking, enforcement) | CRA Art. 71 § 2 | 2027-12-11 |
Early duties from 11 Jun 2026
Importers, distributors & authorised representatives → must verify that a draft EU Declaration of Conformity and technical file exist, keep conformity documentation for at least 10 years or the product's support period, whichever is longer, and ensure storage/transport does not compromise firmware integrity (CRA Ch. IV).
Market-surveillance authorities → gain power to sample, test, and order withdrawals or recalls of insecure products (CRA Art. 35–51).
Early duties from 11 Sep 2026
Manufacturers → must operate a vulnerability-handling process:
• Notify the designated CSIRT without undue delay (expected within 24h) of an actively-exploited vulnerability (CRA Art. 14 § 1 + CRA Art. 16)
• Publish a Coordinated Vulnerability Disclosure (CVD) policy (CRA Annex I Part II § 5)
• If requested by a CSIRT, provide an intermediate report on the status of a vulnerability (CRA Art. 14 § 6).
Grace-period end (11 Dec 2027) – only Annex I/II-compliant PDEs may bear the CE mark; MSAs may recall or ban non-compliant goods; penalties up to € 15 million or 2.5 % of worldwide turnover for non-compliance with essential requirements (CRA Art. 64 § 2).
Relationship to other EU laws
| Law | How it interacts with CRA |
|---|---|
| NIS 2 Directive | Governs organisational cyber-risk; CRA covers product security. Manufacturers that are NIS-2 "essential" entities must comply with both. (CRA Rec. 13, CRA Rec. 24, NIS 2 Art. 21 § 2) |
| Radio Equipment Directive (RED) | Radio device security requirements exist in RED Art. 3 § 3 (d-f). CRA covers a wider range of products and its requirements include all elements of the RED's. (CRA Recital 30) |
| RED Delegated Act | Makes security clauses mandatory for certain wireless devices from 1 August 2025. This date is the result of a 12-month extension, granted by Regulation (EU) 2023/2444, to allow more time for harmonised standards to be developed. The original act is Regulation (EU) 2022/30. |
| CE-marking framework | CRA adds cybersecurity to the CE mark through Articles 28–30. A PDE may affix the mark only after Annex I/II compliance and completion of the appropriate conformity-assessment route. (CRA Art. 28, CRA Art. 30, CRA Rec. 89, CRA Rec. 93) |
2 Scope – which products are in?
2.1 Statutory Definition & Interpretation
Official Definition
A product with digital elements (PDE) is "any software or hardware product, and its remote data-processing solution, that is directly or indirectly connected to another device or network" (CRA Art. 3 § 1).
A remote data-processing solution, which is also in scope, is the cloud or back-end essential to the PDE's core function and "designed and developed by, or under the responsibility of, the manufacturer" (CRA Art. 3 § 2, see also CRA Recital 11).
Interpretation
This broad definition effectively covers almost any modern electronic device or piece of software. It creates a two-part test:
- Does it have "digital elements"? This means does it contain a microprocessor, firmware, or software?
- Can it connect to something else? This means does it have a "direct or indirect logical or physical data connection" to another device or network?
Both conditions must be met.
-
Example 1: A "dumb" toaster with a digital timer but no connectivity.
- Digital elements? Yes (firmware for the timer).
- Connectable? No.
- Result: Out of scope.
-
Example 2: A "smart" toaster with a Bluetooth app.
- Digital elements? Yes (firmware, app, and the cloud service).
- Connectable? Yes (Bluetooth).
- Result: In scope. The manufacturer is responsible for the toaster, the app, and any back-end cloud service they provide that is essential for its function.
-
Example 3: A high-end toaster updated via USB stick.
- Digital elements? Yes (firmware for new toast profiles).
- Connectable? Yes. (USB Stick)
- Result: In scope. The USB port is a physical data connection. The overall update process creates an indirect connection to the network where the firmware originated.
2.2 Out-of-scope & special regimes
| Excluded or separate regime | Legal reason |
|---|---|
| Medical devices | Already covered by MDR 2017/745 (CRA Art. 2 § 2(a)) |
| Automotive ECUs | Covered by Vehicle Type-Approval rules 2019/2144 (CRA Art. 2 § 2(c)) |
| Aviation & drones | EASA cyber rules override 2018/1139 (CRA Art. 2 § 3) |
| Defence & national security items | Excluded (CRA Art. 2 § 7) |
| Non-commercial OSS distributed "as-is" | Exempt when no commercial support (CRA Recital 15, CRA Recital 18, CRA Recital 19). If commercial support is later offered, CRA duties apply. |
| Open-source software stewards (foundations, maintainers) | Light-touch obligations (CRA Recital 19 + CRA Art. 24) |
| Commercial FOSS in Annex III classes | May use self-assessment (Module A) if technical documentation is made public (CRA Art. 32 § 5). |
| Pure SaaS (no local client) | Distinguished from a PDE's remote data-processing solution; general cloud services are covered by NIS 2 (CRA Recital 12). |
| Legacy products placed on the market before 11 Dec 2027 | Exempt unless they undergo a substantial modification after that date (CRA Art. 69 § 2) |
3 CRA Requirements & How to Implement Them
The CRA's mandatory security obligations are detailed in CRA Annex I (CRA Art. 6). This annex is split into two parts:
- Part I defines the product security requirements that must be designed into the device from the start.
- Part II defines the vulnerability handling requirements the manufacturer must follow throughout the product's support lifecycle.
The following tables translate those legal requirements into a practical engineering checklist. To provide a more concrete technical interpretation, they also map each CRA clause to the corresponding requirement in Germany's influential BSI TR-03183 technical guideline. It is important to note that the BSI TR is an official guideline from a national cybersecurity agency, designed as a playbook for compliance, not a legal text itself. Each row links to the relevant implementation guide in this handbook, providing a clear, actionable path from the legal text to the code and configuration required for compliance.
3.1 Risk Assessment & Threat Modeling
Before implementing specific security controls, the CRA requires manufacturers to perform and document a comprehensive cybersecurity risk assessment (CRA Art. 13 § 2, 3). Threat modeling is the core practice for fulfilling this obligation. It is a structured process to identify, analyze, and mitigate potential threats and vulnerabilities early in the design phase.
This proactive approach ensures that security is not an afterthought but a foundational part of the product's architecture. The outcomes of this threat model directly inform the security measures required in the subsequent sections.
| Obligations | Engineering Tasks | Implementation Guides |
|---|---|---|
| Cybersecurity risk assessment CRA Art. 13 § 2 BSI TR-03183-1: REQ_RA 1 | Perform and document a risk assessment covering the product's intended and reasonably foreseeable use. | Threat Modeling |
3.2 Product security (Annex I Part I)
| Obligations | Engineering Tasks | Implementation Guides |
|---|---|---|
| No known vulnerabilities Annex I § 1 (2)(a) BSI TR-03183-1: REQ_ER 2 | Ship without known exploitable vulnerabilities; establish a process to identify vulnerabilities in all product components. | CI/CD Hardening Static & Dynamic Analysis |
| Secure by default configuration Annex I § 1 (2)(b) BSI TR-03183-1: REQ_ER 3 | Provide a secure-by-default configuration that supports intended use and can be fully restored via a reset function. | Secure Configuration & Hardening |
| Security updates by design Annex I § 1 (2)(c) BSI TR-03183-1: REQ_ER 4 | Provide timely, integrity-protected security updates via a secure and automated mechanism (with user opt-out). | Secure OTA Updates |
| Access control Annex I § 1 (2)(d) BSI TR-03183-1: REQ_ER 5 | Implement an access control model based on least privilege; prevent and log unauthorised access attempts. | Unique Device Identity |
| Confidentiality protection Annex I § 1 (2)(e) BSI TR-03183-1: REQ_ER 6 | Protect confidentiality of sensitive data at-rest and in-transit using state-of-the-art encryption. | Key Provisioning & Storage |
| Integrity protection Annex I § 1 (2)(f) BSI TR-03183-1: REQ_ER 7 | Protect integrity of all code, data, and configuration using state-of-the-art mechanisms; detect and handle violations. | Secure Boot |
| Data minimisation Annex I § 1 (2)(g) BSI TR-03183-1: REQ_ER 8 | Limit data collection and processing to only what is necessary for the product's intended purpose. | Data Privacy & Secure Deletion |
| Resilience & availability Annex I § 1 (2)(h), (i) BSI TR-03183-1: REQ_ER 9, 10 | Protect essential functions against DoS attacks and prevent the product being used in attacks against other systems. | Device Lifecycle Management |
| Attack surface reduction Annex I § 1 (2)(j) BSI TR-03183-1: REQ_ER 11 | Minimise attack surfaces by securing all interfaces and disabling unused physical ports and network services. | Secure Configuration & Hardening |
| Exploit mitigation Annex I § 1 (2)(k) BSI TR-03183-1: REQ_ER 12 | Use and enable modern exploit mitigation techniques (e.g., ASLR, stack protection, CET). | Secure Configuration & Hardening |
| Security logging Annex I § 1 (2)(l) BSI TR-03183-1: REQ_ER 13 | Log all security-relevant events by default, including access attempts and setting changes, with a user opt-out. | Security Logging & Monitoring |
| Secure data deletion Annex I § 1 (2)(m) BSI TR-03183-1: REQ_ER 14 | Provide a function for users to securely and completely delete all personal and configuration data. | Data Privacy & Secure Deletion |
3.3 Vulnerability handling (Annex I Part II)
The CRA makes it a hard-wired legal duty for manufacturers to "address and remediate vulnerabilities without undue delay" throughout the product's entire lifecycle (Annex I, Part II, § 2). This obligation lasts for a mandatory support period, which the manufacturer must define. This period cannot be shorter than five years from the date the product is placed on the market, unless its expected usable life is shorter (CRA Art. 13 § 8, 9). During this time, security updates must be provided free of charge.
| Obligations | Engineering Tasks | Implementation Guides |
|---|---|---|
| Identify components (SBOM) Annex I Part II § 1 BSI TR-03183-1: REQ_VH 1 BSI TR-03183-2 § 5.2 | Create and maintain an up-to-date, machine-readable Software Bill of Materials (SBOM) for all software components. | SBOM & VEX Workflows |
| Handle & remediate vulnerabilities Annex I Part II § 2, 7, 8 BSI TR-03183-1: REQ_ER 4, REQ_VH 6 | Address and remediate vulnerabilities without undue delay, providing timely security updates via a secure mechanism. | Secure OTA Updates Patch Cadence |
| Regular security testing Annex I Part II § 3 BSI TR-03183-1: REQ_VH 3 | Regularly test the product for vulnerabilities using both internal processes and independent experts. | Static & Dynamic Analysis |
| Public vulnerability information Annex I Part II § 4, 5 BSI TR-03183-1: REQ_VH 5 BSI TR-03183-3 § 4.3 | Inform users about fixed vulnerabilities, their impact, and mitigation steps via security advisories. | Vulnerability Disclosure |
| Coordinated Vulnerability Disclosure Annex I Part II § 6 BSI TR-03183-1: REQ_VH 2 | Publish a clear vulnerability disclosure policy and provide an easily accessible contact channel for vulnerability reporting. | Vulnerability Disclosure |
How Vulnerabilities are Discovered and Handled
The CRA anticipates that vulnerabilities will be discovered through multiple channels, both internal and external. Manufacturers must have processes in place to handle all of them.
| Discovery Channel | CRA Hook | What it looks like in practice |
|---|---|---|
| Internal Security Testing | Annex I, Part II, § 3: "apply effective and regular tests and reviews" | DevSecOps pipelines flag flaws before and after release; automated SBOM scanning against vulnerability databases (e.g., NVD) catches new CVEs in third-party libraries. |
| Supply-Chain Monitoring | Annex I, Part II, § 1, 2: "identify and document components... address and remediate vulnerabilities" | The manufacturer monitors advisories for all components in their SBOM (e.g., OpenSSL, Linux kernel, RTOS, chipset firmware) and integrates or back-ports security patches. |
| Coordinated Disclosure | Annex I, Part II, § 5, 6, Recital 76 | Security researchers, customers, or bug bounty hunters report flaws via the manufacturer's published CVD policy and secure contact channel. |
| In-Field Detection | Art. 14, Annex I, Part II, § 4, 8 | If active exploitation is detected in the wild, the manufacturer must: (i) notify the designated CSIRT without undue delay (within 24h), (ii) develop a remediation, and (iii) provide a security update to users. |
3.4 Other Key Obligations
Beyond the direct product and vulnerability requirements in Annex I, the CRA imposes several other crucial obligations on manufacturers regarding documentation, conformity, and reporting.
| Obligations | Engineering Tasks | Implementation Guides |
|---|---|---|
| Technical documentation CRA Art. 31, Annex VII | Create & maintain technical file with risk assessment, SBOM, design specs, and evidence of Annex I compliance. Keep for at least 10 years or the support period, whichever is longer. Evidence: Technical file. | n/a |
| Conformity & CE mark CRA Art. 13(12), 28, 30 | Perform conformity assessment (self-assessment or third-party audit); draw up EU Declaration of Conformity (DoC); affix CE mark. Evidence: DoC, Notified Body certificate (if applicable). | n/a |
| Information to users CRA Art. 13(17-19), Annex II | Provide clear instructions on intended use, secure configuration, support period end-date, and how to report vulnerabilities. Evidence: User manual/documentation. | User Documentation Guide |
| ENISA reporting CRA Art. 14 | Notify the designated CSIRT without undue delay (expected within 24h) of an actively exploited vulnerability. If requested, provide intermediate status reports. Evidence: Incident logs. | n/a |
* Dates derive from CRA Art. 71 § 2 and Art. 69 § 3: most obligations apply 36 months after entry into force (2024-12-10). Reporting duties under Art. 14 begin earlier, at 21 months.
4 Self-Assessment vs. Third-Party Audit?
4.1 Product Risk Classification (The Four Tiers)
The CRA establishes a four-tier risk classification system. A product's classification determines the conformity assessment procedure it must undergo before receiving a CE mark. The classification depends on whether the product is listed in CRA Annex III or CRA Annex IV of the regulation.
-
Default Category (Unclassified): This is the baseline tier for the vast majority (~90%) of products with digital elements. It covers any product not listed in Annex III or Annex IV.
- Assessment: Manufacturers can perform a self-assessment (Module A). The manufacturer retains the flexibility to choose a stricter conformity assessment procedure involving a third party if they wish (CRA Art. 32 § 1, CRA Rec. 93).
- Example: A smart toaster, a simple connected sensor, or a general-purpose software library.
-
Important Products — Class I: This tier covers products listed in CRA Annex III, Part I. These products perform functions critical to cybersecurity or pose a significant risk of disruption (CRA Art. 7 § 2).
- Assessment: Self-assessment (Module A) is possible if the manufacturer fully applies relevant harmonised standards. Otherwise, a third-party audit is required (CRA Art. 32 § 2).
- Examples (from Annex III, Part I): Identity management systems, password managers, web browsers, smart home products with security functions (e.g., smart locks).
-
Important Products — Class II: This tier covers a smaller list of higher-risk products defined in CRA Annex III.II.
- Assessment: A third-party audit by a Notified Body is mandatory (CRA Art. 32 § 3).
- Examples (from Annex III, Part II): Hypervisors, firewalls, industrial intrusion detection systems, tamper-resistant microprocessors.
-
Critical Products: The highest risk tier, for products listed in CRA Annex IV. These are products upon which the EU's critical infrastructure (as defined in NIS 2) may depend, or whose failure could disrupt critical supply chains (CRA Art. 8 § 2).
- Assessment: The Commission may require a mandatory European cybersecurity certificate at assurance level 'substantial' or higher. If no such scheme is mandated, these products follow the same rules as Class II (CRA Art. 32 § 4).
- Examples (from Annex IV): Hardware Security Modules (HSMs), smart meter gateways, smartcards.
The table below provides a non-exhaustive list of examples mapping product categories to the four risk tiers:
| Product & Category | Default | Important (Class I) | Important (Class II) | Critical |
|---|---|---|---|---|
| Consumer | ||||
| Smart speaker (no virtual assistant) | ✅ | |||
| Smart TV | ✅ | |||
| Smart thermostat | ✅ | |||
| Smart refrigerator | ✅ | |||
| Smart doorbell (with no lock) | ✅ | |||
| Smart Lighting Controller/Hub | ✅ | |||
| Smartphone | ✅ | |||
| Smart speaker with virtual assistant (CRA Annex III.I.16) | ✅ | |||
| Smart lock (CRA Annex III.I.17) | ✅ | |||
| Home alarm system (CRA Annex III.I.17) | ✅ | |||
| Baby monitor (CRA Annex III.I.17) | ✅ | |||
| Fitness band (CRA Annex III.I.19) | ✅ | |||
| Connected toy (CRA Annex III.I.19) | ✅ | |||
| General IT | ||||
| Printer | ✅ | |||
| Office Suite | ✅ | |||
| Laptop | ✅ | |||
| Network-Attached Storage (NAS) device | ✅ | |||
| Digital Signage Display | ✅ | |||
| Web browser (CRA Annex III.I.2) | ✅ | |||
| Password manager (CRA Annex III.I.3) | ✅ | |||
| SIEM (CRA Annex III.I.7) | ✅ | |||
| Operating System (CRA Annex III.I.12) | ✅ | |||
| Router / Modem (CRA Annex III.I.13) | ✅ | |||
| Hypervisor / Container runtime (CRA Annex III.II.1) | ✅ | |||
| Firewall (CRA Annex III.II.3) | ✅ | |||
| Intrusion Detection System (CRA Annex III.II.2) | ✅ | |||
| Specialised H/W | ||||
| Basic Barcode Scanner / RFID Reader | ✅ | |||
| Microprocessor w/ security features (CRA Annex III.I.14) | ✅ | |||
| Tamper-resistant microprocessor (CRA Annex III.II.4) | ✅ | |||
| Tamper-resistant microcontroller (CRA Annex III.II.5) | ✅ | |||
| HSM (CRA Annex IV.1) | ✅ | |||
| Smartcard / Secure Element (CRA Annex IV.3) | ✅ | |||
| Industrial (OT) | ||||
| Non-critical IoT sensor | ✅ | |||
| Industrial IoT Temperature Sensor | ✅ | |||
| Industrial VPN gateway (CRA Annex III.I.5) | ✅ | |||
| Industrial firewall (CRA Annex III.II.3) | ✅ | |||
| Industrial IDS (CRA Annex III.II.2) | ✅ | |||
| Smart meter gateway (CRA Annex IV.2) | ✅ | |||
| Component | ||||
| General-purpose library (CRA Art. 3 § 1) | ✅ |
4.2 Assessment Routes for Each Tier
Once a manufacturer has determined their product's risk class using the tiers above, the next step is to identify the specific conformity assessment procedure required to earn the CE mark. The CRA lays out several distinct 'modules' or routes, and the path you must take is dictated directly by your product's classification.
| Class | Conditions | Assessment Route |
|---|---|---|
| Default | All unclassified products. | Module A (Internal Control) → Manufacturer performs self-assessment (CRA Art. 32 § 1). |
| Important (Class I) | Manufacturer fully applies harmonised standards or a relevant certification scheme. | Module A (Internal Control) → Manufacturer performs self-assessment. |
| Manufacturer does not fully apply harmonised standards or a scheme. | Modules B+C or Module H → Mandatory third-party audit by a Notified Body (CRA Art. 32 § 2). | |
| Important (Class II) | All Class II products. | Modules B+C or Module H → Mandatory third-party audit by a Notified Body (CRA Art. 32 § 3). |
| Critical (Annex IV) | Commission mandates a specific European Cybersecurity Certification Scheme. | Mandatory certification under the specified scheme. |
| No scheme is mandated by the Commission. | Modules B+C or Module H → Mandatory third-party audit by a Notified Body (same as Class II) (CRA Art. 32 § 4). |
Key takeaway: For Class I products, following harmonised standards is the express lane to self-assessment. For all higher classes, some form of third-party assessment is either likely or mandatory.
4.3 The Role of Harmonised Standards
A harmonised standard (hEN) is a standard created by a European Standardisation Organisation (e.g., ETSI) following a formal request from the European Commission. When a product complies with a relevant hEN—such as ETSI EN 303 645 for consumer IoT—it gains a "presumption of conformity" with the CRA's essential requirements (CRA Art. 27).
This provides two key benefits for manufacturers:
- Simplified Assessment: For Important (Class I) products, it allows the manufacturer to perform a self-assessment (Module A) instead of requiring a third-party audit.
- Simpler Documentation: The manufacturer can cite the harmonised standard in their EU Declaration of Conformity, rather than documenting compliance with every requirement in Annex I individually.
The first harmonised standards for the CRA are expected to be published in the Official Journal around Q2 2027. This follows a standardisation request (Mandate M/606) and an 18-24 month drafting period.
In the absence of a suitable harmonised standard, the Commission may issue a common specification to provide the same presumption of conformity (CRA Art. 27 § 2, 5).