The Cyber Resilience Act (CRA) is an EU law that sets baseline cybersecurity rules for hardware and software products sold in the European Union. It's formally known as Regulation (EU) 2024/2847, and it entered into force on December 10, 2024. Think of it as a "safety label" requirement for anything digital and connected: similar to how a CE mark already tells you a toy or appliance meets EU safety standards, the CRA extends that logic to cybersecurity.
In practice, if a product can connect to a network, runs software, or is software itself, and it's sold anywhere in the EU, the CRA likely touches it, regardless of where the company that makes it is based.
Who has to comply?
The Cyber Resilience Act's obligations fall on manufacturers, importers, and distributors of "products with digital elements" (PDEs). A PDE is any hardware or software whose intended use includes a direct or indirect connection to a device or network, a definition broad enough to cover smart home gadgets, routers, wearables, mobile apps, operating systems, and cloud back-ends that a product depends on to function.
Location doesn't matter. A company based in the US, Japan, or anywhere else is in scope the moment its product reaches an EU customer. A few categories sit outside the CRA because they're already regulated elsewhere: medical devices, vehicles, and aviation systems, for example, follow their own sector-specific rules.
Does the CRA apply to companies outside the EU?
Yes. The CRA is not limited to EU-headquartered businesses. It applies to anyone placing a qualifying product on the EU market, no matter where they're incorporated. This mirrors how GDPR reached beyond EU borders: the trigger is where the product is sold, not where the company sits.
Does the CRA apply to open-source software?
Mostly, no, but there's nuance worth understanding. The CRA only applies to open-source software that is supplied "in the course of a commercial activity." Publishing code for free, accepting donations without profit motive, or maintaining a project as a hobbyist keeps you outside the regulation entirely.
Where it gets more specific:
- Non-profit organizations that direct all earnings back into the project generally aren't considered to be engaged in "commercial activity."
- Individual contributors who submit code to a project they don't control or maintain are exempt.
- A new category, "open-source software stewards," covers organizations that provide sustained, systematic support for OSS projects used commercially. These stewards face lighter obligations and are explicitly shielded from CRA fines.
- If a company monetizes open-source software as part of a commercial product, the standard manufacturer obligations apply just as they would for closed-source code.
When does the CRA take effect?
The Cyber Resilience Act rolls out in phases rather than all at once. Three dates matter most for planning:
| Date | What applies |
|---|---|
| December 10, 2024 | CRA enters into force; the compliance clock starts |
| June 11, 2026 | Rules on notifying conformity assessment bodies begin applying |
| September 11, 2026 | Mandatory reporting of actively exploited vulnerabilities and severe incidents begins |
| December 11, 2027 | Full application: secure-by-design rules, CE marking, SBOM, and conformity assessment all become mandatory |
After December 11, 2027, any new product placed on the EU market must carry the CE mark and meet full CRA requirements; products already on the market before that date are generally grandfathered unless substantially modified.
Incident reporting timelines
From September 2026, manufacturers must follow a fixed reporting cadence for actively exploited vulnerabilities and severe security incidents:
- 24 hours: early warning notification
- 72 hours: full notification with technical detail
- 14 days: final report once a fix is available (for vulnerabilities)
- 1 month: final report for severe incidents
Reports go through a single EU platform coordinated by ENISA together with national CSIRTs. Organizations that wait until the deadline to build this workflow tend to scramble; the "who decides, who files, who communicates" runbook needs to exist well before an actual incident.
Core requirements
| Requirement | What it means in practice |
|---|---|
| Secure-by-design & secure-by-default | Ship products with safe default settings, minimal attack surface, and built-in update mechanisms, not security added after the fact |
| Software Bill of Materials (SBOM) | Document at least top-level dependencies in a machine-readable format (SPDX or CycloneDX), kept current and available to regulators on request |
| Vulnerability handling | Maintain a coordinated disclosure policy, a way to receive and triage reports, and free timely security updates |
| Incident & vulnerability reporting | Follow the 24-hour/72-hour/14-day/1-month reporting cadence from September 2026 onward |
| Conformity assessment & CE marking | Assess your product's risk tier, complete the matching assessment route, and affix the CE mark before selling in the EU |
| Documentation & lifecycle support | Keep versioned technical documentation and define a clear support period, typically at least five years |
Note that an SBOM is required to exist and be shared with regulators on request. It does not need to be published publicly.
How are products classified by risk?
Not every product faces the same level of scrutiny. The CRA sorts products into four tiers, and the tier determines how rigorous the compliance path is:
| Risk tier | Examples | Assessment path |
|---|---|---|
| Default | Majority of products, such as smart speakers or mobile games | Self-assessment is generally sufficient |
| Important Class I | Elevated-risk products like password managers or smart-home hubs | May use harmonized standards or a notified body |
| Important Class II | Higher-stakes products such as firewalls, VPNs, or intrusion detection systems | Require third-party assessment |
| Critical | Short list including hardware security modules and smartcards for secure elements | May eventually need EU-level certification |
Getting the tier right early shapes everything downstream: testing depth, documentation load, and how long certification takes.
What happens if a company doesn't comply?
Penalties are structured like GDPR's: the higher of a fixed amount or a percentage of global turnover, whichever bites harder.
| Violation type | Maximum penalty |
|---|---|
| Breaching essential cybersecurity requirements (Annex I) or core manufacturer duties | €15 million or 2.5% of global annual turnover |
| Other obligations (documentation, market access) | €10 million or 2% of global annual turnover |
| Providing false or misleading information to authorities | €5 million or 1% of global annual turnover |
Beyond fines, national market surveillance authorities can order product withdrawals, recalls, or outright bans from the EU market, and enforcement actions become public, which carries its own reputational cost.
How is the CRA different from NIS2?
This is one of the most common points of confusion, since both are EU cybersecurity laws that arrived around the same time. The short version: NIS2 regulates organizations, the CRA regulates products.
| NIS2 | Cyber Resilience Act | |
|---|---|---|
| What it governs | How critical-sector organizations operate and secure themselves | How products with digital elements are designed, built, and supported |
| Who it targets | Essential/important service operators (energy, health, finance, digital infrastructure, etc.) | Manufacturers, importers, distributors of connected hardware/software |
| Legal form | Directive, each member state transposes it into national law, so details vary by country | Regulation, directly binding across all 27 states, no local variation |
| Entered into force | January 16, 2023 | December 10, 2024 |
| Reporting obligation | Entity reports incidents to its national authority | Manufacturer reports product vulnerabilities/incidents to ENISA and CSIRTs |
| Maximum penalty | Up to €10 million or 2% of global turnover | Up to €15 million or 2.5% of global turnover |
A company can be subject to both at once. NIS2 governs how a business runs its operations, while the CRA governs the products it builds and sells, and the two obligations don't duplicate each other.
FAQs
Yes. Every in-scope product needs a machine-readable Software Bill of Materials covering at least top-level dependencies, kept up to date, and available to authorities on request, but it doesn't have to be made public.
Largely, yes, for the products it covers. The CRA harmonizes requirements across all EU member states, replacing the previously fragmented national approaches.
Any hardware or software whose intended or foreseeable use involves connecting, directly or indirectly, to a device or network. This spans IoT hardware, firmware, standalone software, mobile apps, and the cloud back-ends a product depends on.
The CRA expects a defined support period, typically a minimum of five years, during which security updates must keep flowing and users must be told when that support ends.
In enforcement structure, yes: turnover-based fines and an EU-wide reach beyond companies headquartered in Europe. In subject matter, no: GDPR protects personal data, while the CRA protects the security of digital products themselves.
Start by mapping which products qualify as PDEs, sorting them into risk tiers, and building the vulnerability-reporting runbook well ahead of the September 2026 deadline. Waiting until the deadline itself leaves little room for error.