Cyber Resilience Act penalties are the enforcement consequences for breaches of the CRA, including administrative fines and restrictions on product availability. Article 64 establishes three maximum fine tiers; market surveillance measures can also require corrective action, withdrawal or recall.
The three Article 64 tiers
| Breach category | Fixed maximum | Turnover maximum | How it is compared |
|---|---|---|---|
| Essential requirements and manufacturer obligations under Articles 13 and 14 | €15 million | 2.5% worldwide annual turnover | The higher amount |
| Other obligations covered by the second tier | €10 million | 2% worldwide annual turnover | The higher amount |
| Incorrect, incomplete or misleading information to authorities | €5 million | 1% worldwide annual turnover | The higher amount |
These are upper limits, not automatic invoices. National authorities determine the actual sanction in the circumstances and under the applicable procedures. The regulation includes factors that authorities must consider. A calculator can show the arithmetic ceiling, but cannot predict a fine, decide a legal breach or account for every enforcement factor.
A worked arithmetic example
For a business with worldwide annual turnover of €20 million, 2.5% is €500,000. The higher figure in the first tier is therefore €15 million. This does not mean a €20 million business would automatically receive a €15 million penalty. It illustrates why the percentage is not a cap that replaces the fixed amount for a smaller company. The same comparison method applies independently to the other tiers.
At €1 billion in worldwide annual turnover, the percentage in the first tier is €25 million, which exceeds the fixed €15 million figure. Use the fine calculator to check the three calculations for your inputs. Do not use the output to book a provision or assess litigation exposure without appropriate advice.
The narrow micro and small enterprise exception
Article 64(10) provides a specific exemption from fines for micro and small enterprises that miss the 24-hour early-warning deadline. It does not cancel the early-warning obligation itself. It does not remove the 72-hour notification, final report, remediation, user information or broader product-security obligations. Do not turn this exception into a general statement that small companies are exempt from CRA enforcement.
The enterprise definition must also be checked; headcount on its own may not settle it, particularly where group relationships are relevant. If the exception matters to a case, record the factual basis and obtain qualified review. The reliable operational response remains a tested reporting process, rather than planning to rely on a penalty exception.
Market access can matter before a fine
From 11 December 2027, applicable CRA requirements and conformity steps affect products placed on the EU market. Market surveillance authorities can seek corrective action and use powers that include restricting availability, withdrawal or recall. A product with no defensible technical evidence can therefore create distribution, support and inventory problems even before an administrative penalty is decided.
Retailer and marketplace requirements should be checked separately. Sales channels can remove non-compliant listings according to their applicable rules and legal duties. Avoid promising that a platform will accept a product merely because a document template is complete. Radio products have a separate RED cybersecurity context, including EN 18031, which must be reviewed on its own terms.
Budget for evidence and ongoing ownership
A readiness budget should distinguish assessment, implementation, testing, conformity-route costs and continuing monitoring. The purpose is to find and close security gaps, not to purchase a document that claims to eliminate enforcement risk. A useful project leaves your team with maintained evidence, an incident contact and a repeatable release process. Compare provider deliverables carefully: a subscription to software is a different purchase from engineering remediation or a lab assessment.
Build evidence that survives a release
Begin with a named product and a reproducible release reference. A marketing model number is not enough when several firmware branches, mobile applications and remote services jointly implement its functions. Record the hardware revision, firmware version, build identifier and necessary remote processing. Decide which older versions remain supported. The CRA work should refer to this boundary consistently, so a reviewer can understand which product a statement describes.
Assign responsibilities before collecting documents. Engineering should own technical facts and remediation. A product owner should agree the intended use, support commitment and customer information. An incident contact should receive vulnerability disclosures and have the authority to escalate them. The manufacturer remains accountable for conformity and reporting even when an external team prepares evidence or drafts. Outsourcing a task does not transfer the underlying obligation.
Retain both the conclusion and the evidence that supports it. An applicability decision without a release reference becomes difficult to defend after a dependency upgrade. A technical file without its underlying test results becomes difficult to update. A useful record links the requirement, the artifact, the reviewer, the decision and its date. Keep open questions visible instead of marking an item complete because a template exists.
Common mistakes to avoid
Do not use a scan score as a compliance decision. Vulnerability matches can be incomplete or inaccurate, and a component version alone does not establish exploitability in the product. Equally, a finding that appears irrelevant needs a documented technical rationale. The evidence should explain whether the affected code is present, reachable and exposed through the supported configuration, and who reviewed that conclusion.
Do not confuse a project completion date with a continuing duty. New releases, new public vulnerabilities and changes to the intended use can change the evidence. Plan how the inventory, risk assessment and customer information will be updated. Check that the incident contact still works and that an on-call substitute can make decisions when the primary owner is unavailable.
Do not assume that company size or a non-EU address removes the obligations. The relevant questions include the product, the economic-operator role and how it reaches the EU market. A distributor, importer, authorised representative and manufacturer can have different responsibilities. Borderline interpretations need qualified review. This guide explains the engineering workflow and does not provide legal advice.
A practical review meeting
Bring the product owner, release engineer and security contact together with the current evidence. Walk through a single supported version rather than discussing a hypothetical future product. Ask which assumptions can be checked immediately, which require a build or test, and which require an external conformity or legal specialist. Finish with a short list of actions, owners and dates. A small, reviewed evidence set is more useful than a large unmaintained folder.
Use the CRA guide to connect this topic to the complete lifecycle. Review the product classes before choosing a conformity route, and connect the release SBOM to the Article 14 reporting workflow. If you need a starting inventory, the free Snapshot is a bounded first step.
Make the next action measurable
Choose one supported release and identify the specific evidence missing for this topic. Write an action that a reviewer can close: an inventory validated against the image, a timestamped reporting drill, a classification rationale or an approved customer statement. “Improve compliance” is too broad to verify. Name the artifact, the responsible person and the date for review.
At the next meeting, check the artifact rather than the percentage complete in a tracker. Record any remaining uncertainty and whether the product boundary or release has changed. This keeps progress grounded in technical facts and prevents a documentation task from becoming disconnected from the product it describes.
Frequently asked questions
Is this a substitute for a product-specific assessment?
No. Use the guide to organise the engineering work. The product boundary, applicable legal interpretation and conformity route need a documented review.
Does a small team still need a process?
Yes. Assign a product owner, incident contact and substitute. The micro and small enterprise fine exception for 24-hour early warnings does not remove the duties.
Can Roja help with the practical work?
Yes. Our engineers validate inventory, triage findings, prepare reporting drafts and help build the technical evidence. The manufacturer reviews and remains accountable.
Where should we check the requirements?
Start with Regulation (EU) 2024/2847 on EUR-Lex and ENISA guidance for the Single Reporting Platform. Check the current text and your product facts before making a decision.
Sources
General engineering information, reviewed on the date above. Product-specific interpretations and current standards should be checked before a conformity decision. Roja helps manufacturers prepare for the Cyber Resilience Act. We do not certify products or provide legal advice.