Cyber Resilience Act Fines and Penalties: What Non-Compliance Actually Costs

TL;DR
Cyber Resilience Act fines are tiered under Article 64, topping out at €15 million or 2.5% of worldwide annual turnover, whichever is higher. Market surveillance authorities can also order a product withdrawn or recalled across the EU, which usually costs more than the fine. The exposure most manufacturers miss: reporting obligations start on 11 September 2026 and they apply to products you already shipped, so top-tier fine risk arrives more than a year before "full compliance" is due.

Most articles about CRA penalties stop at the three-row fine table. That table is the easy part. The harder question is which products the fines attach to and when, and the answer surprises people: your installed base is already in scope for the highest tier.

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 withdrawal, recall, and lost EU market access.

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. For a manufacturer with a shipped fleet, that's often a bigger number than the fine itself, and it lands faster.

What are the maximum administrative fines under the EU Cyber Resilience Act?

Article 64 sets three tiers: €15 million or 2.5% of turnover, €10 million or 2%, and €5 million or 1%. The higher figure always applies.

The tiers track the seriousness of what you got wrong. Breach the security of the product itself and you're in the top tier. Get the paperwork or the supply chain roles wrong and you're in the middle. Mislead an authority and you're in the third.

Two details worth reading twice. The percentage is of total worldwide annual turnover for the preceding financial year, not EU revenue. And under Article 64(9), a fine can be imposed on top of a recall or withdrawal order for the same infringement, not instead of one.

What specific product vulnerabilities trigger the highest tier of CRA fines?

Shipping a product that breaches Annex I requirements triggers the top tier: known exploitable vulnerabilities, unchangeable default passwords, no update mechanism, or no security support.

Annex I is where the technical substance lives, and Article 64(2) puts every breach of it in the €15 million band. In practice the top-tier exposures cluster into a short list:

• Placing a product on the market with a known exploitable vulnerability in it
• Default credentials that can't be changed, or a configuration that ships wide open
• No mechanism to deliver a security update to the device once it's in the field
• No SBOM, or an SBOM that doesn't reflect the components actually in the shipped image
• No coordinated vulnerability disclosure policy, so there's no route for a researcher to reach you
• Missing an Article 14 reporting deadline, which sits in this tier too

That last one is the trap, and it deserves its own section.

Will Cyber Resilience Act fines be applied retroactively to older software products?

Partly. Products placed on the market before 11 December 2027 escape the essential requirements unless substantially modified. Article 14 reporting duties apply anyway.

This is the single most misread part of the regulation, and most summaries get it wrong by stopping halfway.

Article 69(2) is the grandfather clause everyone quotes: if a product was placed on the market before 11 December 2027, the CRA's requirements only bite if that product undergoes a substantial modification after that date. So far, so reassuring.

Then Article 69(3) takes it back. By explicit derogation from paragraph 2, the Article 14 obligations apply to all in-scope products placed on the market before 11 December 2027. Every unit. No modification needed.

Now stack three articles together:

1. Article 71 starts Article 14 on 11 September 2026, fifteen months before the rest of the regulation.
2. Article 69(3) applies Article 14 to your entire legacy fleet.
3. Article 64(2) puts Article 14 breaches in the top fine tier, €15 million or 2.5%.

The conclusion is uncomfortable and it's what nobody's saying plainly: from 11 September 2026, the products carrying the highest CRA fine exposure are the ones you shipped years ago. Not the ones on your 2027 roadmap.

And you can't report an actively exploited vulnerability within 24 hours if you can't answer a more basic question first: what's actually inside the firmware we shipped in 2021? That's not a legal problem or a process problem. It's an inventory problem. Our platform exists to give you that ground truth software inventory for shipped binaries, because a reporting workflow with nothing accurate behind it is just a form.

What are the penalties for failure to report a vulnerability under the Cyber Resilience Act?

Missing an Article 14 reporting deadline sits in the top fine tier: up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Article 14 sets four clocks, and they start when you become aware, not when you finish investigating.

Article 14(8) adds a duty people overlook: you also have to inform affected users, where appropriate in a structured, machine-readable format. That's a VEX-shaped requirement in everything but name, and it's why we treat reporting as a product capability rather than a compliance task. See how the platform supports rapid PSIRT vulnerability response.

Twenty-four hours is not a lot of time to determine whether a newly exploited CVE is even reachable in your shipped product. Teams that can answer that in an afternoon will report accurately. Teams that can't will either over-report, under-report, or miss the clock. All three are bad outcomes, and one of them is a €15 million bad outcome.

How are Cyber Resilience Act fines calculated for different company sizes?

The cap is whichever is higher: a fixed euro amount, or a percentage of worldwide annual turnover. Company size is then a mitigating factor.

That "whichever is higher" mechanic means the two halves of the cap bind different companies. A firm with €200 million turnover is capped by the fixed €15 million figure, because 2.5% is €5 million. A firm with €2 billion turnover is capped at €50 million, because the percentage overtakes the fixed amount. The fixed number protects nobody large.

Size then re-enters as a factor in setting the actual amount. Article 64(5)(c) requires authorities to give due regard to the size of the operator, specifically naming microenterprises, SMEs, and start-ups, along with market share. That's mitigation, not exemption.

Two real carve-outs do exist in Article 64(10):

• Open-source software stewards are outside the administrative fines for any infringement of the regulation. Their obligations still stand, but the fines don't attach.
• Micro and small manufacturers get relief on the reporting deadlines specifically, for failures to meet the deadline in Article 14(2)(a) or 14(4)(a), which are the 24-hour early warnings.

One caution on that second point. Article 64(10) opens by derogating from "paragraphs 3 to 9," while the Article 14 obligations are fined under paragraph 2. The published text is widely read as exempting small manufacturers from 24-hour deadline fines, and that's clearly the intent, but the paragraph numbering leaves an ambiguity a national implementing law could resolve either way. Worth a conversation with counsel rather than a planning assumption. [verify before publishing]

What are the "aggravating factors" that increase CRA fine amounts?

Article 64(5) names three: the nature, gravity, and duration of the infringement, prior fines for similar infringements, and the operator's size and market share.

The regulation doesn't actually use the phrase "aggravating factors." It lists circumstances that cut both ways, so the same three factors that raise a fine can lower it.

• Nature, gravity, and duration, including consequences. A vulnerability shipped for three years is worse than one shipped for three weeks. Actual exploitation is worse than theoretical exposure.
• Prior fines for a similar infringement, whether from the same authority or a different Member State's. Article 64(6) requires authorities to share fines they've applied through the information system under Regulation (EU) 2019/1020, so a second offence in a second country isn't a fresh start.
• Size and market share. Cuts toward mitigation for a start-up, toward aggravation for a market leader.

The practical read: duration is the factor you can influence most, and it's the one that rewards knowing what's in your products before an authority tells you.

Are Cyber Resilience Act penalties administrative fines or criminal penalties?

The CRA provides for administrative fines only. Member States write the national rules, and any criminal liability would come from national law, not the regulation.

Article 64(1) hands Member States the job of laying down penalty rules that are effective, proportionate, and dissuasive, then notifying the Commission. Article 64(8) allows those fines to be imposed by national courts or other competent bodies depending on the legal system, which is why some countries will route CRA fines through a court even though the fine itself is administrative in character.

So the honest answer to "can I go to prison for a CRA breach" is: not under the CRA. Whether existing national criminal law reaches the same conduct is a separate question, and it varies by Member State. [verify with counsel for specific jurisdictions]

Who is the market surveillance authority responsible for CRA fines?

Each Member State designates its own. Most are existing product-safety regulators, working alongside national cybersecurity agencies, CSIRTs, and ENISA on reporting oversight.

Article 52(2) requires every Member State to designate one or more market surveillance authorities, and lets them reuse an existing body rather than create a new one. In practice that means the CRA is enforced by the same kind of authority that already polices unsafe kettles and non-compliant radio equipment, because Regulation (EU) 2019/1020 on market surveillance applies to CRA products directly.

Three consequences worth planning around:

• Enforcement is product-safety flavoured, not privacy flavoured. Expect document requests, sweeps under Article 60, and technical evaluations of the shipped product, not complaint-driven investigations.
• Cyber expertise is borrowed. Article 52(5) lets authorities ask a CSIRT or ENISA for technical analysis when evaluating whether a product complies. The people reading your evidence may be very good at binary analysis.
• One authority, then all of them. Fines get shared across Member States under Article 64(6), and an ADCO group exists to keep application uniform, so a finding in one country travels.

If your product is also a high-risk AI system, Article 52(14) hands market surveillance to the authority designated under the AI Act instead.

What is the Cyber Resilience Act enforcement timeline, and is there a grace period?

There's no general grace period, just staggered start dates. Reporting duties start 11 September 2026. Everything else applies from 11 December 2027.

Article 71 sets the phasing, and it's worth being precise because several widely-shared summaries have these dates wrong.

Read that table as a sequencing instruction rather than a countdown. The reporting capability has to exist first, and it has to cover the fleet you've already shipped. The design-time and conformity work is what 2027 is for. Our step-by-step CRA preparation guide lays out the full order of operations.

How does the CRA penalty structure compare with GDPR?

GDPR's ceiling is higher: €20 million or 4% of turnover. The CRA's is lower, but it adds product recall and removal from the EU market.

Comparing the headline numbers alone gets you the wrong answer. The CRA's remedies are what make it bite.

For a device manufacturer, the CRA's lower ceiling is cold comfort. A GDPR fine is a cash event. A CRA withdrawal order is a revenue event, and it can outlast the fine by quarters.

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. Start with our EU Cyber Resilience Act overview if you need the regulation itself explained first.

Which products fall outside CRA fine exposure?

Medical devices, IVDs, motor vehicles, and civil aviation products sit outside CRA scope. Those products carry cybersecurity penalties under their own regimes instead.

Article 2 carves out categories already covered by other EU legislation, so a fine under the CRA is not a risk for them. That doesn't mean no risk, it means a different regime:

• Medical devices and IVDs: cybersecurity sits under the Medical Device Regulation and IVDR in the EU, and under section 524B of the FD&C Act in the United States. Enforcement runs through notified bodies and FDA premarket review rather than market surveillance fines.
• Motor vehicles: UN R155 type approval and ISO/SAE 21434, not the CRA.
• Cloud SaaS: outside scope, except remote data processing solutions that form part of a product with digital elements.
• National security, defence, and classified-information products: excluded.

One caution for medical device and automotive makers. The exclusion is product by product, not company wide. A connected gateway, a hospital-facing accessory, a companion app that isn't a regulated device function, or a component you sell separately can all land inside CRA scope while the regulated device beside it stays outside.

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 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, generated from what shipped rather than from the build manifest
• Run a gap analysis against the Annex I essential requirements, and get a CRA readiness assessment on your highest-exposure product lines
• Stand up a vulnerability handling and reporting process before 11 September 2026, covering products already in the field
• Fold security checks into your existing release workflow rather than bolting on a separate one
• Update supplier contracts to require the cybersecurity evidence you'll need from upstream

Procurement matters more than teams expect. Most of your Annex I exposure lives in components you didn't write, and you can't report on what a supplier won't tell you.

Compliance doesn't start with a transformation. It starts with knowing what you ship.

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