EU Cyber Resilience Act

TL;DR The EU Cyber Resilience Act (CRA) is the first EU-wide law that makes cybersecurity a mandatory feature of products with digital elements. It applies to manufacturers, importers, and distributors selling in the EU, including companies based outside it. The CRA entered into force in December 2024, vulnerability reporting starts September 11, 2026, and all requirements apply from December 11, 2027. Miss them and fines reach €15 million or 2.5% of global turnover.

For years, connected products shipped with weak security and little accountability for what happened after the sale. A flaw in one device could open a door into an entire network, and buyers had almost no way to tell a secure product from a careless one. When everything connects, everything becomes a potential target. The EU Cyber Resilience Act is the bloc's answer to that problem.

This guide explains what the CRA is, why it exists, who it touches, and what you actually have to do. One idea runs through all of it: the CRA isn't a certificate you earn once and frame on the wall. It makes security a continuous product feature, something you build in at design time and sustain for the product's whole supported life. Treat it as a last-minute scramble before launch and it's painful. Treat it as a continuous workflow grounded in what you actually ship, and the compliance evidence falls out as a byproduct of building good products.

What is the EU Cyber Resilience Act?

The EU Cyber Resilience Act is the first EU-wide law that makes cybersecurity mandatory for products with digital elements across their entire lifecycle, before and after they're sold.

Formally, it's Regulation (EU) 2024/2847. A "product with digital elements" means almost anything with software, firmware, or a remote data processing component: laptops, routers, smart home devices, industrial control systems, mobile apps, operating systems, even software libraries and components sold on their own. The CRA is horizontal, meaning it applies across every industry rather than to one sector, and it's technology-neutral, setting security outcomes rather than dictating specific tools. Until now, most of these products fell under no EU cybersecurity law at all. The CRA closes that gap and puts the responsibility on the people who make and sell the product.

Why did the EU introduce the Cyber Resilience Act?

The EU introduced the CRA to fix weak, inconsistent product security: too many vulnerable connected products, too few timely updates, and too little transparency for buyers.

The old landscape was a patchwork. Some products were covered by sector rules, most weren't, and non-embedded software fell through the cracks entirely. That left two problems the CRA names directly: products shipped with widespread vulnerabilities and inconsistent security updates, and buyers had no reliable way to judge a product's security before purchasing. The cost of that gap is real. Incidents like the WannaCry ransomware outbreak and the Kaseya supply chain attack showed how a single weak link can cascade across borders and organizations in minutes. The CRA's goal is to raise the floor for everyone and make security a condition of market access, not an optional extra.

Who does the Cyber Resilience Act apply to?

The CRA applies to manufacturers, importers, and distributors of products with digital elements sold in the EU, including companies based outside the EU whose products reach the EU market.

The manufacturer carries the heaviest load, since you're the one who designs the product, declares its conformity, and handles its vulnerabilities. Importers and distributors have their own duties to check that what they're placing on the market carries the right marking and documentation. Location is no escape: if you ship into the EU from anywhere in the world, the CRA applies the moment your product hits the market. A handful of product categories are carved out because other EU laws already govern their cybersecurity, including motor vehicles, medical devices, and certain aviation and marine equipment. Everything else with a digital element is in scope.

What is the Cyber Resilience Act timeline and key dates?

The CRA entered into force in December 2024. Vulnerability reporting begins September 11, 2026, and all remaining requirements apply from December 11, 2027.

The rollout is phased on purpose, giving the reporting duties an earlier start than the full obligations. These are the dates that matter.

The September 2026 date is the one teams underestimate, because it lands more than a year before the headline deadline and applies retroactively to products already on the EU market.

What does the Cyber Resilience Act require?

The CRA requires products to be secure by design, to ship without known exploitable vulnerabilities, to receive security updates across their support period, and to document everything for authorities.

The obligations split into two halves, both in Annex I of the regulation. The first half is about how the product is built. The second is about how you handle problems after it ships.

Security by design

Products must be designed and built to a baseline of security: no known exploitable vulnerabilities at release, secure default configurations, protection of data confidentiality and integrity, a minimized attack surface, and the ability to be updated securely. The principle is that security is engineered in from the start, not bolted on at the end.

Vulnerability handling and security updates

After launch, manufacturers must identify and document vulnerabilities (including by maintaining an SBOM and technical documentation), fix them without delay, and provide security updates for the product's support period. That period reflects how long the product is expected to be in use, which for most products means at least five years, with technical documentation kept for ten [verify before publishing]. This is the heart of the CRA: security as an ongoing commitment, not a one-time gate.

How does the CRA classify products, and what are critical products?

The CRA sorts products into four risk tiers: Default, Important Class I, Important Class II, and Critical. The tier sets how rigorous the conformity assessment has to be.

The logic is to scale scrutiny to risk. The Default tier covers the large majority of products, around 90% by the Commission's estimate [verify before publishing], and includes things like smart speakers and photo-editing apps. Important Class I covers security-relevant products such as password managers, network management systems, and routers. Important Class II raises the bar further with products like firewalls and intrusion detection systems. The Critical tier covers the highest-stakes products, such as hardware security modules and smart meter gateways. Crucially, every tier has to meet the same essential requirements. The tier only changes how you prove it.

What are the conformity assessment and CE marking requirements?

Most products self-assess and apply CE marking. Higher-risk products need a third-party assessment. The CE mark now signals that a product meets the CRA's cybersecurity requirements.

CE marking isn't new, but the CRA adds cybersecurity to what it certifies. To apply it, you run a conformity assessment, the formal check that your product meets the essential requirements, then issue an EU Declaration of Conformity. Default and most Important Class I products can self-assess. Important Class II and Critical products must involve an accredited third-party body, and Critical products generally go through a European cybersecurity certification scheme. We cover the full breakdown in our guide to CRA conformity assessments.

How do you report vulnerabilities under the Cyber Resilience Act?

Manufacturers must report actively exploited vulnerabilities and severe incidents through the ENISA platform: a 24-hour early warning, a 72-hour notification, and a 14-day final report.

This obligation, in Article 14, is the first one with real enforcement teeth, and it starts in September 2026. Once you become aware of an actively exploited vulnerability or a severe incident in an in-scope product, the clock starts. You file an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days of a fix being available (one month for severe incidents). Reports go to your national CSIRT and ENISA through a Single Reporting Platform. To hit a 24-hour window, you need to know what's in your products and watch for exploited components continuously, which is why exploitability-based prioritization matters so much here.

How does the CRA treat open source software?

The CRA largely exempts open source software developed and supplied outside a commercial activity. It introduces an "open-source software steward" role with lighter obligations for those supporting commercial-use FOSS.

This was one of the most debated parts of the regulation, because so much of modern software is built on free and open source components. The drafters drew the line at commercial activity: a hobbyist or nonprofit maintainer isn't a manufacturer under the CRA, but the company that commercializes open source code in a product is responsible for its compliance. The new "steward" category sits in between, placing duties like cooperating with market surveillance on organizations that systematically support open source intended for commercial use, without treating them as full manufacturers.

What are the penalties for non-compliance with the CRA?

Non-compliance can cost up to €15 million or 2.5% of global annual turnover, whichever is higher, plus product recalls and removal from the EU market.

The fines are tiered by how serious the breach is, and authorities have powers beyond money. Market surveillance authorities can order a product withdrawn or recalled across the EU, which is often a bigger cost than the fine itself.

How is the CRA different from NIS2 and GDPR?

The CRA secures products, NIS2 secures the organizations running essential services, and GDPR protects personal data. They overlap, but each answers a different question.

People conflate these three constantly, so it's worth being precise. The CRA is product-centric: it asks whether the thing you sell is secure. NIS2 is entity-centric: it asks whether an essential or important organization, like an energy utility or a hospital, manages its operational security and reports incidents. GDPR is data-centric: it asks whether you protect people's personal data. A connected device maker can easily fall under all three at once. The good news is that the evidence overlaps. A strong product security program built for the CRA feeds directly into the operational and data obligations of the others, so the work compounds rather than duplicates.

How can a small business or SME prepare for the Cyber Resilience Act?

Start by inventorying your products, classifying each into its CRA tier, finding the gaps, and standing up vulnerability handling, all well before the December 2027 deadline.

You can't prove conformity for products you haven't mapped, so preparation begins with a clear system of record. For a small team on a budget, the priorities are practical: build an accurate software inventory and SBOM for each product, run a gap analysis against the essential requirements, set up a vulnerability handling and reporting process before September 2026, and fold security checks into your existing release workflow rather than adding a separate one. Procurement matters too, so update supplier contracts to require the cybersecurity evidence you'll need from upstream. Our step-by-step CRA preparation guide lays out the full sequence.

Conclusion

The CRA is a significant shift, but the core idea is simple. Security is now a feature you ship and maintain, not a box you tick before launch. The regulation asks you to know what's in your products, fix what's exploitable, keep proving it across the product's life, and be ready to report fast when something goes wrong.

The companies that struggle will be the ones treating December 2027 as a one-time deadline. The ones that thrive will build the continuous, evidence-backed habits the CRA rewards, and produce compliance as a byproduct of doing product security well.

Want to see what continuous, audit-ready CRA evidence looks like in practice? Request a CRA walkthrough.