What are the Cyber Resilience Act penalties and how are they enforced?
Article 64 of the Cyber Resilience Act sets maximum administrative fines in three tiers: EUR 15 million or 2.5% of total worldwide annual turnover for breaches of the Annex I essential requirements and the Article 13 and 14 duties, EUR 10 million or 2% for other listed obligations, and EUR 5 million or 1% for incorrect, incomplete or misleading information given to authorities. For undertakings, the higher of the two figures applies. National market surveillance authorities enforce these fines, and Member States set their own penalty rules and notify them to the Commission. The maximum is a ceiling, not the amount that will be imposed. Authorities must weigh the nature, gravity and duration of the infringement, any previous fines for similar breaches, and the size and market share of the operator, with particular regard to microenterprises and SMEs. Fines can also run alongside corrective, restrictive or recall measures for the same infringement. Your first step is to confirm which tier each of your likely breaches falls into and which national authority would act, since that answer depends on your Member State and product category.
Timing matters here. The Article 14 reporting obligations have applied since 11 September 2026, so a manufacturer whose reporting process is not running today already carries exposure. Most other obligations apply from 11 December 2027, which gives you a window to fix product requirements, but the penalty tiers attach to the breach itself, so you should not treat that date as a deadline for documentation or record keeping that authorities could request earlier. Ask your legal team to confirm the national penalty rules for each market you sell into, and ask any implementation partner or notified body to explain in writing which evidence would show an authority that you acted in good faith and in a timely way.
Which breach carries which maximum fine
This table compares the three tiers of maximum administrative fines in Article 64 of the Cyber Resilience Act, showing which breaches fall into each tier. Read each row as a ceiling, not a set penalty: the amount an authority imposes depends on the factors in Article 64(5), and the cap is the higher of the fixed sum and the turnover percentage for undertakings.
| Breach category | Maximum fine | Whichever is higher (undertakings) |
|---|---|---|
| Annex I essential requirements and Articles 13 and 14 (Article 64(2)) | EUR 15 million | EUR 15 million or 2.5% of total worldwide annual turnover for the preceding financial year |
| Articles 18 to 23, 28, 30 to 33, 39, 41, 47, 49 and 53 (Article 64(3)) | EUR 10 million | EUR 10 million or 2% of total worldwide annual turnover for the preceding financial year |
| Supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities in reply to a request (Article 64(4)) | EUR 5 million | EUR 5 million or 1% of total worldwide annual turnover for the preceding financial year |
| Maximums only, not fixed amounts | Set case by case | Authorities weigh gravity, duration, prior fines and operator size under Article 64(5) |
How authorities decide the fine amount
Authorities do not apply the maximum fine automatically. Under Article 64(5), they must consider the nature, gravity and duration of the infringement, any previous fines imposed for similar infringements, and the size and market share of the operator, with particular regard to microenterprises and SMEs. For a manufacturer, that means a fine for a missing or late Article 14 notification, or for a gap against an Annex I requirement, will be sized against how many products were affected, how long the gap lasted and whether the company had already been warned. Ask your own team to put a number on each of these points before an authority asks. A single product line with a short, contained issue reads very differently from a fleet of products exposed for years.
Fines can also run alongside other measures. Article 64(9) allows a fine to be imposed in addition to corrective or restrictive measures for the same infringement, so a product that is ordered corrected, withdrawn or recalled may still attract a fine. Article 64(6) requires authorities to share the fines they apply with other Member States through the market surveillance information system, so a penalty in one country is visible to the authorities in the others. Treat any enforcement letter as a multi-market matter from the start, and keep your responses consistent across every national authority you deal with.
Your strongest mitigating evidence is a record of how you behaved, not how you describe yourself. Keep dated records of when each known vulnerability was identified, when a fix or mitigation was released, how quickly customers were informed, and why any step took longer than planned. Record which Article 14 notifications were filed and when, and which decisions were taken by whom. Confirm with counsel which of these records must be produced on request and how long they should be kept, and check whether your size category qualifies you for the protections in Article 64(5) and Article 64(10). Records made at the time of each event will carry far more weight than reconstructions written after an inspection.
Who is exempt or treated differently
The Cyber Resilience Act does not treat every operator the same way when it comes to fines. Some exemptions cover specific breaches, some depend on company size, and some depend on who decides whether a fine can be imposed at all. Each carve-out narrows one part of the penalty regime, so check each one against your own status.
Microenterprises and small enterprises
Under Article 64(10), microenterprises and small enterprises cannot be fined for missing the 24-hour early warning deadline in Article 14. The exemption is narrow. It does not cover late full notifications, missed final reports, or any other Article 14 failure, and it does not reduce the duty to notify. Confirm your headcount and turnover against the Article 3 definitions before you rely on it, and set up reporting to meet the deadline anyway.
Open-source software stewards
Article 64(10) exempts open-source software stewards from fines for any infringement of the regulation. This is the broadest fine exemption in the penalty rules, but it applies only to stewards as the regulation defines them, not to every maintainer or company that publishes code. Whether you qualify depends on your role in the open-source project, so confirm it under the scope rules before assuming protection from fines.
Public authorities
Under Article 64(7), each Member State decides whether public authorities and bodies established in its territory can be subject to administrative fines. Public bodies in one country may face fines while those in another may not. If you are a public sector manufacturer or deploy products for a public body, check the national penalty rules that the Member State has notified to the Commission under Article 64(1).
Courts imposing fines
Under Article 64(8), Member States may provide that fines are imposed by courts rather than directly by the market surveillance authority. The procedure, the decision-maker and the appeal route can therefore differ by country. Organizations selling across several Member States should map which authority or court handles each case, since the enforcement path affects how quickly a fine can follow a finding.
Small and medium enterprises in the amount
Article 64(5) does not exempt SMEs from fines. It requires authorities to consider the size and market share of the operator when setting the amount, with particular regard to microenterprises and SMEs. The ceiling is the same as for larger firms, so a smaller company can still face a fine that matters to its business. Keep records of your size, revenue and market position in case you need to show them to an authority.
Exemptions do not remove duties
An exemption from a fine does not exempt you from the obligation itself. A microenterprise still has to meet the Annex I essential requirements, and a steward still has to meet the duties that apply to it. Authorities can still order corrective action, withdrawal or recall under Article 54 whatever your size or status. Confirm your status under the scope rules first, then plan compliance as if no exemption applied.
Corrective action, withdrawal, recall and sweeps
Under Article 54, a market surveillance authority that finds a product with digital elements presenting a significant cybersecurity risk, where the product does not comply with the regulation, can require the economic operator to take corrective action, withdraw the product or recall it. If the authority also prohibits or restricts the product on its national market, and the measure is not challenged, it can be extended across the EU. The trigger is a finding of significant risk plus non-compliance, which is a higher bar than a paperwork gap. The authority's likely first step is a request for information and a technical review of the product and its risk assessment.
- Trigger: a documented finding that the product presents a significant cybersecurity risk and does not meet the essential requirements.
- Likely action: corrective action first, then withdrawal or recall from the market or from end users if the risk persists.
- EU-wide effect: a national prohibition or restriction can extend across the EU when no objection is raised.
- What to keep ready: the Annex I risk assessment, vulnerability handling records, the support period definition and a dated patch history.
- Operational plan: a tested process for pushing fixes, notifying customers and pulling affected versions from distribution.
Confirm with your national market surveillance authority how it expects recall notices and customer communications to be delivered for your product type.
Article 58 covers formal non-compliance, meaning defects that can be fixed on paper or in the product's labeling rather than in its security design. Examples include a missing CE marking, a missing or incorrect EU declaration of conformity, or incomplete technical documentation. The authority must act on these findings. If the non-compliance persists, the authority can restrict or withdraw the product. These cases are often easier to resolve than substantive security failures, but they are also easy to miss in a fast release cycle.
- Trigger: a product is placed or kept on the market without the required CE marking, declaration or technical documentation.
- Likely action: a request to correct the formal defect within a set period, followed by restriction or withdrawal if it is not fixed.
- Common gaps: declarations that reference an old software version, documentation that does not cover the current release, or product labels that omit required information.
- What to keep ready: a versioned EU declaration of conformity, a current technical file index and a release checklist that checks marking and documentation before each shipment.
- Ownership: assign one person to confirm that each released version has matching documentation.
Check the declaration and documentation requirements against the conformity route for your product class before you assume the paperwork is complete.
Article 60 requires authorities to run coordinated sweeps, which are checks on a particular product or category of products across several Member States at the same time. Sweeps can include inspections of products bought under a cover identity, so that authorities test what a customer actually receives rather than what the manufacturer submits. ENISA can propose sweeps based on Article 14 notifications, which means reports of actively exploited vulnerabilities and severe incidents can help target where authorities look.
- Trigger: a category of products is selected for a coordinated check, or ENISA identifies a pattern in Article 14 notifications.
- Likely action: purchase of products for testing, review of documentation and tests of the firmware or software as shipped.
- Cover-identity checks: products may be bought through ordinary retail or download channels without disclosure to the manufacturer.
- What to keep ready: consistent builds across sales channels, release records that match what is sold and a reporting record for every Article 14 notification.
- Consistency: ensure the version in your download store, distribution partners and update server matches your documented release.
Ask your market surveillance authority whether it has announced any sweep that covers your product category.
Article 65 applies the representative actions directive, Directive (EU) 2020/1828, to infringements of the Cyber Resilience Act that harm or may harm the collective interests of consumers. This means qualified entities, such as consumer organizations designated under that directive, can bring collective actions on behalf of a group of consumers. The exposure is not limited to regulator fines. A product flaw affecting many users can lead to a collective claim even where the authority takes no action.
- Trigger: an infringement that harms or may harm the collective interests of consumers, such as a widely deployed product with an unpatched flaw.
- Likely action: a collective claim brought by a qualified entity under national law implementing the directive.
- Who can claim: the designation and the national procedures are set by each Member State, so confirm the rules in each market where you sell.
- What to keep ready: a complete list of affected product versions, support period statements, dated customer notices and evidence of the fixes provided.
- Legal review: involve counsel early when a vulnerability affects a large installed base.
Confirm with qualified legal advice how the directive is implemented in each Member State where your product is used.
How an enforcement case usually unfolds
The sequence runs from a product check or complaint through information requests, corrective measures and possible fines, and ends with the outcome being shared across Member States. Each step produces a record the operator can review and answer.
Authority checks a product or receives a report
A national market surveillance authority starts a case in one of three ways: it checks a product on its own initiative, it receives a complaint, or it receives a notification of a vulnerability or incident. Sweeps coordinated under Article 60 can also bring a product into view, including purchases made under a cover identity. The operator usually learns of the case when the authority writes to it, so the first useful output is an internal record showing which products, versions and EU market placements are involved.
Authority requests information from the operator
The authority asks the operator for documents and explanations, such as the technical documentation, the EU declaration of conformity, the risk assessment and evidence of the vulnerability handling process. The reply must be complete, accurate and not misleading. Under Article 64(4), supplying incorrect, incomplete or misleading information in reply to a request can draw its own fine, so the operator should confirm in writing what it has sent and keep a copy of every answer.
Authority establishes non-compliance
Based on the material it holds, the authority decides whether the product or the operator is non-compliant. Formal failures, such as a missing CE marking, a missing or incorrect EU declaration of conformity or incomplete technical documentation, are handled under Article 58. Substantive concerns about a product presenting a significant cybersecurity risk are handled under Article 54. The operator should expect a written finding that identifies the requirement at issue, which gives it the basis for a response.
Operator responds and corrects the product
The operator sets out its position and, where the finding is valid, carries out corrective action so the product complies or the non-compliance stops. Corrective action can include fixing a vulnerability, updating documentation, correcting a declaration or informing users. Evidence of this step is a dated corrective action record with the changes made, the versions affected and the date the operator considers the issue closed, which the authority can check.
Authority orders withdrawal, recall or restriction
If the product remains non-compliant, or the risk is not addressed, the authority can require the operator to take corrective action, withdraw the product from the market or recall it from end users. Under Article 54 it can also prohibit or restrict the product nationally. If the measure is not challenged, the authority can extend it across the EU. Under Article 58, if formal non-compliance persists, the authority restricts or withdraws the product. The operator should confirm in writing which products are covered and what its distributors and customers must be told.
Authority may impose a fine alongside measures
Where the infringement warrants it, the authority can impose an administrative fine in addition to the corrective or restrictive measures for the same infringement, under Article 64(9). The amount is capped by Article 64 at the higher of a fixed sum and a share of worldwide annual turnover, and the authority considers the nature, gravity and duration of the infringement, previous fines, and the size and market share of the operator. Member States decide whether courts impose the fine (Article 64(8)). The operator's output is a record of the decision and any payment or appeal steps under national law.
Fines and outcomes shared across Member States
Applied fines are shared with other Member States through the market surveillance information system under Article 64(6), so an outcome in one country becomes visible to authorities elsewhere. Representative actions under Article 65 can also follow where the infringement harms or may harm collective consumer interests. The operator should expect the outcome to be known beyond the authority that opened the case, and should keep its compliance file consistent across all EU markets where its products are sold.
What reduces exposure before an authority calls
Market surveillance authorities tend to start with paperwork and reporting before they look at a product in depth. The cards below cover the records and routines the manufacturer must hold itself, since fines under Article 64 turn on how the organization performed, not on how well a partner prepared the files. An implementation partner can build systems and assemble evidence, but only the organization is accountable for conformity.
Documented cybersecurity risk assessment
The risk assessment is the starting point for choosing which Annex I essential requirements apply to each product and how each one is met. Authorities look for a version dated before the product was placed on the market, a clear link from identified risks to the controls chosen, and written reasons for any requirement judged not applicable. Check that the assessment is reviewed when the product changes, not only once at launch. An assessment that cannot be traced to controls is the first gap an inspector will test.
Working vulnerability handling and reporting route
Annex I Part II requires a process for handling vulnerabilities across the support period, and Article 14 requires notification of actively exploited vulnerabilities and severe incidents. Since 11 September 2026, the reporting duty has been enforceable, so the route must work today. Confirm who receives vulnerability reports, who decides whether a report is reportable, and how the team meets the 24-hour early warning deadline through ENISA's Single Reporting Platform. A reporting route that exists only on paper will not meet the deadline.
Complete technical documentation and EU declaration
Technical documentation must show how the product meets the essential requirements, and the EU declaration of conformity must be complete, correct and kept available for the authority. Formal non-compliance, such as a missing declaration or incomplete documentation, can lead to action under Article 58 even when the product itself is sound. Check that the declaration names the right product, version and conformity route, and that the documentation is held for the period the regulation requires. An incomplete file is the most common reason a product is restricted without a technical defect.
Correct CE marking on each product
The CE marking must appear on the product, or where that is not possible, on its packaging or accompanying documents, and it must follow the rules set out in the regulation. A missing or wrongly placed marking is formal non-compliance that market surveillance authorities can act on under Article 58. Check each product variant, each firmware release and each distribution channel, including products sold through marketplaces. A marking applied to the wrong variant creates the same exposure as no marking at all.
Dated record of fixes and security updates
Authorities assess the nature, gravity and duration of an infringement, so a dated record of vulnerabilities found, fixes shipped and users informed shows how long a problem lasted. The record should tie each fix to the product version it reached and to the support period the manufacturer committed to. Keep the record in a system that cannot be silently edited. Missing dates make it hard to show that a problem was handled promptly, and undated fixes leave the manufacturer unable to answer the authority's first question.
Written answer on scope and status
Before an authority asks, the organization should be able to state which products it places on the EU market, which role it holds for each (manufacturer, importer, distributor or steward), and why any product is outside the regulation. Whether a product is in scope, and whether a later change makes it substantially modified, both affect which obligations apply. Record the reasoning and the date it was reviewed. An unexplained exclusion invites the authority to test the product against every requirement.
What to confirm with counsel and your national authority
The most important point is that the fine framework in Article 64 is applied through national rules. Member States set their own penalty rules and notify them to the Commission, and they decide whether public authorities can be fined and whether fines are imposed by administrative authorities or by courts. Before you rely on any enforcement picture, confirm the exact procedure with the market surveillance authority in each market where your product is sold. Ask it how it intends to start a case, what response window it gives an economic operator, which body issues the decision, and how an appeal works. A single EU-level figure does not tell you how a case will run in a given country.
Take the regulation text to counsel rather than relying on summaries. Confirm the current status of every fine ceiling, exemption and cross-reference against the consolidated text of Regulation (EU) 2024/2847 on EUR-Lex, including the Article 64 exemptions for microenterprises, small enterprises and open-source software stewards. Ask counsel how a fine would interact with your customer contracts, including liability caps, indemnities and warranties on security updates, and whether a regulatory fine is insurable under your current cyber or product liability policies. Ask whether a fine can sit alongside a collective redress claim under the representative actions framework that Article 65 applies, and how your contracts allocate that exposure.
Put the questions in writing and keep the answers with your technical evidence. Ask counsel which parts of your position depend on a national choice, such as whether your Member State fines public bodies, and which parts follow directly from the regulation. Ask your market surveillance authority which of its enforcement actions are likely to be targeted at your product category, and what it expects to see when it asks for technical documentation. Record the date of each answer, since national rules and guidance may change before the regulation applies from 11 December 2027.
Questions buyers ask about CRA fines
What is the maximum fine under the Cyber Resilience Act for my product?
The ceiling depends on the type of breach, not the product. Under Article 64(2), non-compliance with the Annex I essential requirements or the obligations in Articles 13 and 14 can reach EUR 15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Other listed obligations under Article 64(3) reach EUR 10 million or 2%, and supplying incorrect, incomplete or misleading information to authorities under Article 64(4) reaches EUR 5 million or 1%. For a large group, the turnover percentage usually sets the ceiling. Confirm with your legal team which breach categories your products could trigger and how your turnover is calculated under the regulation.
Is a CRA fine a flat amount or a percentage?
Neither figure is applied automatically. Each Article 64 amount is a maximum, and the fine is set case by case. Under Article 64(5), authorities must consider the nature, gravity and duration of the infringement, any previous fines for similar infringements, and the size and market share of the operator, with particular regard to microenterprises and SMEs. A short, contained failure that you fixed quickly will generally be treated differently from a long-running gap affecting many products. Member States also set their own penalty rules under Article 64(1), so the procedure and the practice of each national market surveillance authority should be checked for the markets you sell into.
Am I exempt from CRA fines as an SME or open-source steward?
Exemptions are narrow, and you should confirm your own status. Under Article 64(10), microenterprises and small enterprises are exempt from fines for missing the 24-hour early warning deadline in Article 14. Open-source software stewards are exempt from fines for any infringement. Other SMEs get no blanket exemption, but Article 64(5) requires authorities to consider their size when setting an amount. Being an SME does not remove the underlying obligations, and the exemptions do not cover the product requirements in Annex I. Whether you are a steward, a manufacturer or both depends on your role for each product, so classify your roles before relying on an exemption.
Can authorities impose a CRA fine without ordering a recall?
Yes. Under Article 64(9), a fine can be imposed alongside corrective or restrictive measures for the same infringement, but the regulation does not require a recall before a fine. Authorities can act on formal non-compliance under Article 58, such as a missing CE marking, a missing or incorrect EU declaration of conformity, or incomplete technical documentation, and restrict or withdraw the product if the problem persists. Under Article 54, a product presenting a significant cybersecurity risk can face corrective action, withdrawal or recall, followed by national prohibition or restriction. Article 60 also allows coordinated sweeps, including inspections of products bought under a cover identity.
Do I need outside help to avoid CRA penalties?
Outside help can reduce the chance of a breach, but it does not transfer legal liability. The manufacturer or other economic operator owns its compliance decisions and the evidence behind them. An implementation partner can prepare systems, documentation and evidence, and an independent assessor or notified body can perform conformity assessment where the regulation requires it. Only those independent bodies issue reports or certificates. Before engaging anyone, ask for the written scope, the deliverables you will own, and which decisions remain with your organization. Ask your legal counsel how the engagement affects your position under Article 64.
How long before CRA enforcement applies to my products?
It depends on the obligation. Article 14 reporting has been enforceable since 11 September 2026, and it applies to in-scope products whenever they were placed on the market. Most other requirements apply from 11 December 2027, under Article 71(2). Products already on the EU market before 11 December 2027 fall under the regulation only if they are substantially modified from that date. Because the Article 14 duty is already live, the first question is whether your reporting process works today. Confirm the dates for each obligation against the regulation text and your own product history.
How DeployOpen helps you prepare evidence before an authority asks
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the records an authority might request exist before anyone asks for them. We prepare systems, controls and evidence for your readiness work, while your organization owns its controls and independent assessors issue any conformity or certification outcome.
How we scope
- Agree in writing which products, release lines and business roles the engagement covers before work starts.
- Map which Annex I requirements and Article 14 duties each in-scope product must evidence, with the scope recorded in the agreement.
- Confirm with your legal team which national market surveillance authorities and sector rules apply, and list them as open items.
How we build
- Configure logging, access control and update pipelines so that records of vulnerability handling and product changes are kept as routine output.
- Set up documented procedures for vulnerability intake, triage and user notification, so decisions are traceable to a named owner and date.
- Test the controls against the written requirements and record gaps, fixes and retest results in a form an assessor can review.
How we hand over
- Deliver the technical documentation, control records and test evidence in a structured index your team can maintain after handover.
- Document configuration baselines, runbooks and an evidence register that shows where each record lives and who reviews it.
- Provide a short walkthrough so your compliance and engineering staff can answer an authority's questions from the records.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial engagement.
- Ask any partner to state in writing who issues fines, orders or certifications, and confirm that role stays with your organization and regulators.
- Review the evidence register on a schedule you agree, so records stay current as products change and authority guidance evolves.
Sources and further reading
- Regulation (EU) 2024/2847, Article 64 (EUR-Lex) ↗
- Regulation (EU) 2024/2847, Article 54 (EUR-Lex) ↗
- Regulation (EU) 2024/2847, Article 58 (EUR-Lex) ↗
- Regulation (EU) 2024/2847, Article 60 (EUR-Lex) ↗
- Regulation (EU) 2024/2847, Article 71 (EUR-Lex) ↗
- Commission FAQs on the Cyber Resilience Act, version 1.4 ↗
