What Is the Cyber Resilience Act? Could You Actually Be Fined?
Short answer: the Cyber Resilience Act, usually shortened to CRA, is an EU law that says software and connected devices sold in the EU must be reasonably secure, and that manufacturers must tell the authorities quickly when something goes wrong. It applies whether your company is based in Berlin, Madrid, or Amsterdam, and it applies just as much if you're outside the EU and simply sell into it. The rest of this guide is the detail behind that sentence: what counts as "connected," what "quickly" means in hours, and what happens if you miss it.
This is not legal advice. It's our honest reading of the regulation, written for people who have a product to ship, not a law degree. Where a number matters, we link the source so you can check it yourself.
Who Actually Has to Comply With the CRA
The CRA covers "products with digital elements," a deliberately broad category: hardware or software placed on the EU market that can connect, directly or indirectly, to another device or network. That includes a smart thermostat, a fitness app, a factory sensor, a payment terminal, and a code library your customers install. If it runs code and it talks to something else, it is very likely in scope.
Two categories are carved out because other rules already cover them in detail: medical devices and cars have their own sector-specific security regulations, so the CRA doesn't double-regulate them.
A useful comparison is a food ingredients label. Buy packaged food in the EU and by law you get a list of what's in it. Buy a router or a building-access controller, and until now you usually got a marketing brochure instead of an ingredients list. The CRA is the EU closing that gap for software.
Higher-risk product categories, called "important" or "critical" under the regulation, need an independent check before they can be sold: a notified body, meaning a certification organization accredited by a member state, has to review the product and confirm it meets the requirements before it can carry CE marking, the compliance mark you already see on European electronics and toys.
The Two CRA Deadlines That Actually Matter
The regulation has dozens of dates buried in it, but only two change what you have to do:
| Date | What happens |
|---|---|
| 11 September 2026 | Reporting obligations start. If you have an actively exploited vulnerability or a severe incident, the reporting clock described below applies from this date. |
| 11 December 2027 | Full application. Conformity assessment, technical documentation, and CE marking: the whole regulation is in force. |
Everything else, your software bill of materials, your vulnerability-handling process, your update policy, needs to already exist by the time these dates land, because building it in the two weeks before a deadline isn't realistic for most teams.
The CRA Reporting Clock: 24 Hours, 72 Hours, 14 Days
This is the part that surprises people, so it's worth being precise about it.
The clock doesn't start when a vulnerability is published, when it receives a CVE (Common Vulnerabilities and Exposures) identifier from the public catalog of known security flaws, or when a researcher writes about it. It starts the moment you, the manufacturer, become aware that a vulnerability in your product is being actively exploited, or that a severe incident has affected it. Awareness is the trigger, not disclosure and not publication.
From that moment:
- 24 hours: an early-warning notification to your national CSIRT (Computer Security Incident Response Team, the government cybersecurity response office in each member state) and to ENISA, the EU's cybersecurity agency, submitted through the CRA Single Reporting Platform. At this stage you're allowed to say you don't have all the details yet.
- 72 hours: a fuller notification covering what you know so far and, if relevant, what you're doing about it.
- 14 days after a fix or mitigation exists: a final report closing out the vulnerability. Severe incidents that aren't tied to a specific vulnerability follow a similar path, with a one-month final report instead.
A car recall is a useful comparison. If a manufacturer learns their brakes are failing in the field, they don't get to wait for a journalist to notice before telling the regulator. The CRA applies that same logic to software: once you know something is being actively exploited, staying quiet is itself the violation.
In practice, this means "we'll figure out our exposure when it happens" isn't a plan. You need to already know what's in your product, which is the entire point of a software bill of materials (SBOM), a machine-readable inventory of every component that ships. When a new CVE lands, answering "are we affected?" should take minutes, not a week of digging through old build logs.
Could You Actually Be Fined Under the CRA?
Yes, and the ceiling isn't small. Article 64 of the regulation sets three tiers, and the fine is whichever is higher between a flat euro amount and a percentage of your company's total worldwide annual turnover, the same structure GDPR uses if that comparison is familiar to you:
| Tier | Maximum fine | What it's for |
|---|---|---|
| Top tier | 15,000,000 euros, or 2.5% of worldwide turnover | Failing the essential cybersecurity requirements, or failing the vulnerability-handling and reporting obligations described above |
| Middle tier | 10,000,000 euros, or 2% of worldwide turnover | Various conformity, documentation, and procedural obligations, including registration, technical files, and cooperating with authorities |
| Lower tier | 5,000,000 euros, or 1% of worldwide turnover | Giving notified bodies or market surveillance authorities incorrect, incomplete, or misleading information |
Two exceptions matter for smaller teams:
- Microenterprises and small enterprises can't be fined specifically for missing the 24-hour and 14-day reporting deadlines. That doesn't exempt you from the CRA's other obligations; you still have to build a secure product and handle vulnerabilities properly. It just removes the clock-based fine for a late report.
- Open-source software stewards, meaning non-commercial foundations and maintainers broadly, are exempt from CRA fines entirely. They have separate, lighter obligations under a different part of the regulation.
Does the CRA Apply the Same Way in Every EU Country?
Mostly yes, and understanding why answers the question for any pair of countries you care about, whether that's Spain and the Netherlands or Portugal and France. The CRA is a regulation, not a directive. A directive sets a goal and each country writes its own national law to reach it, which is why something like data-retention rules can vary from country to country. A regulation applies directly, word for word, on the same day, in every member state. A company in Spain and a company in the Netherlands are reading the exact same Article 64. So are companies in Portugal and France.
What does vary by country is enforcement. Each member state has to designate its own market surveillance authority, the body that actually investigates and imposes fines locally. As of this writing, we couldn't find a public, confirmed list of which specific authority any of these four countries has designated for that role. The EU's own implementation tracker doesn't have it filled in yet either. If you need to know who to talk to in your country, check the European Commission's implementation page as designations land, rather than trusting a name in a blog post that may already be out of date by the time you read it.
Frequently Asked Questions About the Cyber Resilience Act
Does the CRA apply to software, or only physical devices? Both. "Products with digital elements" covers standalone software, such as a library or an app, as well as hardware that runs software and connects to a network.
What is a software bill of materials, and do I need one? A software bill of materials, or SBOM, is a list of every component inside a product: every library, every dependency, every version. You need one in practice even though the CRA doesn't use that exact word in every article, because you cannot answer "are we affected by this CVE" quickly without already knowing what's inside your own product.
Is the CRA the same law as NIS2? No. NIS2 sets cybersecurity obligations for operators of essential services and critical infrastructure. The CRA regulates the products themselves, wherever they're sold in the EU. Many companies will need to think about both.
My company is small. Am I exempt from the CRA? Not entirely. Microenterprises and small enterprises get relief from one specific fine, the one tied to missing the reporting deadlines, but the underlying security and documentation obligations still apply.
Read the Actual CRA Text
We've tried to be precise above, but we're a scanning-tool company, not a law firm. For anything you're making a real compliance decision on, go to the source:
- The regulation itself, Regulation (EU) 2024/2847, on EUR-Lex, the EU's official legal database.
- The European Commission's own plain-language summary.
- cyberresilienceact.eu, an independent reference site that tracks the regulation article by article.
If you're trying to answer "what's actually in our product" as a first step toward any of this, that's the part we handle. See how it works in practice in our post on why bomwerk never runs git on a repo it's scanning, or skip ahead: we'll scan one repository free and show you what a real SBOM looks like, gaps included.
Scanning a C/C++ repo and not sure what your SBOM is missing? We'll scan one repo free and show you the diff against whatever you run today.
Get a free scan of one repo