EU Cyber Resilience Act (CRA) – Overview (Updated Oct 2026)
What is the Cyber Resilience Act – CRA
The Cyber Resilience Act is the first European regulation to set a mandatory minimum level of cyber security for all connected products available on the EU market – something that did not exist before.
The CRA is a regulation from the European Union — formally Regulation (EU) 2024/2847 — but it is likely to be applied soon in other parts of the world, which produce for and sell products in the EU.
It covers both hardware and software products whose intended or foreseeable use involves connection (direct or indirect) to a device or network. That includes things like smartphones, laptops, IoT devices (smart-home cameras, smart fridges, connected toys), embedded systems, routers, industrial control systems, and even software with network connectivity.
Non-commercial open source software products are exempt from the CRA and therefore do not have to fulfill the requirements of the CRA.
Some product categories are excluded because they are already covered by other sector-specific regulation (e.g. certain medical devices, aviation, automotive, defense).
As can be seen, the aim is to increase cybersecurity within the European Union. The new regulation applies in all EU Member States and will be implemented gradually.
Timeline & Legal Effect
The CRA entered into force on 10 December 2024. There is a transition / compliance period: the full requirements become applicable by 11 December 2027 for new products.
Starting 11 June 2026, the Conformity Assessment Bodies can assess the fulfillment of the requirements.
Reporting of vulnerabilities and security incidents starts on 11 September 2026.
*CABs = Conformity Assessment Bodies
Source: BSI
Key Requirements & Obligations
For manufacturers, importers or distributors of in-scope products, CRA demands:
Secure-by-design and secure-by-default
During design and development, implement baseline cybersecurity controls (minimizing attack surface, secure defaults, applying cryptography, access control, integrity protection, etc.).
If you design or manufacture hardware or software intended for the EU market — start including security early: threat modelling, secure defaults, update mechanisms, patch management, SBOM (software-bill-of-materials) for components, documentation.
Lifecycle security
Maintain security across the lifecycle — through production, deployment, maintenance, updates (patches), and eventual decommissioning.
Prepare to collect and maintain documentation of the build, supply chain components, update/maintenance history, and test results for many years.
Vulnerability & incident reporting
If a product becomes subject to a “actively exploited vulnerability” or a “severe security incident”, the manufacturer must report promptly (early warning within 24 h, full notification within 72 h, final report within certain timeframes) via the CRA Single Reporting Platform.
For software vendors — ensure update/patch infrastructure is robust and built-in, and notification processes in place for vulnerabilities.
Documentation & traceability
Maintain technical documentation, data inventories and evidence of security measures for a defined period (often many years) after placing the product on the market.
CE-marking with security
Products that comply must carry the CE-mark, indicating conformity with the CRA’s cybersecurity requirements — similar to CE marking for safety or environmental compliance.
For buyers/customers — expect CE-mark + transparency regarding security posture. Choose vendors who commit to long-term patching and vulnerability response.
Conformity assessments for higher-risk products
While many products (roughly 90%) fall under a “default” tier and can be self-assessed by manufacturers, certain more critical or important product types (e.g. firewalls, security modules, intrusion detection systems, certain embedded systems) may require third-party assessment before being placed on market.
Why It Matters
The CRA establishes a common, EU-wide baseline for cybersecurity of digital products. This helps avoid fragmentation where different member states might otherwise have different rules. It forces manufacturers and vendors to adopt security by default + lifecycle security, rather than treating cybersecurity as an optional afterthought. This helps reduce the attack surface and improves resilience against cyber threats.
It increases transparency for consumers and businesses: when they buy a product with digital elements, they can expect a baseline of security and support — including updates and vulnerability management.
For vendors and developers — in enterprise, embedded, IoT or consumer space — it’s a legal obligation. Non-compliance when required could lead to regulatory consequences, and non-compliant products will not be allowed on the EU market once the deadlines lapse.
CRA Product Classification
Criteria & Examples
The CRA divides “products with digital elements (PDEs)” into four classification tiers. Classification drives what conformity assessment, certification, and compliance rigour you must apply.
Update October 2026: On 28 November 2025 the European Commission adopted Implementing Regulation (EU) 2025/2392. It entered into force on 21 December 2025 and contains the official technical descriptions of every important (Annex III) and critical (Annex IV) product category. A product is classified by its core functionality, meaning what it is mainly designed to do. A product that only embeds a component from a higher category, such as a news app with a built-in browser, does not automatically move into that category. The tables below were corrected to match the regulation.
| Category | When a product is placed here (criteria / rationale) | Typical product examples* |
|---|---|---|
| Default | Products that are not listed in the “Important” or “Critical” annexes — i.e. no particularly sensitive cybersecurity function or high risks associated with compromise. | Many consumer devices & software: smart toys, basic IoT devices, simple smart-home equipment, non-security-critical apps, common consumer electronics. |
| Important – Class I | The core functionality matches one of the categories listed in Annex III, Class I. These products perform cybersecurity-relevant functions such as authentication, access control, malware protection or network access. Self-assessment is allowed only if the manufacturer applies harmonised standards, common specifications or a European cybersecurity certificate. Otherwise a notified body is required. | Identity management systems and privileged-access software or hardware (incl. access readers), standalone/embedded browsers, password managers, antivirus/antimalware software, VPN products, network management systems, SIEM systems, boot managers, PKI and certificate issuance software, operating systems, microcontrollers/microprocessors with security functions, routers/modems/switches, smart home security products. |
| Important – Class II | The core functionality matches one of the four categories listed in Annex III, Class II. For these, third-party conformity assessment by a notified body is mandatory. | Hypervisors and container runtime systems, firewalls, intrusion detection/prevention systems (IDS/IPS), tamper-resistant microprocessors and microcontrollers. |
| Critical | The core functionality matches one of the three categories listed in Annex IV. These products must obtain a European cybersecurity certificate where a Commission delegated act requires it. Until then, they go through the same third-party procedures as Class II. | Hardware security modules (“security boxes”), smart meter gateways, smartcards / secure-elements, secure cryptoprocessing hardware — i.e. devices central to critical infrastructure, secure identity, secure communication or supply chain security. |
* Examples are taken from Annex III and Annex IV of the CRA and from Implementing Regulation (EU) 2025/2392, which contains the official technical description of each category.
Assessment & conformity requirements per class
Below are examples of software products affected by the Cyber Resilience Act, organized into two tables and classified into the CRA categories:
-
Default Category – non-critical, low inherent risk
-
Important Class I – categories listed in Annex III, Class I, including antimalware, VPN, SIEM, identity management, password managers, browsers and operating systems
-
Important Class II – hypervisors and container runtimes, firewalls, IDS/IPS, tamper-resistant microprocessors and microcontrollers (Annex III, Class II)
-
Critical – hardware devices with security boxes, smart meter gateways and smartcards or secure elements (Annex IV)
The exact classification of a product depends on its core functionality and intended use, as described in Implementing Regulation (EU) 2025/2392.
Examples of Software Products Classification
Disclaimer: this table reflects my reading of Annex III and Annex IV of the CRA and of Implementing Regulation (EU) 2025/2392. It was reviewed against these texts in October 2026. The final classification always depends on the core functionality of the specific product.
This list was created with help of AI and it is no guarantee to be complete or correct.
| Software Type | Example(s) | CRA Category | Rationale |
|---|---|---|---|
| CRM Platforms | Salesforce, HubSpot, MS Dynamics | Default | General business software with no security function. When delivered purely as SaaS, first check whether it falls under the CRA at all, since the CRA covers products. |
| Blogging/CMS Platforms | WordPress, Ghost, Drupal | Default | Consumer and enterprise web software; not security-critical by default. |
| Office Productivity Tools | LibreOffice, MS Office | Default | Widely used but not security components. |
| Developer Tools | IDEs, build systems | Default | Not listed in Annex III. Relevance for the software supply chain alone does not move a product into an important class. |
| Cloud Management Consoles | AWS CLI tools, Azure Portal extensions | Default | Not listed in Annex III. Web portals delivered as a service may be outside the CRA scope. |
| Antivirus / Endpoint Protection | CrowdStrike, Defender, Bitdefender | Important Class I | Annex III, Class I, point 4: software that searches for, removes or quarantines malicious software. |
| EDR/XDR Platforms | SentinelOne, Trellix, Microsoft XDR | Important Class I | No category of its own. Class I when the core functionality is anti-malware (point 4) or SIEM (point 7). |
| Firewalls (Software-based) | pfSense, OPNsense, Cisco, Juniper | Important Class II | Annex III, Class II, point 2: firewalls, intrusion detection and prevention systems. |
| VPN Clients | OpenVPN Client, WireGuard clients | Important Class I | Annex III, Class I, point 5: products with the function of a virtual private network (VPN). |
| Identity & Access Software | SSO, MFA clients, IdP agents | Important Class I | Annex III, Class I, point 1: identity management systems and privileged access management software. |
| Key Management & Crypto Libraries | OpenSSL, libsodium | Default | Not listed in Annex III or IV. All critical categories are hardware devices. Open source projects that are not supplied in the course of a commercial activity are outside the CRA. |
| Secure Configuration Agents | MDM agents, compliance agents | Default | Not listed in Annex III. Default unless the core functionality matches a listed category, such as identity management. |
| Network Monitoring / SIEM | Splunk, Elastic, QRadar | Important Class I | Annex III, Class I, point 7: security information and event management (SIEM) systems. |
| Container Security Tools | Aqua, Twistlock | Default | Not listed in Annex III. Only container runtime systems are Class II. If the core functionality is a firewall or IDS, the product is Class II. |
Further reading and sources
-
https://digital-strategy.ec.europa.eu/en/policies/cra-summary
-
https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
-
https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
-
https://digital-strategy.ec.europa.eu/en/policies/cra-conformity-assessment
- https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- https://iapp.org/news/a/10-tips-to-prepare-for-the-eu-cyber-resilience-act
- https://eur-lex.europa.eu/eli/reg_impl/2025/2392/oj
The post EU Cyber Resilience Act (CRA) – Overview (Updated Oct 2026) first appeared on Sorin Mustaca – Security & Technology.
