What Does CRA Compliance Cost? Drivers & Scenarios

Last updated: 2026-10-09

“What does CRA compliance cost?” has no blanket answer, and blanket figures do more harm than good here. 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. We show the cost logic, three illustrative effort scenarios and how to reduce the effort deliberately.

Why there is no serious flat price

The effort for CRA compliance results from product properties, existing maturity and portfolio structure. Two manufacturers with the same revenue can differ considerably 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 reliable figure emerge.

Five drivers, two cost blocks. Product class: self-assessment or notified body (Art. 32); SBOM maturity: inventoried dependencies reduce effort; Process maturity: vulnerability handling, CVD, secure development; Number of products: shared platforms spread the evidence effort; Support period: long commitments create running costs (Art. 13(8)). One-off: gap analysis, risk assessment, SBOM set-up, technical documentation, declaration of conformity, CE, notified body where needed; Ongoing: PSIRT and CVD over the support period, vulnerability monitoring, SBOM per release, reporting readiness, retention for 10 years or longer. Footer: Effort drivers, not prices; the actual effort depends on the individual case. — What drives the effort of CRA compliance and which costs are one-off and which are running.

The five cost drivers

Driver	Effect on effort
Product class (Annex III/IV)	Standard products run via self-assessment (Module A) - cheaper. Annex III “important” products: class I allows self-assessment only with full application of harmonised standards, common specifications or a European cybersecurity certification scheme (at least “substantial”), otherwise a notified body (Module B+C or H); class II: Module B+C, Module H or, where available and applicable, a European cybersecurity certification scheme at least at assurance level “substantial”; self-assessment under Module A is excluded. Annex IV “critical” products: a European scheme under Article 8(1), otherwise the class II procedures (Article 32(3) and (4)).
SBOM maturity	Those already inventorying dependencies face considerably less effort than with a greenfield SBOM over grown firmware. Format: commonly used and machine-readable; BSI TR-03183-2 (v2.1.0) specifies CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1.
Process maturity	Existing vulnerability handling, a CVD policy and a secure SDLC reduce the initial effort. Where these are missing, building the PSIRT/reporting process becomes its own sub-project.
Product count & reuse	Shared platforms and modules amortise the evidence across many products. A reusable SBOM toolchain pays off across the portfolio.
Support period	Long promised update periods create ongoing cost (monitoring, patch provision, reporting readiness), not just one-off. At least five years under Article 13(8), shorter only where the expected use time is shorter.

One-off vs. ongoing cost

It is a mistake 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 at least ten years after placing on the market or for the support period, whichever is longer.

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, especially 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 full application of harmonised standards, common specifications or a European certification scheme (at least “substantial”) to enable self-assessment under Module A; otherwise Module B+C or H. Markedly larger, partly recurring effort - but the platform approach lowers the effort per individual product.

C - Critical / class II product

Conformity assessment without Module A (Module B+C, H or a European certification scheme), deep evidence (security testing, formal risk assessment), ongoing operation of the reporting and update chain. Highest effort, plannable along a roadmap whose pace a notified body involved co-determines.

A worked example: the industrial router

Take a mid-sized manufacturer of a managed industrial router. Routers are listed in Annex III, class I (point 12). A possible path would be:

Have the class assignment checked: what matters is whether the device matches the technical description of routers in Implementing Regulation (EU) 2025/2392; your legal department or counsel confirms the classification. In class I, self-assessment (Module A) is possible provided harmonised standards, common specifications or a European cybersecurity certification scheme (assurance level at least “substantial”) are fully applied - otherwise a notified body (Module B+C or H).
Build the SBOM across the firmware (commonly used machine-readable format; BSI TR-03183-2 specifies CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1), covering at least the top-level dependencies, as part of the technical documentation - there is no general publication obligation.
Set up the reporting process first: early warning without undue delay and in any event within 24 hours of becoming aware; notification with the general information available without undue delay and in any event within 72 hours; final report no later than 14 days after a corrective or mitigating measure is available (actively exploited vulnerability) or within one month of the notification (severe incident having an impact on the security of the product).
Produce the technical documentation (Annex VII) and declaration of conformity, apply CE marking, retain the documentation for at least ten years or for the support period if longer.

The point: because the reporting obligation has already applied since 11 September 2026, the reporting process 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 only manufacturer duty already in force (since 11 September 2026): PSIRT, coordinated vulnerability disclosure policy and access to the single reporting platform.
Analyse gaps early and honestly. Waiting adds cost: 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, common specifications or a European certification scheme (at least “substantial”) 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). Article 64 is not among the provisions that apply early and applies from 11 December 2027 (Article 71(2)); the German implementing act (Bundestag printed paper 21/6134), which is to set the authority and fining procedure, had been neither adopted nor promulgated as of 9 October 2026. That is the yardstick against which compliance cost should be weighed.

What Blackfort does

Blackfort Technology translates the cost logic into a product-specific roadmap: a technical assessment of the product class for review by your legal department or counsel, gap analysis, SBOM build, reporting process and PSIRT, 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.

Frequently asked questions

Can you name a fixed price for CRA compliance?+

Only after a gap analysis. Product class, SBOM and process maturity drive the effort so strongly that a serious figure is product- and portfolio-specific - not a blanket number. The scenarios given are explicitly estimates for orientation, not a price promise.

Where should you start?+

That depends on what is already in place. Because the reporting obligation has applied since 11 September 2026, the reporting process (PSIRT, coordinated vulnerability disclosure policy, access to the single reporting platform) belongs near the top of the list. If it is unclear which products are affected and what is missing, the gap analysis first provides the overview and orders the steps by urgency; SBOM and technical documentation follow.

Are the costs one-off or ongoing?+

Both. One-off items are the gap analysis, risk assessment, SBOM build, technical documentation per Annex VII, declaration of conformity and CE marking. Ongoing items are operating a PSIRT and CVD policy across the support period, vulnerability monitoring, SBOM upkeep per release and retaining the technical documentation for at least ten years or the support period if longer.

Why is a notified body more expensive than self-assessment?+

Standard products run via self-assessment (Module A). Annex III class I products allow self-assessment only with full application of harmonised standards, common specifications or a European cybersecurity certification scheme (at least “substantial”), otherwise a notified body becomes necessary (Module B+C or H); for class II and critical Annex IV products, Module A is excluded (Article 32(3) and (4)); besides Module B+C or H, European certification schemes come into consideration there. External assessment, deeper evidence and the body's capacity planning increase both effort and lead time.

By when must I budget for CRA costs?+

The CRA has been in force since 10 December 2024. The reporting duties under Art. 14 have applied since 11 September 2026, and full applicability of all product requirements follows on 11 December 2027. The reporting process is therefore the first concrete cost block; the product-requirements part can be planned towards 2027. This information is schematic and does not replace legal advice.

Sources

This content provides general technical and organizational information on the Cyber Resilience Act (Regulation (EU) 2024/2847) and does not constitute legal advice (no legal services within the meaning of the German RDG).