On 10 October 2024, the EU Cyber Resilience Act (CRA) entered into force, marking a watershed moment in European cybersecurity regulation. Unlike GDPR — which governs data — the CRA governs the security of products with digital elements: software, firmware, connected hardware, and everything in between. If your organisation manufactures, imports, or distributes any such product in the European market, this law directly affects you.
This guide covers everything you need to know: the legal background, scope, requirements, timelines, and penalties. We also explain how tools like CRATrust can help you achieve and maintain compliance efficiently.
Why the CRA Exists
For decades, the EU's digital single market lacked a unified baseline for the cybersecurity of products. The 2016 NIS Directive and its 2022 successor NIS2 addressed operators of essential services and digital service providers — but said nothing about the security of the software and hardware products those operators use. The result: a market flooded with products containing known vulnerabilities, shipped without security updates, and bearing no accountability to end users.
The European Commission's impact assessment found that cybercrime cost the EU economy over €5.5 trillion annually by 2021. A significant proportion of attacks exploited vulnerabilities in commercial products that manufacturers had never been required to fix. The CRA changes this fundamentally: it shifts security responsibility from users to manufacturers.
"The Cyber Resilience Act will ensure that products on the EU market are cyber-secure by default and by design — not as an afterthought." — Thierry Breton, former EU Commissioner for Internal Market
What Products Does the CRA Cover?
The CRA applies to "products with digital elements" placed on the EU market. This deliberately broad definition covers:
- Standalone software (desktop apps, mobile apps, SaaS clients)
- Embedded software and firmware
- Connected hardware devices (IoT, routers, smart devices)
- Industrial control systems and SCADA software
- Network equipment and operating systems
- Remote data processing solutions
Crucially, the CRA also covers component software — libraries, SDKs, and modules — when they are made available commercially. This means open-source maintainers who monetise their work through support contracts or hosted services are in scope.
Several categories are explicitly excluded:
- Products covered by existing sector-specific rules (medical devices, aviation, automotive under type approval)
- National security and defence products
- Free and open-source software developed entirely non-commercially
- Software-as-a-Service not supplied as a product (covered by NIS2 instead)
The Product Classification System
Not all products face the same requirements. The CRA creates three tiers, defined in Annexes I through III of the regulation:
Core Security Requirements (Annex I)
Annex I of the CRA sets out the essential cybersecurity requirements all in-scope products must meet. These fall into two parts:
Part I — Security Properties of Products
- Secure by default: Products must ship with security-enabling configurations active. No default passwords, no unnecessary open ports.
- No known exploitable vulnerabilities at launch: Manufacturers must identify and remediate vulnerabilities before placing a product on the market.
- Minimal attack surface: Only expose interfaces and features that are necessary.
- Protection of data confidentiality: Encryption in transit and at rest where appropriate.
- Access control: Authentication mechanisms commensurate with risk.
- Resilience: Products must be able to tolerate and recover from DoS conditions.
- Integrity verification: Mechanisms to verify the integrity of software and data.
- Audit logging: Security-relevant events must be logged with sufficient detail.
- Software Bill of Materials (SBOM): Manufacturers must identify and document all components including open-source dependencies.
Part II — Vulnerability Handling Obligations
- Establish and operate a coordinated vulnerability disclosure (CVD) policy.
- Provide security updates free of charge for the supported lifecycle (minimum 5 years from market placement or expected use period).
- Report actively exploited vulnerabilities and severe incidents to ENISA within 24 hours of becoming aware, with a full notification within 72 hours.
- Maintain a single point of contact for vulnerability reports from security researchers and customers.
Key Dates and Timelines
The CRA entered into force on 10 October 2024, but full obligations are phased:
- 11 September 2026: Article 14 vulnerability reporting and ENISA notification obligations begin. Manufacturers must be ready to report exploited vulnerabilities within 24 hours.
- 11 December 2027: All CRA requirements apply. Products placed on the EU market from this date must comply fully. Existing products already on the market have until their next "substantial modification" or end of support.
- 11 December 2030: Notified bodies reporting obligations to ENISA become active.
Penalties for Non-Compliance
The CRA contains some of the most severe penalties in EU product regulation. Non-compliance can result in:
- Up to €15,000,000 or 2.5% of global annual turnover (whichever is higher) for violations of essential requirements or the Article 14 reporting obligations.
- Up to €10,000,000 or 2% of global annual turnover for other violations such as misleading declarations of conformity.
- Up to €5,000,000 or 1% of global annual turnover for providing incorrect or incomplete information to market surveillance authorities.
Beyond financial penalties, national market surveillance authorities can order product recalls, market withdrawals, and import bans. For companies with EU market ambitions, the reputational and commercial consequences of a CRA enforcement action could be existential.
The Role of the SBOM
One of the most operationally significant CRA requirements is the mandate to produce and maintain a Software Bill of Materials (SBOM). Under Annex I, Part II, manufacturers must identify all components of their products — including open-source libraries — to a degree of granularity that enables effective vulnerability tracking.
An SBOM is a machine-readable inventory of every software component in your product: names, versions, licenses, suppliers, and dependency relationships. The CRA doesn't mandate a specific SBOM format, but industry standards like CycloneDX and SPDX are widely accepted.
Without an SBOM, you cannot know which of your products are affected when a critical vulnerability like Log4Shell or XZ Utils is disclosed. With one, you can identify affected products in minutes.
Official Resources
For primary sources, we recommend:
- CRA Official Text — EUR-Lex (Regulation EU 2024/2847)
- European Commission — Cyber Resilience Act policy page
- ENISA — CRA guidance and resources
- BSI Germany — CRA implementation guidance
Getting Started with CRA Compliance
CRA compliance is not a one-time project — it is an ongoing operational discipline. The organisations that will fare best are those that start building compliance processes now, before the December 2027 deadline, rather than scrambling in the final months.
The key first steps are: classify your products, generate SBOMs for each, establish a vulnerability monitoring programme, and document your secure development lifecycle. CRATrust is purpose-built to help you do exactly this — from automated SBOM ingestion to real-time vulnerability monitoring and compliance reporting.