CRA Penalties: Fines, Recalls and Enforcement

CRA penalties can reach EUR 15 000 000 or 2.5% of worldwide annual turnover, whichever is higher for undertakings. The Cyber Resilience Act gives market surveillance authorities two kinds of leverage: administrative fines, and product measures such as corrective action, withdrawal, recall, or restrictions on availability.

This page explains what those powers mean in practice and what evidence an economic operator should have ready before an authority asks.

What are the CRA penalty tiers?

The Regulation sets the EU-level maximums for administrative fines. Member States lay down the detailed penalty rules, but those rules must stay within the CRA framework and penalties must be effective, proportionate, and dissuasive.

Tier	Triggering breach	Maximum administrative fine
Tier 1	Non-compliance with Annex I essential cybersecurity requirements, or with the manufacturer obligations in Articles 13 and 14	EUR 15 000 000 or, for undertakings, 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher
Tier 2	Non-compliance with listed economic-operator, conformity, notified-body, and market-surveillance obligations, including Articles 18 to 23, 28, 30(1) to (4), 31(1) to (4), 32(1) to (3), 33(5), 39, 41, 47, 49, and 53	EUR 10 000 000 or, for undertakings, 2% of total worldwide annual turnover, whichever is higher
Tier 3	Supplying incorrect, incomplete, or misleading information to notified bodies or market surveillance authorities	EUR 5 000 000 or, for undertakings, 1% of total worldwide annual turnover, whichever is higher

The top tier is the one most manufacturers should understand first. It covers both the product-security substance in Annex I and the operational manufacturer duties in Articles 13 and 14: cybersecurity risk assessment, vulnerability handling, security updates, technical documentation, EU Declaration of Conformity, CE marking, support-period disclosure, and severe-incident or actively exploited vulnerability reporting.

Which breaches matter most?

The CRA does not rank every possible fact pattern. It sets legal brackets. In practice, the most serious exposure comes from failures that go to the product's cybersecurity substance, the truthfulness of the conformity claim, or the ability of authorities to assess risk.

Pattern	Why it matters	Likely legal area
Product placed on the EU market without meeting Annex I essential requirements	The product-security claim is wrong at source	Tier 1
No effective vulnerability-handling process during the support period	Annex I Part II and Article 13 duties are not operating	Tier 1
Failure to report a severe incident or actively exploited vulnerability when Article 14 applies	The reporting duty starts before the full regime	Tier 1
Wrong conformity route for an Important or Critical product	The Declaration of Conformity rests on the wrong assessment route	Tier 1 or Tier 2, depending on the obligation breached
Missing or invalid EU Declaration of Conformity, CE marking, or operator details	Market access documentation is defective	Tier 2
Misleading a Notified Body or market surveillance authority	Authorities cannot rely on the information provided	Tier 3, and potentially worse if other breaches are present

The safest way to read the tiers is not "which fine will we get?" but "which evidence must we be able to produce?" A signed Declaration of Conformity without a technical file, SBOM evidence, vulnerability-handling records, and conformity-assessment rationale is a fragile enforcement position.

How authorities decide the fine amount

The fine amount is not just a mechanical percentage calculation. When authorities set the amount, they must consider the infringement, whether the operator has previous similar fines, and the operator's size.

Factor	Practical meaning
Nature, gravity, and duration of the infringement and its consequences	A short-lived documentation gap is different from a shipped product with an exploitable design weakness.
Whether fines were already imposed on the same economic operator for similar infringements	Repeat conduct across Member States can aggravate the outcome.
Size of the economic operator and market share	Microenterprises, SMEs, and start-ups must be considered when fines are set.

That does not mean small operators can ignore the law. It means the penalty must be proportionate. A small manufacturer still needs a real conformity route, technical documentation, vulnerability-handling process, and Article 14 reporting capability where the duties apply.

Market surveillance powers beyond fines

Fines are not the only risk. CRA enforcement sits inside the EU market-surveillance framework, including Regulation (EU) 2019/1020. The CRA then gives the national-level procedure for products with digital elements that present a significant cybersecurity risk.

If an authority evaluates a product and finds non-compliance, it can require the relevant economic operator to take appropriate corrective action, bring the product into compliance, withdraw it from the market, or recall it within a reasonable period. If the operator does not take adequate corrective action, authorities can move to restrict or prohibit market availability.

Measure	What it means operationally
Corrective action	Fix the non-compliance, update documentation, remediate vulnerabilities, update instructions, or change the product before continued sale.
Withdrawal	Stop making the product available in the market. This usually affects unsold stock and distribution channels.
Recall	Retrieve or remediate products already supplied to users where the risk justifies it.
Restriction or prohibition	Limit or block the product's availability on the national market, with potential EU-wide consequences through coordination.

Article 57 also matters: a product can comply formally and still present a significant cybersecurity risk. In that case, authorities can still require measures to address the risk. Formal paperwork is not enough if the product remains risky.

What can trigger enforcement attention?

The CRA does not publish a fixed trigger list. Market surveillance can be proactive or reactive. These are the situations most likely to put a product on an authority's radar:

Trigger	What an authority will likely ask for
Actively exploited vulnerability or severe incident	Article 14 reporting evidence, vulnerability triage, affected versions, customer communications, remediation timeline.
Competitor, customer, or researcher complaint	Technical file, vulnerability-handling records, conformity assessment evidence, and product-security rationale.
Product sampling or sector campaign	EU Declaration of Conformity, user information, CE marking, SBOM evidence, and test evidence.
Import or distributor concern	Manufacturer identity, importer details, Declaration of Conformity, support-period information, and traceability records.
Inconsistent public claims	Evidence that marketing, support-period statements, security-update commitments, and the technical file match.

The enforcement risk is highest where the company cannot explain why the product is in scope, which role it plays, which conformity route it used, what evidence supports the Declaration of Conformity, and how vulnerabilities are handled during the support period.

What an authority request can look like

A market surveillance request is usually an evidence problem before it is a litigation problem. The exact request depends on the Member State, the product, and the risk, but a CRA-ready file should make these items retrievable:

Evidence area	Examples
Product identity and scope	Model, version, intended purpose, software/firmware versions, remote data processing solution, product class.
Conformity claim	EU Declaration of Conformity, applicable standards, conformity assessment module, Notified Body certificate where relevant.
Technical documentation	Annex VII technical file, cybersecurity risk assessment, architecture, tests, production controls.
SBOM evidence	Current SBOM, component scope, generation method, update process, supplier SBOM handling.
Vulnerability handling	CVD policy, security contact, triage records, remediation records, security-update process.
Article 14 reporting	Severe incident and actively exploited vulnerability decision logs, ENISA/CSIRT reporting records where applicable.
Support period	Disclosed support period, end-of-support date, update availability, customer notification records.

The practical test is simple: if an authority asks for the file today, can the team produce coherent evidence without reconstructing it from memory?

What to keep ready before a request arrives

Use this checklist before the first enforcement deadline:

Area	Ready state
Scope and role	You can explain why the CRA applies, which Article 3 role you play, and whether any Article 2 carve-out applies.
Product classification	You know whether the product is Default, Important Class I, Important Class II, or Critical.
Conformity route	You can justify Module A, B+C, H, or another permitted route.
Technical file	Annex VII evidence exists, is versioned, and matches the product sold.
Declaration and CE marking	The DoC is signed, accurate, and aligned with the evidence file.
SBOM	The SBOM is generated, maintained, and tied to shipped versions.
Vulnerability handling	Intake, triage, remediation, disclosure, and update delivery are operational.
Reporting	Article 14 decision-making and escalation are ready before 11 September 2026.
Communications	Customer, distributor, importer, and authority communications are documented.

SMEs, micro/small manufacturers, and open-source stewards

Smaller operators get important nuance, but not an exemption from CRA compliance.

Microenterprises, SMEs, and start-ups. When setting fines, authorities must consider the operator's size, including whether it is a microenterprise, SME, or start-up. That affects proportionality, not the existence of the underlying duty.

Micro and small manufacturers. Article 64(10)(a) exempts manufacturers that qualify as microenterprises or small enterprises from administrative fines for missing the 24-hour early-warning deadlines in Article 14(2)(a) and 14(4)(a). That relief is narrow: it concerns those specific deadline failures, not the full reporting duty and not other CRA obligations.

Open-source software stewards. Article 64(10)(b) exempts open-source software stewards from the administrative fines in Article 64(3) to (9). The steward regime is still real: Article 24 requires a cybersecurity policy and cooperation with market surveillance authorities on reasoned request. A downstream company that ships open-source software inside its own commercial product is usually a manufacturer for that product, not a steward.