The Cyber Resilience Act (Regulation (EU) 2024/2847) is the first EU law imposing mandatory cybersecurity requirements on products with digital elements — hardware and software sold on the EU market. It entered into force on 10 December 2024, the vulnerability- and incident-reporting duties began applying on 11 September 2026, and the full product-security obligations — secure-by-design requirements, conformity assessment, CE marking — apply from 11 December 2027. If you ship software, embedded devices, or connected hardware into the EU, you are a manufacturer under this regulation — regardless of where you are headquartered.
Who Is in Scope
The CRA covers any product whose intended purpose includes a direct or indirect logical or physical data connection — routers, operating systems, mobile and desktop applications, password managers, VPN clients, smart-home devices, industrial controllers, and embedded software. Pure online services (SaaS, cloud platforms) are out of scope unless they are an integral part of a product's functionality — a device whose remote processing happens in your cloud is covered as part of the product.
Products are tiered by risk. Around 90% are in the default category with self-assessment. Important products (Annex III) — identity and access management systems, browsers, password managers, network management, VPNs, operating systems, routers, smart-home security functions — face stricter conformity routes, with Class II products requiring third-party assessment. Critical products (Annex IV) — smartcards, hardware security modules, secure elements — need certified evaluation. Open-source developers acting outside commercial activity are largely exempt; a distinct "open-source software steward" category covers foundations that host and support projects commercially used.
Already in Force: The Reporting Duties
Since 11 September 2026, manufacturers must report to the single reporting platform operated by ENISA and the designated CSIRT:
- Actively exploited vulnerabilities — early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days after a corrective measure is available.
- Severe incidents impacting product security — early warning within 24 hours, incident notification within 72 hours, and a final report within 1 month.
This is the obligation that is live today — it does not wait for the 2027 CE-marking regime. If you distribute software in the EU, you need a channel that can detect an exploited-in-the-wild report and turn it into a 24-hour early warning.
The December 2027 Regime
From 11 December 2027, products can only be placed on the market if they meet the essential security requirements of Annex I — split into product properties and vulnerability handling:
- Secure by design: delivered without known exploitable vulnerabilities, with secure default configurations, protection of confidentiality, integrity, and availability, minimized attack surface, and security-by-design development processes.
- Vulnerability handling: effective vulnerability identification and remediation, regular testing and review, a coordinated vulnerability disclosure policy, secure and timely distribution of updates, and security support for at least 5 years (or the product's expected lifetime, if shorter).
- Technical documentation: risk assessment, security architecture, and component inventory — including a software bill of materials (SBOM) identifying all components, which enables market surveillance and your own vulnerability triage.
- EU declaration of conformity and CE marking: the visible signal the product complies, backed by the conformity assessment route your product category requires.
Importers and distributors carry verification duties — they must check the CE marking and documentation rather than trusting the supply chain. Non-compliance with the essential requirements or the reporting duties carries fines up to EUR 15M or 2.5% of global turnover.
SBOMs in Practice
The SBOM requirement is the operationally heavy piece: you must be able to identify which components — including open-source libraries — ship in each product version, so an exploited dependency maps to affected products in hours, not weeks. Practical implications: generate SBOMs in your build pipeline (CycloneDX or SPDX formats), keep them versioned alongside releases, and wire them to a monitoring feed for known vulnerabilities. The SBOM belongs to technical documentation — market-surveillance authorities can request it — it is not required to be public.
Mapping CRA to What You Already Have
If you run a certified ISMS, much of the machinery exists. Secure development lifecycle, vulnerability management, and supplier control map to ISO/IEC 27001 Annex A controls A.8.25–A.8.31 (secure development, architecture, testing, outsourced development) and A.5.19–A.5.23 (supplier and cloud security) — see the full Annex A control list. Harmonized European standards — still being finalized — will offer presumption of conformity once published, and an existing EU cybersecurity certification can substitute for parts of the assessment. The CRA does not demand a new discipline so much as it demands evidence: documented risk assessment, tested vulnerability-handling, and reproducible SBOMs.
A Practical Sequence for Software Vendors
- Classify your products. Default, important Class I/II, or critical — the category determines the conformity route and whether third-party assessment is needed.
- Stand up the reporting lane now. 24-hour early warning on exploited vulnerabilities is already live — define who detects, decides, and files to the ENISA platform.
- Generate SBOMs in CI. Every release, versioned, queryable against CVE feeds.
- Formalize vulnerability handling. Intake channel (security.txt or disclosure form), coordinated disclosure policy, fix SLAs, secure update distribution.
- Commit the support period. Security updates for at least 5 years — decide how EOL products are handled and communicated.
- Build the technical file. Risk assessment, architecture, SBOM, test evidence — the documentation behind your declaration of conformity.
Our GRC & management-system automation service builds the evidence layer — risk registers, vulnerability-handling workflows, control tracking — and the free ISO 27001 Gap Analysis gives you a baseline on the security-development controls CRA assumes. To scope an engagement, request a quote.
Frequently Asked Questions
Does the CRA cover SaaS and cloud services?
Pure online services are out of scope — NIS2 covers those. But a cloud component that is integral to a product's functionality is assessed as part of the product: a smart lock's companion app and its backend are within the product's security boundary.
Is the SBOM made public?
No — it is part of the technical documentation shared with market-surveillance authorities on request. What is public is the CE marking and the declaration of conformity; the component inventory stays in your technical file.
How long must security support last?
At least 5 years, or the product's expected lifetime if that is shorter. Security updates must be made available free of charge, and the support commitment becomes part of product documentation.
What applies right now versus December 2027?
Now: the reporting duties — 24-hour early warning and 72-hour notification for actively exploited vulnerabilities and severe incidents — plus the CE-marking/authority framework machinery. December 2027: the essential security requirements, conformity assessment, technical documentation, and CE marking obligations for products placed on the market.
Does CRA apply to open-source projects?
Non-commercial open-source development is exempt. Commercial activity changes the answer — monetized OSS products fall in scope — and a separate "open-source steward" regime gives foundations light-touch duties around cybersecurity policies and cooperation with authorities.
