How to prepare for the EU Cyber Resilience Act

If you sell a product with digital elements in the EU, the Cyber Resilience Act is now your problem, and the first deadline is closer than it looks. The fastest way to prepare is to get two things in place: a live picture of what you have shipped and the components inside it, and the ability to report and fix an actively exploited vulnerability within 24 hours. Everything else on the checklist supports those two capabilities.

This is the readiness guide, not a recap of the legislation. The two dates that matter, the artifacts an auditor will eventually ask for, and the work worth starting now.

What is the EU Cyber Resilience Act?

The Cyber Resilience Act, Regulation (EU) 2024/2847, is an EU law that makes cybersecurity a legal requirement for any product with digital elements placed on the EU market. It has been in force since December 2024. In plain terms, products must be secure by design, ship with no known exploitable vulnerabilities, and keep receiving security maintenance for as long as they are supported. The full breakdown of scope and obligations lives on our Cyber Resilience Act framework page.

Who needs to prepare?

Manufacturers, importers, and distributors of connected products sold in the EU, from consumer IoT to industrial and embedded devices. If your product has a digital element and reaches the EU market, assume it is in scope until you have confirmed otherwise. Products already governed by sector-specific regimes, such as medical devices, automotive, and aviation, follow those rules instead.

When are the CRA deadlines?

There are two dates to plan around, and they are not the same.

1. 11 September 2026 is when the reporting obligations apply. From that date, you must report actively exploited vulnerabilities and severe incidents within 24 hours.
2. 11 December 2027 is when the full set of essential requirements applies, including the secure-by-design and conformity-assessment obligations.

The reporting clock is first and it is the one most teams have done the least to prepare for. We go through both milestones in detail in the CRA timeline.

How do I prepare for the CRA?

Treat preparation as building two capabilities, then producing the evidence that proves you have them. Here is the work, in the order that pays off fastest.

1. Inventory what you have shipped. You cannot defend products you cannot see. Build a live list of every product, version, and deployment that is on the EU market.
2. Maintain a Software Bill of Materials. Generate an SBOM for each product so you know the components and versions inside it. This is the input that turns a new vulnerability into a list of affected devices. Our hands-on SBOM walkthrough covers how to produce one from a real firmware build, and the gap a build-time SBOM still leaves.
3. Wire up vulnerability monitoring. Watch sources like the EU Vulnerability Database and known-exploited feeds, and match new entries against your SBOMs so you can answer "which of my devices are exposed" without a fire drill.
4. Stand up a coordinated vulnerability disclosure process. Publish a way for researchers to report issues, and a security.txt, and define internally who triages and who decides.
5. Make the fix path fast. Secure update delivery, including to fielded and older devices, is what the 24-hour clock actually depends on. A report you cannot act on is not compliance.
6. Keep the evidence. Conformity assessment and incident reports both need a paper trail: the SBOM, the disclosure policy, the fix history, and the decision log. Produce it as you go, not the week before an audit.

The ship list of concrete artifacts, with worked examples, is in what the CRA actually requires from your ESP32 product.

What does the 24-hour reporting rule require?

The trigger is not every CVE. It is a vulnerability in your product that is being actively exploited, or a severe incident. Once you become aware of one, you have 24 hours to send an early warning to the relevant national CSIRT and ENISA, followed by a fuller notification and a final report. The hard part is operational: you have to already know whether your fielded devices, including old ones with no upstream fix, are exposed, and be able to respond under time pressure. That is why the inventory and fast-fix capabilities sit at the top of the checklist.

Do I need a notified body?

It depends on your product class. Default-class products can self-assess. Products in the "important" and "critical" classes require a third-party assessment by a notified body. Working out which class you are in changes how much lead time you need, so do it early. We walk through the decision in CRA conformity assessment, self-assessment or notified body.

What are the penalties?

Non-compliance with the essential requirements can draw fines of up to 15 million euro or 2.5 percent of worldwide annual turnover, whichever is higher. Authorities can also require a non-compliant product to be withdrawn from the EU market, which for most connected-product companies is the more frightening outcome.

Where Scadable fits

Scadable maps every device, deployment, and component you have shipped to the vulnerabilities that affect them, flags what is actively exploited, writes and backports the fix to fielded devices, opens the pull request, and files the report inside the window. It is the inventory, the matching, the fast-fix path, and the evidence trail from the checklist above, run continuously instead of as a one-time audit. If the CRA is on your roadmap, book a walkthrough and we will scope it to your products.

Frequently asked questions

When do I need to be ready for the CRA? Two dates matter. Reporting obligations for actively exploited vulnerabilities apply from 11 September 2026, and the full set of essential requirements applies from 11 December 2027. The reporting clock is the one most teams are unprepared for, and it arrives first.

What is the single most important thing to prepare? The ability to answer, within 24 hours, whether a vulnerability being actively exploited affects the products you have already shipped, and to push a fix. That operational capability, not the paperwork, is the hard part of the CRA.

Do I need a Software Bill of Materials for the CRA? Yes. The CRA expects you to maintain an SBOM as part of the technical documentation and to know the components inside the products you ship. It is the input that lets you map new vulnerabilities to affected devices.

Does the CRA apply to my product? If your product has digital elements and is sold in the EU, it is almost certainly in scope. Products covered by sector-specific rules, such as medical devices, automotive, and aviation, are handled under those regimes instead.

What happens if we are not ready in time? Non-compliance with the essential requirements can draw fines of up to 15 million euro or 2.5 percent of worldwide annual turnover, whichever is higher. Beyond fines, market-surveillance authorities can require a product to be withdrawn from the EU market.