What does CRA compliance cost?

“What does CRA compliance cost?” is one of the most frequently asked questions about the Cyber Resilience Act – and one where blanket figures do more harm than good. The effort hinges on a few clearly nameable drivers. That is why we deliberately cite no third-party market figures and give no price promise, but instead show the cost logic, three illustrative effort scenarios and how to reduce the effort deliberately. The concrete values are explicitly to be understood as estimates and do not replace a product-specific calculation.

Why there is no serious flat price

CRA compliance is not an off-the-shelf purchase but the sum of product properties, existing maturity and portfolio structure. Two manufacturers with the same revenue can differ by an order of magnitude in effort – depending on whether they maintain a single standard product or a grown firmware family without a dependency inventory. Anyone asking for a fixed price should expect the counter-question: which product class, which SBOM maturity, which process maturity? Only from that does a robust figure emerge.

The five cost drivers

One-off vs. ongoing cost

A common mistake is to budget CRA compliance as a one-off project. It splits into two blocks:

• One-off (project effort): gap analysis, risk assessment under Art. 13 and Annex I (threat modelling as the method), building the SBOM, technical documentation per Annex VII, EU declaration of conformity, CE marking, possibly conformity assessment by a notified body.
• Ongoing (operations): operating a PSIRT and CVD policy across the entire support period, continuous vulnerability monitoring, SBOM upkeep at every release, reporting readiness via the ENISA Single Reporting Platform, and retaining the technical documentation for ten years after placing on the market.

Three illustrative scenarios (effort, not price)

The following scenarios describe the relative effort tier, not euro amounts. They are estimates for orientation.

A – Single standard product, good maturity

Self-assessment (Module A). Focus: finalise the SBOM, document the risk assessment, produce the technical file (Annex VII) and declaration of conformity. Manageable, project-shaped effort – often plannable in weeks if vulnerability handling already exists.

B – Product line, medium maturity

Several products on a shared platform, class I. Focus: platform hardening, SBOM automation in CI/CD, PSIRT and CVD build, possibly applying harmonised standards to enable self-assessment. Markedly larger, partly recurring effort – but the platform approach lowers the effort per individual product.

C – Critical / class II product

Notified body, deep evidence (penetration test, formal risk assessment), ongoing operation of the reporting and update chain. Highest effort, plannable over a multi-month roadmap – here the notified body’s capacity co-determines the schedule.

A worked example: the industrial router

Take a mid-sized manufacturer of a managed industrial router. Routers are among the Annex III class I examples. A possible path would be:

• Check the class assignment: router = important products, class I. Self-assessment is conceivable provided the relevant harmonised standards are fully applied – otherwise a notified body.
• Build the SBOM across the firmware (CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1), at least top-level dependencies, as part of the technical documentation – there is no general publication obligation.
• Set up the reporting process first: 24 h early warning, 72 h notification, final report – distinguish cleanly: 14 days after a corrective measure becomes available for actively exploited vulnerabilities versus 1 month for severe security incidents.
• Produce the technical documentation (Annex VII) and declaration of conformity, apply CE marking, retain the documentation for ten years.

The point: because the reporting process already applies from 11 September 2026, it is the first concrete cost block – regardless of whether the product requirements are fully in place later.

Reducing cost and prioritising correctly

• Reporting processes first. They are the first hard deadline (11 September 2026) and can be set up with comparatively little effort. A PSIRT, CVD policy and a line to the ENISA platform protect against the highest fine tiers.
• Analyse gaps early and honestly. The most expensive mistake is waiting: retrofitting a product line already on the market is more expensive than “by design”.
• Reuse. Build the SBOM toolchain, hardening baselines and process documentation once, use them across the portfolio.
• Clarify the class before engaging a notified body. For class I, fully applying harmonised standards may avoid the notified body.

To frame the financial risk: the CRA provides tiered fines – up to €15m or 2.5 % of worldwide annual turnover for breaches of Annex I and the Art. 13/14 duties, up to €10m / 2 % for other duties, and up to €5m / 1 % for incorrect information to authorities (whichever is higher). That is the yardstick against which compliance cost should be weighed – as a factual framing, not a threat.

What Blackfort does

We translate the cost logic into a robust, product-specific roadmap: class assignment, gap analysis, SBOM build, reporting-process and PSIRT design, and the technical documentation per Annex VII – with a clear separation of one-off and ongoing cost. Instead of a blanket figure, you get a traceable budget per product and portfolio. This presentation is schematic and does not replace legal advice; the concrete assessment of your product is made on a case-by-case basis.

A first step with no effort: the CRA applicability check. Deeper detail on the legal act and deadlines in the Cyber Resilience Act overview, practical framing for smaller manufacturers under CRA for SMEs, and sector-specific examples under Industries. For a concrete effort discussion: get in touch.