Product security and the Cyber Resilience Act

Who is affected

The CRA covers manufacturers, importers and distributors of products with digital elements — from industrial controllers and connected machines through embedded components to accompanying software. What matters is not the sector but the product: as soon as it contains digital elements and reaches the EU market, you carry responsibility for its security. For machine builders this means the product itself, not only the company network, must meet the requirements.

The timeline — and why it is pressing now

The CRA entered into force on 10 December 2024; its obligations apply in stages. Crucially, the reporting obligations have applied since 11 September 2026. Manufacturers must report actively exploited vulnerabilities and severe incidents — an early warning within 24 hours, a full notification within 72 hours, and a final report after 14 days (or one month, respectively), via the central ENISA platform. The remaining main obligations — essential cybersecurity requirements, vulnerability handling, technical documentation and CE marking — apply from 11 December 2027. Anyone who starts only then is too late.

What manufacturers face

• Security by design — security as part of development, not a later add-on.
• Vulnerability management across the whole lifecycle, including the provision of updates.
• Software bill of materials (SBOM) — a traceable list of all components, the basis for acting fast when a vulnerability appears.
• Reporting and response processes for actively exploited vulnerabilities and incidents.
• Technical documentation and declaration of conformity, completed by the CE marking.

The link to IEC 62443 and NIS2

The CRA says what must be achieved; IEC 62443 provides the how. Parts 62443-4-1 (secure development process) and 4-2 (component requirements) are the technical foundation of your CRA conformity. At the same time the CRA complements your NIS2 obligations as an operator: many industrial companies are both — manufacturer and operator. We consider both roles together, so that vulnerability and reporting processes are built once and work twice.

Our approach

We translate the abstract CRA requirements into concrete processes for your product development: taking stock of and classifying your products, building an SBOM and vulnerability process, setting up the reporting path and preparing the technical documentation — without blocking your development schedule. As an immediate measure, we make sure you can actually meet the reporting obligation that has applied since September 2026.

Product classes and conformity assessment

Not every product is treated the same. The CRA broadly distinguishes the standard category from particularly critical classes. For the large majority of products a self-assessment by the manufacturer suffices; for certain safety-critical product groups, stricter procedures and, where applicable, the involvement of a notified body are foreseen. Part of our work is therefore the clean classification of your products — because that determines how demanding the path to CE marking will be.

What is a "product with digital elements"?

The term is broad. It covers hardware and software that can be connected, directly or indirectly, to a network or another device — from the programmable logic controller through the connected drive system to a machine's accompanying software. For machine builders this means at least part of the portfolio almost always falls under the CRA. The first question is therefore never whether you are affected, but which of your products fall into which class.

Supply chain and third-party components

Almost no product consists only of your own code. Bought-in libraries, modules and open-source components become part of your product — and therefore part of your responsibility. The software bill of materials (SBOM) is not an end in itself but the precondition for being able to act at all when a vulnerability appears in a third-party component. We help you build that transparency without slowing your development.

Fines and market access

The CRA carries meaningful sanctions. Breaches of the essential requirements can attract fines in the tens of millions of euros or a percentage of worldwide annual turnover. For most manufacturers, though, market access matters more than the figure: without conformity, no sale in the EU.

Technical documentation as a side benefit

The technical documentation the CRA requires looks at first like extra bureaucracy. In practice it pays off twice: it speeds up fault-finding, eases the onboarding of new developers, and serves as evidence to customers in tenders. Treat it from the outset as part of development rather than an afterthought, and a regulatory burden turns into a competitive advantage. We structure the documentation so that it grows alongside your development process, rather than being reconstructed painfully at the end.

Why starting early matters

Security is hard to retrofit into a finished product. The earlier the requirements flow into architecture and development, the lower the effort and cost. Companies that start now spread the work across the time remaining until 2027 — and avoid the bottleneck that everyone who acts just before the deadline will hit.

First steps

Begin with two things: an inventory of your products with a rough classification, and making sure you can meet the reporting obligation that has applied since September 2026. Both can be done quickly and give you the overview you need before the main obligations take effect in 2027.

Further reading: IEC 62443 – Assessment & Security Architecture · Manufacturing & Automation · NIS2 & ISO/IEC 27001