The EU Machinery Regulation 2027: What Robot Makers and Deployers Must Do Before 20 January, 2027.

By Endy Idahosa, Lead AI/ML Engineer, Xium Labs

Key takeaways

From 20 January 2027, the EU Machinery Regulation (2023/1230) replaces the Machinery Directive that has governed CE marking for two decades. For the first time, protection against cyber attack becomes part of the conformity assessment itself: machinery whose safety can be compromised digitally cannot lawfully carry the CE mark. Robots, cobots and automated systems with connectivity or AI are squarely in scope. Manufacturers carry the heaviest duties, but importers, integrators and companies that substantially modify machinery inherit obligations too, and UK firms selling into the EU meet the rules in full. The window to prepare is now measured in months.

Most compliance deadlines arrive quietly. This one arrives with teeth. On 20 January 2027 the EU Machinery Regulation (2023/1230) applies in full across the European Union, and with it, the legal definition of a safe machine changes. A robot that can be hacked is no longer just insecure. In the eyes of EU law, it is unsafe, and unsafe machinery does not get a CE mark or a place on the European market.

We wrote recently about the humanoid robots now being deployed across the UK and Europe and the security questions that deployment raises. This piece goes deeper on the regulation that turns those questions from good practice into law, because in our work across AI and offensive security we keep meeting the same gap: engineering teams who know the Machinery Directive well and have not yet clocked how different its replacement is.

What is the EU Machinery Regulation (2023/1230)?

The Machinery Regulation is the EU's core product law for machinery: everything from industrial robots and cobots to production lines, lifting equipment and increasingly the software that drives them. It was adopted in June 2023 and, after a transition period, applies from 20 January 2027, replacing the Machinery Directive (2006/42/EC) outright.

Two structural changes matter before we even reach the content. First, it is a regulation rather than a directive, which means it applies identically in every member state with no national transposition and no local variations to arbitrage. Second, there is no grace period for products already in the pipeline: from the application date, machinery placed on the EU market must conform to the new rules. A robot that ships on 19 January 2027 under the old directive is lawful; the same robot shipped a month later under the same paperwork is not.

Machinery Regulation vs Machinery Directive: what actually changes

The old directive was written before machines were routinely networked, updated over the air, or driven by learning software. The regulation was written because of those things. Four changes stand out for anyone building or deploying robotics.

Cybersecurity becomes a safety requirement

This is the headline change. The regulation's essential health and safety requirements now demand protection against corruption: machinery must be designed so that a connection to any external device, network or remote access channel cannot lead to a hazardous situation, and so that safety functions cannot be defeated, whether accidentally or by a malicious third party. Evidence of interference must be traceable. In practical terms, the manufacturer must perform and document a cybersecurity risk assessment as part of CE conformity, covering the machine's connectivity, its software and its update mechanisms. No assessment, no valid CE file, no market access.

Software and AI are explicitly in scope

Safety-related software is treated as a safety component in its own right, including software placed on the market separately. Machinery with self-evolving behaviour, meaning systems whose logic changes after deployment through machine learning, faces additional scrutiny, and certain categories of machinery embedding AI safety functions are steered towards third-party conformity assessment rather than pure self-certification. If your robot's safe behaviour depends on a model rather than a relay, the regulation knows, and it has opinions.

Substantial modification creates a new manufacturer

Modify a machine substantially, including through software, and you can become its legal manufacturer, inheriting the full conformity burden for the modified machine. Integrators and end users who retrofit autonomy, connectivity or new AI capabilities onto existing equipment should read that sentence twice. A firmware change that alters safety behaviour is not a maintenance event; it can be a regulatory one.

Digital documentation is permitted

A smaller but welcome change: instructions and the EU declaration of conformity may now be supplied digitally, though a paper copy must be available on request and safety-critical information still has to accompany the product.

Who carries the obligations

The manufacturer carries the core duties: design to the essential requirements, perform the risk assessment including cybersecurity, compile the technical file, affix the CE mark. But the regulation distributes obligations along the whole chain. Importers and distributors must verify conformity before placing machinery on the market. Anyone performing a substantial modification becomes a manufacturer for the machine as modified. And while deployers are not the primary target of this instrument, they inherit the practical consequences: machinery bought after the deadline without a compliant file is a procurement failure with legal exposure attached, and insurers and workplace safety regulators will treat the CE file as the baseline evidence that a machine was safe to operate.

For anyone renting rather than buying, including the Robot-as-a-Service models now arriving in the UK and Europe, the same logic applies through the contract: the question of who holds the conformity file, and who answers for the cybersecurity risk assessment of the machine as deployed in your environment, belongs in the agreement, not in the post-incident review.

How it interacts with the Cyber Resilience Act and the AI Act

The Machinery Regulation does not arrive alone, and the three instruments are designed to interlock rather than duplicate.

The Cyber Resilience Act (2024/2847) governs products with digital elements across their whole lifecycle: secure development, vulnerability handling and mandatory reporting, with reporting duties beginning on 11 September 2026 and penalties reaching 15 million euros or 2.5 per cent of global turnover. Where the Machinery Regulation asks whether a cyber weakness makes the machine unsafe, the CRA asks whether the product was built and maintained securely at all. A robot manufacturer will typically answer to both.

The AI Act adds obligations where AI performs high-risk functions or acts as a safety component, with the relevant duties phasing in through 2027 and 2028 following the Digital Omnibus adjustments of May 2026. Helpfully, the frameworks are aligned so that one properly scoped risk assessment and technical file can serve more than one regime, which is exactly how sensible engineering teams should approach it: one security and safety case, mapped to three sets of requirements, rather than three parallel paper exercises.

Does the Machinery Regulation apply to UK companies?

Not directly on the domestic market, where UK product rules and the UKCA/CE arrangements continue on their own track. In practice, though, the exemption is narrower than it looks. Any UK manufacturer or integrator selling machinery into the EU must comply in full. Any UK deployer buying robotics built for the European market will receive machines engineered to these requirements anyway, and should demand the same evidence, because a vendor who cannot produce a cybersecurity risk assessment for the EU has told you something about the machine you are putting on your own network. And UK law is moving the same direction on product security generally. Treating the Machinery Regulation as your baseline is not gold-plating; it is buying the version of the machine the rest of the market will insist on.

A practical checklist for the next twelve months

For manufacturers and integrators, the work between now and January 2027 looks like this:

1. Inventory every product and project that will be placed on the EU market or substantially modified after 20 January 2027, and map each against the regulation rather than the directive.

2. Perform a cybersecurity risk assessment for each machine covering connectivity, remote access, software supply chain and update mechanisms, and integrate it into the safety risk assessment rather than filing it separately.

3. Test the assumptions. A risk assessment that has never been challenged by an actual attack exercise is a hypothesis, not evidence. Penetration testing of the machine, its companion applications and its cloud services is the fastest way to find the gap between the file and the machine.

4. Establish secure update and vulnerability handling processes that satisfy both the Machinery Regulation and the Cyber Resilience Act's timelines, including the 24-hour reporting duty that begins in September 2026.

5. Review contracts, for integrators and RaaS arrangements especially, so that responsibility for the conformity file, modifications and incident response is written down before the machines ship.

6. Check whether any AI-driven safety function pushes the product towards third-party conformity assessment, and book the notified body early, because capacity will tighten as the deadline approaches.

For deployers, the list is shorter: ask for the CE file and the cybersecurity risk assessment before purchase, put conformity responsibilities into the contract, and segment and monitor the machine on your network as you would any other connected system, a discipline we set out in detail in our article on humanoid robot security.

where Xium Labs fits

The gap the regulation exposes is the one we work in. Xium Labs builds AI products and intelligent automation, and our offensive security practice tests connected systems the way attackers approach them, from AI models and LLM-driven functions to the APIs and networks machines depend on. That combination is what a defensible cybersecurity risk assessment needs behind it: not a template, but evidence that someone tried to break the machine and documented what happened. If you are working towards January 2027, or buying machinery from someone who should be, talk to us before the deadline does the negotiating for you.

Frequently asked questions

When does the EU Machinery Regulation apply?

From 20 January 2027, in full, across all EU member states. It replaces the Machinery Directive (2006/42/EC) on that date, with no transition for products placed on the market afterwards.

Does the Machinery Regulation really require cybersecurity?

Yes. Its essential health and safety requirements demand that machinery be protected against corruption, that external connections cannot create hazardous situations, and that safety functions resist both accidental and malicious interference. The cybersecurity risk assessment becomes part of the CE conformity assessment.

Does it apply to software on its own?

Safety-related software is treated as a safety component and falls in scope even when placed on the market separately from the machine it controls.

What happens if we modify a machine we already own?

A substantial modification, including through software, can make you the legal manufacturer of the modified machine, with responsibility for its full conformity, including the cybersecurity assessment. Plan retrofits of connectivity or AI with that in mind.

We are a UK company. Can we ignore it?

Only if you neither sell into the EU nor buy machinery built for the European market, which describes almost nobody in UK manufacturing or robotics. Selling into the EU means full compliance; buying from EU-focused vendors means you should demand the same evidence the regulation requires of them.

Endurance Idahosa is the founder of Xium Labs, a UK AI and cybersecurity company operating from London and Teesside, working across AI products, intelligent automation and offensive security. His background spans penetration testing and data science, and he writes on applied AI, automation and securing the systems that run on both.