The Cyber Resilience Act applies from December 2027. Including CRA effort in current budget planning avoids costly follow-up demands later.
The CRA budget is driven by three blocks of effort: building secure development and vulnerability processes, technical security measures in the product, and documentation together with conformity assessment. The largest share rarely falls on one-off measures; it is typically on ongoing obligations throughout a product’s support period.
What really drives the CRA effort
The CRA effort is spread across three levels that have different practical impacts.
The first level is process development. The CRA requires a secure product development process and functioning vulnerability management. This includes a vulnerability disclosure policy, an incident response process, and the ability to report actively exploited vulnerabilities and serious incidents within required timeframes. For many manufacturers in the machinery and plant engineering sectors, this means building from scratch. A common procedural reference here is IEC 62443-4-1 as process standard for secure product development, which structures a large part of these requirements.
The second level is technical measures in the product. Threat modeling, security-by-design, secure update mechanisms, authentication, encryption and hardened interfaces follow from the basic requirements in Annex I, Part I. This block becomes particularly effort-intensive when existing product platforms must be retrofitted for security instead of having security considered from the start.
The third level is documentation and conformity assessment. This includes technical documentation according to Annex VII, risk assessment, the EU declaration of conformity and, depending on the product class, involvement of a notified body. Which route applies depends on classification: standard products via internal control, important products under Annex III possibly via harmonized standards or a notified body. The classification of important and critical products under the CRA therefore directly determines the size of this effort block.
Why manufacturers underestimate the CRA effort
The most common blind spot: the CRA is read as a pure documentation and CE topic, something that can be handled at the end of development. In reality, the regulation reaches deeply into processes and product architecture.
Take a networked machine controller with remote maintenance access. At first glance this is an established product with an existing CE marking. Under the CRA, however, additional requirements affect the product itself: a secured remote access, a demonstrable process for security updates across the entire support period, and technical documentation that proves the security architecture. What looks like a modest addition touches development, testing, product management, service and legal departments at the same time.
Three additional reasons for underestimation regularly occur. First, effort scales with portfolio breadth: every product with digital elements generally falls within scope, and product variants multiply the work. Which products are affected should be clarified at the start through a thorough applicability check and scoping for the CRA. Second, the effort is not one-off but ongoing: vulnerability management accompanies the product for years. Third, the CRA reaches into the supply chain, for example via software bill of materials (SBOM) and supplier attestations.
Why late CRA budgeting becomes expensive
If the CRA effort is not included in the regular budgeting round, you end up later with a change request in the middle of the fiscal year. Such supplementary funding requests are harder to push through, compete with already committed projects and often arise under time pressure, meaning worse terms.
There is also a capacity problem. The closer 2027 approaches, the more manufacturers compete for the same resources: internal developer capacity, external specialists and the testing capacity of notified bodies for important and critical products. Late budgeting therefore meets a tighter market.
The most expensive item is ultimately the market access risk. Products that do not meet CRA requirements may not be placed on the market after the cut‑off date. Delayed implementation thus not only shifts costs but in the worst case endangers the marketability of entire product lines. The situation is aggravated by parallel regulation: the new Machinery Regulation (EU) 2023/1230 applies from 20 January 2027 and ties up many of the same teams in many organizations.
Why the CRA belongs in the 2027 budgeting round
CRA obligations come into force in stages. The reporting obligations for actively exploited vulnerabilities and serious security incidents already apply from 11 September 2026, i.e. in a few months. The full product requirements follow on 11 December 2027, i.e. in the fiscal year currently being budgeted. Those who do not allocate funds now will have no leverage in the obligation year itself.
Manufacturers who have so far postponed the issue and plan to tackle it seriously only in the obligation year must anchor the effort now in the current 2027 budgeting round. Early CRA budgeting offers three advantages: it spreads effort over multiple fiscal years instead of squeezing it into a single year, it provides negotiating leverage with external partners and notified bodies, and it prevents crisis mode shortly before the deadline. A rough but intentional budget can be refined later. A forgotten budget must be pushed through as a supplementary request against resistance.
Conclusion
The real CRA effort does not arise from the CE marking but from processes, technical measures in the product and ongoing obligations throughout the support period. These drivers are regularly underestimated in practice because they cut across the company and are not one‑off. This year’s budgeting round is the right time to establish a realistic order of magnitude before scarce resources and fixed deadlines narrow the available leeway.
A reliable budget figure does not come from intuition but from a product‑related roadmap that makes effort drivers, sequencing and timing visible. We develop exactly this roadmap with manufacturers in a structured workshop, in which a CRA effort calculator translates estimated efforts into an order of magnitude that can be justified in the budgeting round.
