Machinery Regulation 2023/1230: what actually changes for AGVs and AMRs

On 20 January 2027, Regulation (EU) 2023/1230 replaces the Machinery Directive 2006/42/EC. The date is a cliff edge, not a transition: any machine placed on the European market from that day onward must comply with the Regulation. There is no grace period during which both texts coexist for new placements. Four months from the deadline, many mobile-robot manufacturers and integrators are still discovering the size of the task.

The first change is often underestimated: it is a regulation, no longer a directive. It applies directly and uniformly across the Union, with no national transposition. The interpretation nuances between Member States that had been part of the landscape since 2006 disappear — and with them a certain flexibility that borderline cases used to enjoy.

Why are AGVs and AMRs first in line? Because they combine everything the legislator wanted to regulate more closely: autonomous movement among people, software-driven behaviour, remote updates, and ever more functions marketed as 'intelligent'. Large parts of the text were written with them in mind.

The most structural change is the status of software. Software performing a safety function is now explicitly a safety component within the meaning of the Regulation — including when it is placed on the market separately from the machine. That means its own technical documentation, a declaration of conformity, marking, and clear liability for whoever supplies it. For fleet-management software vendors whose products drive stop or slow-down functions, this is a different world.

Second major novelty: cybersecurity becomes part of machinery compliance. The Regulation requires the machine to withstand corruption attempts, accidental or malicious, wherever they could compromise a safety function. Concretely: an AMR whose safety stop can be defeated by a network attack is non-compliant, however robust it is mechanically. Software interventions must also be traceable — version logs, evidence of embedded code integrity.

Third key concept: substantial modification. Whoever substantially modifies a machine in service — new function, new safety perimeter, changed behaviour — legally becomes its manufacturer, with the full set of obligations: technical file, conformity assessment, CE marking. For AGV fleets, where retrofits, major software upgrades and zone extensions are daily business, the line between maintenance and substantial modification becomes a first-order contractual question.

Then comes the topic everyone talks about, not always accurately: AI. Annex I Part A of the Regulation lists machinery whose conformity assessment must involve a third-party body — and it includes systems with fully or partially self-evolving behaviour performing safety functions. The nuance is crucial: it is AI inside the safety function that triggers the obligation, not AI in general.

In practice, most of today's industrial AGVs and AMRs keep a deterministic safety architecture: certified laser scanners, fixed safety fields, a hard-wired stop chain. Navigation can be as 'smart' as you like: as long as safety does not rest on self-evolving behaviour, self-certification through internal checks (Module A) remains possible. This is as much an architecture choice as a compliance one — and it deserves to be made consciously, early in the design.

Good news amid the constraints: digital documentation is finally recognised. Instructions and the EU declaration of conformity may be supplied in digital form — a paper copy remaining a right for any user who requests it. For fleets of dozens of machines updated several times a year, this is a real simplification.

What about the installed base? The Regulation is not retroactive: a machine lawfully placed on the market under the Directive remains so. But beware of the trap — a substantial modification after 20 January 2027 brings the modified machine under the Regulation, with today's requirements applied to a platform designed yesterday. Some ambitious retrofits will cost more in compliance than in engineering.

The watch item for the coming months: harmonised standards. Presumption of conformity will flow from a new generation of standards cited in the Official Journal under the Regulation — and that harmonisation calendar is not yet settled. The reasonable strategy: design to the current normative state of the art (EN ISO 3691-4 for driverless trucks, ISO 13849 for safety functions), document the gaps, and watch the OJ publications quarter by quarter.

Where to start, four months from the deadline? Inventory what will be placed on the market after 20 January 2027 and check which technical files must switch over. Map the safety functions that depend on software, and who supplies them. Audit your remote-update processes against the traceability requirement. Clarify contractually who carries 'manufacturer' liability in case of substantial modification. And settle the Annex I question explicitly: does your safety rest on self-evolving behaviour, yes or no?

This Regulation rewards clean architectures: deterministic safety clearly separated from application intelligence, safety software identified and versioned, a crisp chain of responsibility between manufacturer, integrator and operator. If you want an outside eye on your gap analysis — or a sparring partner for the architecture trade-offs that follow — that is exactly the kind of engagement we run at Hetev.