The EU Machinery Regulation From 20 January 2027: What It Asks of Your Machine Software

On 20 January 2027 the Machinery Directive is replaced by Regulation (EU) 2023/1230, the Machinery Regulation. Most of it will feel familiar to anyone who builds CE-marked machines. One part will not. For the first time, machinery law puts duties directly on software: the machine has to say which software it needs to run safely, notice when that software or its configuration changes, resist corruption, and keep a trace of safety software updates for five years.

This is written for heads of engineering and controls at machine builders. If you ship machines into the EU after that date, these requirements land in your PLC programs, your HMI, your remote access and your update back end.

What the Law Actually Says

The European Commission states that the Regulation "applies on a mandatory basis as of 20 January 2027" and that it "integrates provisions for cyber-safety for compliance-relevant software data and safety control systems". The text published in 2023 said 14 January; a corrigendum moved it.

The software duties sit in two essential health and safety requirements in Annex III of the Regulation.

Section 1.1.9, protection against corruption. In short:

• Connecting another device to the machine, directly or remotely, must not lead to a hazardous situation.
• Software and data that are critical for compliance with the safety requirements "shall be identified as such" and protected against accidental or intentional corruption.
• Hardware that carries signals or data giving access to that software (think of a programming port or a network interface into the safety controller) must be protected as well, and the machine must collect evidence of intervention in it.
• The machine "shall identify the software installed on it that is necessary for it to operate safely, and shall be able to provide that information at all times in an easily accessible form."
• The machine "shall collect evidence of a legitimate or illegitimate intervention in the software or a modification of the software installed on the machinery or related product or its configuration."

Section 1.2.1, safety and reliability of control systems. Control systems must withstand "reasonably foreseeable malicious attempts from third parties leading to a hazardous situation". Point (f) adds the logging duty: a tracing log of the data generated by an intervention, and of the versions of safety software uploaded after the machine was placed on the market, "is enabled for five years after such upload". The log exists to show conformity when a national authority makes a reasoned request, and for nothing else.

Also on the list: the technical documentation must be able to produce "the source code or programming logic of the safety related software" if an authority asks (Annex IV).

Which Machines Are Covered

The rules apply to machinery placed on the market from 20 January 2027. Machines placed on the market under the old Directive before that date can still be sold on (Article 52), and the fleet already in the field is not reached by the new software rules.

The catch is what "placed on the market" means. The Commission's Blue Guide says the concept "refers to each individual product, not to a type of product". Every unit that leaves your factory for an EU customer from 20 January 2027 has to meet the new requirements, software included. A family that ships continuously needs its controls software ready before the first unit of 2027, not at the next model change.

Later updates need thought too. A change made "by physical or digital means" that the manufacturer did not foresee, and that creates a new hazard or increases a risk, can be a substantial modification. Recital 32 says the risk assessment should cover software updates foreseen at placing on the market, so describe your update path there now.

What It Means in Each Layer of the Machine

Safety controller and PLC

• Decide what is safety relevant. That is usually the safety program, but it can include standard PLC code that feeds a safety function, safety parameters in drives, and the configuration of laser scanners or light curtains. Write it down per machine family; everything else depends on it.
• Baseline and compare. For each released configuration, record a checksum or signature of every safety-relevant item. At startup and at intervals, the machine compares what is running against that baseline and records any difference. This catches the intervention that went around your access control, such as a laptop plugged straight into the controller.
• Lock down engineering access. Passwords on the safety program, unused ports and services disabled, and engineering access only through a path that authenticates the person and logs what they did.

HMI

• A software identification screen listing the safety-relevant software with versions and checksums. Read the values live from the devices. A page typed up at release time drifts from reality, and the requirement says "at all times".
• Parameter screens. Point 1.2.1(d) rules out modifications to settings or rules that could lead to hazardous situations. Safety-related parameters belong behind access levels, with limits enforced in the controller and not only in the HMI, and every change recorded with who, when, the old value and the new one.

Remote access

Section 1.1.9 names remote devices explicitly. In practice:

• Safety functions stay local. A remote session can read, diagnose and stage a change. It cannot override a stop, a guard or an enabling device.
• Sessions are authenticated per person, not through a shared service account, and the customer can see when one is open.
• Every session start, end and change goes into the same evidence log as local interventions.

Back end and update pipeline

If you deliver updates after shipment, your update server is in scope of the work. For each serial number you need to know which safety software version was uploaded, when, and by whom. Sign the updates, and have the machine check the signature before it installs anything.

The tracing log itself

The Regulation does not say where the log lives. Our view: the copy that counts sits on the machine, because many customers will not allow a permanent connection. A cloud mirror is useful, but it cannot be the only copy.

The volume is small: interventions and safety software uploads, not process data. Five years fits in local storage if you size it on purpose. Protect it against deletion and make sure it survives a controller swap. If entries name a technician, that is personal data at the customer's site: log what the requirement needs and nothing more.

What Your Controller Vendor Gives You, and What It Does Not

Your controller platform will supply part of this. Before building anything, check what it offers: a signature or checksum over the safety program, password protection, user management, a change log, version readout. Use whatever is there.

These are building blocks. The vendor does not know which of your drives and scanners are safety relevant, cannot see your remote gateway or update server, and cannot decide how evidence survives five years and a controller replacement. Configuring those features, connecting them across the whole machine and documenting the result is the builder's job, and the builder signs the declaration of conformity.

How This Relates to the Cyber Resilience Act

The Cyber Resilience Act runs on its own calendar. Its reporting obligations have applied since 11 September 2026, and its full requirements apply from 11 December 2027. The Machinery Regulation lands between the two.

The CRA acknowledges the overlap. Recital 53 of Regulation (EU) 2024/2847 says manufacturers of machinery that is also a product with digital elements should comply with both, and that complying with the CRA "could facilitate" compliance with sections 1.1.9 and 1.2.1. The manufacturer has to demonstrate that synergy. The CRA's Annex I asks for protection of the integrity of "commands, programs and configuration" and for reporting on corruptions, which is close to what 1.1.9 asks.

One difference matters for your log design. The CRA's requirement to record and monitor internal activity comes "with an opt-out mechanism for the user". The Machinery Regulation's tracing log has to stay enabled for five years. Build one logging mechanism if you like, but do not let the CRA opt-out switch off the machinery log.

Build for the Machinery Regulation now, because it comes first, and design it so the same evidence store, signing and update records serve the CRA in December 2027.

Standards and the Failed Postponement

Do not count on a harmonised standard covering these requirements being cited by 20 January 2027. The Commission's harmonised standards page, as updated in September 2026, says the first list under the Machinery Regulation is being prepared. It will carry over most standards cited under the Directive and clarify them where they "do not yet fully address" the new requirements, and it "can be expected before the end of this year".

In January 2026, CEMA, CECE, CECIMO, EGMF and FEM asked in a joint industry position for 1.1.9 and 1.2.1(f) to be postponed to 11 December 2027, in line with the CRA. They put compliance costs at "more than €1 million per platform architecture" and said the expected standards stay very general on the data log in 1.2.1(f).

That request was not adopted. The Machinery Regulation was amended in July 2026 by Regulation (EU) 2026/1744, but that amendment deals with high-risk AI systems in machinery and leaves the application date alone. Plan on 20 January 2027.

So you may have no standard giving a presumption of conformity for these two requirements on day one. Your technical file then has to describe the solution you applied for each (Annex IV). Write that while you build, not afterwards. For machinery listed in Annex I, Part B there is one more step: self-assessment is only open if harmonised standards or common specifications cover all the relevant requirements; otherwise a notified body is involved (Article 25). Machinery not listed in Annex I self-assesses either way.

A 15-Week Plan

From Monday 5 October 2026 to the deadline is just over 15 weeks, with the holidays in the middle. That is tight but workable if you prioritise by shipping date: families with EU units going out in January come first.

1. Weeks 1 and 2 (5 to 16 October): scope. List every machine family that will ship EU units after 20 January 2027. For each, list the safety-relevant software and data: safety program, compliance-critical standard code, drive and sensor safety parameters, HMI, firmware, remote gateway. Name one owner per family.
2. Weeks 3 and 4 (19 to 30 October): risk assessment and gaps. Update the risk assessment for connections, remote access, malicious attempts and the update path. Check what your controller platform provides and what is switched on.
3. Weeks 5 to 9 (2 November to 4 December): build. Software identification screen, baseline comparison, access control on engineering and remote access, the tracing log with five-year capacity, signed updates and per-serial-number records in the back end.
4. Weeks 10 and 11 (7 to 18 December): test it the way a technician and an attacker would. Change a safety parameter directly with the vendor tool and confirm the machine records it. Swap a controller and check the log survives. Cut the power during an update.
5. Weeks 12 and 13 (21 December to 1 January): holidays. Plan no engineering work; leave a soak test filling the log towards its five-year size.
6. Weeks 14 and 15 (4 to 15 January): documentation and release. Technical file entries for 1.1.9 and 1.2.1, instructions for use explaining how a customer reads the software identification and what remote access can and cannot do, and a production step that loads the released baseline and records it per serial number.

If more platform architectures need this than fit in that window, tell sales now: a unit that is not ready cannot lawfully be placed on the EU market.

Who This Is Not For

Machines placed on the market before 20 January 2027 are not reached by these software rules, unless someone later modifies them substantially. If you buy machines rather than build them, the duty sits with your supplier; your part is to ask for the software identification and log access in your specifications.

Where to Get Help

We are a software company, not a notified body or a law firm. We build and change the software these requirements land in: HMI and back-end applications, remote access gateways, update pipelines and evidence logging, working alongside the controls engineers who own the safety program. Older platforms with years of accumulated code are the hardest case, which is where our legacy system maintenance work usually starts, and the CRA side is covered in our Cyber Resilience Act guide. If your team has the plan but not the hands to finish it by January, write to office@c9group.dev.