Machinery Regulation meets Cyber Resilience Act: two regulations, one interface, and why the cyber duty has applied since September

The short answer first: if you build or retrofit a machine with digital elements, two EU regulations now read the same product, and they started on different dates. The Machinery Regulation (EU) 2023/1230 becomes mandatory on 20 January 2027 and brings explicit cyber-safety requirements for conformity-relevant software for the first time. The Cyber Resilience Act (EU) 2024/2847 has already obliged manufacturers to report actively exploited vulnerabilities and severe incidents since 11 September 2026. Whoever treats them as two separate projects will build the same documentation twice.

This guide is written for the machine builder and its software supplier, not for the certifier. It covers what each regulation demands, where they overlap, and the one trigger both share: the substantial modification that turns an update into a re-certification.

The two timelines, side by side

The dates matter because they refuse to queue politely. The CRA's reporting duty has been live since 11 September 2026, the Machinery Regulation applies from 20 January 2027, and the CRA's main obligations land eleven months after it. Between them sits the product lifecycle of every machine that ships in between, and each one will have to answer to both.

What the Machinery Regulation adds that the directive never had

The Commission's machinery page lists the changes plainly: the regulation integrates provisions for cyber-safety of conformity-relevant software data and safety control systems, provisions for machinery with AI-powered safety functions, and it clarifies that instructions and the declaration of conformity can be provided digitally. Under Directive 2006/42/EC none of this was explicit; the machine's software lived in a footnote. Under the regulation it is a named requirement, which means the auditor can now fail it.

The regulation itself sets the trigger that decides whether an old machine becomes a new obligation, in Article 18 together with Article 3(16): a substantial modification. Our earlier piece on the software-update side walked through Article 18 and the two-letter carve-out in Article 3(16) that keeps most routine updates out of scope; the short version is that a change to a safety function can requalify you as the manufacturer, and from January 2027 that assessment runs against the new requirements, not the old directive.

Where the Cyber Resilience Act picks up the same product

The Commission's CRA summary sets the second clock: in force since 10 December 2024, reporting obligations under Article 14 since 11 September 2026, main provisions from 11 December 2027. And it shares the MVO's trigger logic: products placed on the market before 11 December 2027 only fall fully under the CRA if they undergo a substantial modification afterwards. The reporting duty, however, applies to everything already on the market, no grandfather clause for incidents.

The overlap is the product that is both: a machine whose safety or function depends on software with digital elements. That covers the embedded controller in a press, the HMI on a packaging line, the networked drive in a conveyor. For that product the MVO asks whether the software keeps the machine safe, and the CRA asks whether the software keeps itself safe. Both answers live in the same engineering file.

What a mid-market manufacturer should do before January

Four steps, in order. First, inventory the software-bearing safety functions: which products have controllers, firmware or connected components whose failure could hurt someone. Second, map each one against both requirement lists, because the MVO conformity file and the CRA technical documentation reference the same versions. Third, fix the reporting channel now, since the CRA's duty is already live: since 11 September 2026, whoever learns of an actively exploited vulnerability owes a notification, whether or not the rest of the file is ready. A vulnerability that is merely exploitable does not have to be reported to the CSIRT or to ENISA; from 11 December 2027, however, a vulnerability you find in an integrated component must be reported to whoever manufactures or maintains that component (Article 13(6) CRA). Fourth, decide the update policy, because every future software change is a potential substantial modification and should be triaged, not improvised.

The regulatory stack keeps growing sideways: the CRA reporting piece covers the September deadline in detail, and the NIS2 incident duty applies to the same events at company level if you sit in a covered sector. One incident can owe three reports.

The honest remainder

Two qualifications keep this honest. First, the detailed conformity mechanics depend on the harmonised standards; the Commission notes on its page on harmonised standards for machinery (retrieved 16 October 2026) that the first MVO list was expected before the end of 2026, and until it lands, some questions sit in interim. Second, this is orientation, not legal advice: whether a specific update crosses the substantial-modification line is an engineering and legal judgment on the actual change, not a rule of thumb.

Whoever takes one sentence from this piece: the two regulations do not ask two different questions; they ask the same question about the same software from two directions, and the company that builds one lifecycle file answering both will be done while competitors are still explaining to two auditors why the folders disagree.

Frequently asked questions about the Machinery Regulation and the Cyber Resilience Act