Cybersecurity for Machinery Makers

From 2027, a machine with a controller, an operator display or a data connection answers to two EU regulations. Both start from the same question: which software is on this machine, version by version, and what is inside it.

1. 11 September 2026Cyber Resilience Act reporting of actively exploited vulnerabilities and severe incidents applies.
2. 20 January 2027The Machinery Regulation, (EU) 2023/1230, applies and replaces the Machinery Directive.
3. 11 December 2027The Cyber Resilience Act, (EU) 2024/2847, applies in full.

Machinery Regulation

Two essential health and safety requirements in Annex III deal with cybersecurity:

• 1.1.9, protection against corruption. Connecting another device to the machine, directly or remotely, must not lead to a hazardous situation. Software and data that are critical for the machine's compliance with the essential health and safety requirements must be identified and protected against accidental or intentional corruption. The machine must identify the software installed on it that it needs to operate safely, and provide that information at all times. It must also collect evidence of legitimate or illegitimate interventions in that software or its configuration.
• 1.2.1, safety and reliability of control systems. Control systems must withstand reasonably foreseeable malicious attempts by third parties that lead to a hazardous situation. Under 1.2.1(f), they must keep a tracing log of interventions and of the versions of safety software uploaded after the machine was placed on the market, for five years after the upload.

Cyber Resilience Act

A machine with a data connection, or a part of it sold on its own, is a product with digital elements. The manufacturer must exercise due diligence on the third-party components it integrates, draw up an SBOM covering at least the top-level dependencies, handle vulnerabilities for the support period, which is at least five years unless the product is expected to be in use for less, and keep the technical documentation for at least ten years or for the support period, whichever is longer.

Not automatically. The Cyber Resilience Act gives no presumption of conformity with the Machinery Regulation. Its recital 53 says that meeting the CRA's essential requirements could facilitate compliance with the Machinery Regulation's requirements on protection against corruption and on the safety and reliability of control systems. It also says that the manufacturer has to demonstrate this, for example by applying harmonised standards after a risk assessment, and that the conformity assessment procedures of both regulations still apply.

The harmonised standard being written for 1.1.9 is EN 50742, Safety of machinery: Protection against corruption. As of November 2026 it was a final draft, FprEN 50742, covering 1.1.9 and the related points of 1.2.1, and until a final version is cited in the Official Journal it gives no presumption of conformity. It combines the risk assessment of EN ISO 12100 with security concepts from IEC 62443, and accepts the consistent use of IEC 62443-4-1, IEC 62443-3-3 and IEC 62443-4-2 as an equivalent way to meet its protection goals. IEC 62443-4-2 sets the technical security requirements for control system components, graded by security capability level. In Germany, the test principles GS-IFA-M25 of July 2026 turn protection against corruption into 66 test criteria, using the terms of prEN 50742. One of them, T46, asks that the product can provide its installed software version and configuration on request. Answering that for every configuration takes a record of what each software version contains.

The Machinery Regulation has a presumption of its own, and it runs through a different route: EU cybersecurity certification schemes adopted under the Cybersecurity Act, Regulation (EU) 2019/881. A certificate or statement of conformity under such a scheme presumes conformity with 1.1.9 and 1.2.1 as far as it covers those requirements.

So one risk assessment and one set of evidence can serve both regulations, but you show conformity to each. If your machine has a data connection, plan for both. The software evidence, meaning SBOMs, vulnerability records and the update history, is the part they share.

In January 2026 machinery industry associations asked for 1.1.9 and 1.2.1(f) to be postponed, and in March 2026 for them to apply from the CRA's date, 11 December 2027. It is a request, not law: as of November 2026 no postponement had been adopted. The dates on this page are the dates in the regulations.

• Construction, materials-handling, mining and industrial machines fall under the Machinery Regulation, and under the CRA as well when the machine or its parts have a data connection.
• Agricultural and forestry tractors covered by Regulation (EU) No 167/2013 are excluded from the Machinery Regulation, except for machinery mounted on them. The CRA's list of exclusions does not name that regulation, so a connected tractor can be in CRA scope.
• Road vehicles type-approved under Regulation (EU) 2019/2144 are excluded from the CRA.
• Components sold on their own. The CRA also applies to software and hardware components placed on the market separately. A supplier that sells an ECU or a telematics unit on its own is a manufacturer under the CRA in its own right. Where the unit is only built into the machine, the machine maker carries the obligation for the whole machine and must exercise due diligence on the supplier's component.

This is general information, not legal advice. Check your own product's classification.

Inside one machine, the software comes from different places, and only the team that builds a piece of software can say reliably what is in it. As we hear from machine makers, bare-metal ECUs hold little open source, while Linux, Android and Windows software holds a lot.

Low volume, high variety. A machine maker can have hundreds of platforms on the market, sell a handful of units of each per year, and configure many machines to order. Every configuration is a different set of software, so an SBOM for every build matters more than an SBOM for every product line.

Long lifetimes. Machines stay in service for a decade or more, while suppliers change or go out of business. The record of what went into a software version has to be made when it is built, because it cannot be reconstructed years later.

Supplier software dominates, and supplier SBOMs are often poor. We hear of supplier SBOMs with missing components, no package URLs or CPEs, no licenses and no hashes, some written by hand and failing schema validation. Binary analysis of a flashed ECU is a stopgap: it guesses at the contents instead of recording them.

The risk sits in the connected layers. Much ECU logic is generated from models and contains little open source. The open source, and the network exposure, concentrate in the Linux, connectivity and app layers, so spend your effort there first.

An illustrative example: the software stack of a fictional wheel loader platform, from the cloud down to the ECUs.

1. Cloud back end and companion appIn-house. Mostly open source and network-facing. Cyber Resilience Act.
2. Telematics gatewayEmbedded Linux, mostly open source, connected to the mobile network. Cyber Resilience Act, and 1.1.9 for the remote connection.
3. Operator displayEmbedded Linux image with a UI framework, mostly open source, connected to the machine bus and to service tools. Cyber Resilience Act and 1.1.9.
4. Machine controllerIn-house application on a supplier platform, safety-relevant. 1.1.9 and 1.2.1, and the Cyber Resilience Act where it can be reached over a connection.
5. Hydraulic, steering and engine ECUsSupplier firmware, proprietary and model-generated, little open source, safety-relevant. 1.1.9 and 1.2.1; the Cyber Resilience Act through the machine.

The open source and the network exposure sit in the top three layers, which is also where your own build pipelines usually are. Start there.

Machine makers now set SBOM requirements for the software they buy, such as package URLs or CPEs, licenses, hashes and a format that passes validation, and send back files that fail. If you build on GitHub Actions, CRACI produces the SBOM from the build itself, so it lists what actually went into the release, including the components no lockfile names, with a package URL and declared license for every component. Check the export against the full list of fields your customer asks for. More on answering customer SBOM requests.