CRA and the Machinery Regulation for integrators and plant builders: what applies from 2026

From 2026, two EU regulations begin to interlock that affect everyone who builds machinery and places it on the market: the Cyber Resilience Act (CRA) and the new Machinery Regulation (EU) 2023/1230 (MR). Both require cybersecurity, both lead to a CE marking. But they govern different things, apply at different points in time, and neither replaces the other.

From 11 September 2026, actively exploited vulnerabilities must be reported under Article 14 CRA in staggered form – an early warning within 24 hours, a vulnerability notification within 72 hours and a final report within 14 days to the coordinating CSIRT and ENISA, including for systems already in the field. What that means for roles, deadlines and your own vulnerability pipeline, in turn.

When do you, as an integrator or plant builder, become the “manufacturer”?

The CRA ties the obligations to the role of the manufacturer. Integrators regularly fall into this role: anyone who combines components into a system and places it on the market under their own name (Art. 3(13)) is deemed the manufacturer of the overall product. The same applies in the case of a substantial modification to an existing product (Art. 22).

• A one-off or custom build offers no exemption – the obligation applies per product, not only above a certain unit count.
• A pure bugfix is generally not a substantial modification. A new function or an increased attack surface, by contrast, is.
• The consequence: full manufacturer obligations for the overall product, including the bought-in third-party and open-source components.

For most plant builders, this is not an open question. The trigger is not how novel the combined system is, but a simple question: do you deliver a defined machine, line or system under your name – with your nameplate and your declaration of conformity? If so, you are the manufacturer, regardless of whether it contains a standard PLC with sensors and actuators or something highly specialised. Because it is not the CE marking that makes the manufacturer; it is the other way around: whoever places a product on the market under their own name is the manufacturer and therefore affixes the CE marking and signs the declaration of conformity. Anyone who already signs a declaration of conformity for the overall system today – which is in any case the situation under the MR, or under the old Machinery Directive, as the manufacturer of the “assembly of machinery” – has already assumed the manufacturer role for that product. The CRA does not newly establish this role; it adds a second dimension of requirements to it as soon as the system contains digital elements.

The European Commission describes this case using the example of a food-packaging machine: it can be both a machine within the meaning of the MR and a product with digital elements within the meaning of the CRA. In this case both sets of requirements must be assessed and met, and both conformity assessments must be carried out separately; satisfying one does not replace the other.

There is a limit: anyone who, as a pure installer, merely wires up individually CE-marked devices at the customer's site without combining them into their own product delivered under their name is not the manufacturer of a new product. This boundary runs along the lines of placing on the market and putting into service, and it becomes blurred above all for very large complete installations erected only on the customer's premises – yet according to the Commission's (legally non-binding) draft guidance, complex systems do not automatically fall outside the scope either, but must be assessed on a risk basis. For a defined machine or a delimited line this caveat does not apply: it has been placed on the market as a product. Size therefore does not make the classification more certain, but rather blurs it at the outer edge.

The common argument “we just plug together a PLC with actuators and sensors” changes nothing: as soon as the result is delivered as your machine under your name, it is your CRA product. But that does not mean you have to analyse every third-party component in detail yourself. The CRA is designed as a layered model: every CRA-regulated component has its own manufacturer, who is liable for its advisories and updates. You may rely on their CE marking and vendor advisories; the duty of care during integration remains (Art. 13(5)). Vulnerability management and the declaration of conformity for the overall machine, however, are your responsibility (Art. 13(1)) – the obligation applies to the product in its entirety, including all integrated components.

CRA and the Machinery Regulation apply in parallel

The MR and the CRA apply in parallel. Both lead to a CE marking, both belong in the declaration of conformity. But they pursue different protection goals, and that determines how deeply each must be analysed.

• The MR protects people. Cybersecurity is relevant here only in a safety frame: what must be protected is whatever can lead to a hazardous situation (Annex III, 1.1.9 protection against corruption and 1.2.1 control systems).
• The CRA protects the product. It is about IT security across the entire attack surface – confidentiality, integrity, availability – and that over the complete support period.

In substance, the safety-relevant threats of the MR are a subset of the CRA's security scope. Anyone who implements the CRA properly largely covers the cyber substance of the MR in content terms. The following comparison shows the delineation:

From the differing time horizons follows a practical distinction: the MR obligation is completed with the design documentation at the point of placing on the market. The recurring effort of monitoring and triage over years, by contrast, arises from the CRA.

It is not a perfect overlap, though. A clean CRA compliance can cover MR requirements 1.1.9/1.2.1 – but only “where demonstrated” via a harmonised standard, and that standard is not yet listed in the Official Journal of the EU. On top of that, a conceptual difference remains: a residual risk acceptable under the CRA that could disable a safety function must nevertheless be eliminated by design under the MR. For safety-critical threats, the MR threshold therefore sits higher. And one MR obligation has no counterpart in the CRA at all: the tamper-proof logging of safety-relevant interventions (firmware updates, configuration changes) over at least five years.

The timeline: what applies from when

Three dates are decisive for planning. The first deadline is not the CE marking, but the reporting obligation:

The order is decisive: the reporting obligation takes effect more than a year before the CE obligation, and it applies retroactively to systems that are already running today. Anyone who only starts at the end of 2027 has already missed the first deadline. Setting up monitoring across the supply chain is therefore time-critical.

Implementation in practice: the vulnerability pipeline

The approach can be kept proportionate: avoid your own in-depth analyses, rely on the curated advisories of your direct suppliers, secure these contractually, map them to your own system and check only the integration delta yourself. In detail, six steps:

1. Map the HW BOM to firmware versions – for all new systems from now on. The result is a matrix of systems × components × suppliers. Important: a hardware bill of materials is not an SBOM. The CRA requires a software bill of materials with CVE-capable IDs (CPE/PURL and version).
2. Monitor direct-supplier feeds – not the feeds of the sub-components. Primarily machine-readable via CSAF; long-tail suppliers without CSAF via RSS, email or manually, normalised to a single view.
3. Map the advisory to the system – via supplier, exact component, version and CPE. The entry must be CVE-matchable, not merely “mentioned”.
4. Deployment-condition check instead of re-triage – if the supplier says “not affected under condition X”, you only check whether your wiring meets that condition. No in-depth architecture or source analysis of third-party closed components.
5. PSIRT decision – is the vulnerability exploitable in the specific system context? If so: define the measure, inform the customer and, where applicable, trigger the 24 h / 72 h report to ENISA.
6. Triggered spot check as a fallback – not random, but event-driven: where there are actively exploited vulnerabilities (KEV) and the supplier remains silent beyond the SLA, check yourself. Plus a periodic audit of supplier responsiveness.

The effort stays proportionate above all thanks to one boundary: a closed supplier module is treated as a boundary node and is not broken down further. Otherwise raw sub-component feeds mainly generate noise – a raw Jetson feed, for instance, brings around 5,500 kernel CVEs per year, about 85 % of them without a score. The direct supplier's product-level VEX lowers the false alarms most, because it has already done the mapping step.

Contractually, every direct-supplier framework agreement should include a clause guaranteeing, per release, a machine-readable CSAF/VEX for the product – including the sub-component layer – within a defined SLA. This removes the need for your own in-depth analysis.

What to do with suppliers who provide no CSAF?

CSAF is the machine-readable standard format, but a large part of the DACH supplier chain will not provide it in 2026. Mid-sized component manufacturers today publish advisories as a PDF, as a newsletter, as an entry on a support page, or not at all. Anyone who relies only on CSAF-capable suppliers leaves open the gaps from which reportable cases later arise.

These unstructured sources must be actively collected and normalised to the same view as the CSAF feeds: tapping RSS and mailing lists, watching support pages, evaluating incoming email advisories and mapping the result to supplier, component and version. This collection and unification across the entire spectrum from CSAF to email is what we automate at Werkspilot. For suppliers who permanently fail to respond, the triggered spot check remains as a fallback (see step 6).

The patch business that emerges from the CRA

The CRA is often seen only as a cost item. But it also creates business potential for plant builders. The reason is an asymmetry in the supply chain: the component manufacturers' vulnerability updates are free of charge; under the CRA they are obliged to provide them over the support period. What the component manufacturers do not deliver is the work that falls on the plant builder:

• Integration of the update into the specific system configuration – a firmware update for a component is not automatically approved for the overall system.
• Validation and regression – ensuring that the update does not disable any safety function and that the system continues to run in conformity with its specification.
• Testing and recommissioning in the field, documented as CRA evidence.

These three steps recur, over the entire support period of at least five years, and can be mapped into a contract with the customer. Anyone who runs the monitoring anyway is the first to see which system is affected by which vulnerability, and can offer the patch service proactively. The regulatory obligation thus becomes a plannable, recurring service revenue.

The ongoing monitoring across the supply chain

In addition, the MR and the CRA require a traceable cybersecurity risk assessment; the usual tool for this is a STRIDE threat analysis per system type; it is drawn up once and then maintained. The recurring effort sits in the daily monitoring across the supply chain.

With manual processing, this monitoring fails against the 24 h deadline. For a sense of scale: a single well-maintained supplier feed already yields a few hundred CVEs per year; across the whole supplier base that adds up to thousands of matched advisories per year, of which a handful are genuinely reportable in the end. This funnel cannot be handled by hand, especially as the component pool grows by around 20 % per year. Reviewing, mapping and documenting quickly ties up several person-days per month across a mid-sized installed base – more with every new system; and when a case is actively exploited, the same work has to be done within hours.

Werkspilot automates this pipeline: continuously capturing supplier feeds from CSAF to email, automatically matching new vulnerabilities against the systems in the field, assessing them centrally and reporting them to customers and ENISA on time at the push of a button. Out of thousands of advisories, what remains in the end is what actually affects your own systems, traceably documented for the audit case.

If you would like to see what this looks like concretely for your systems, book a call.

This article summarises the state of the regulation at the time of publication and does not constitute legal advice. The regulatory texts themselves are authoritative.