The EU Machinery Regulation, Regulation (EU) 2023/1230, applies on a mandatory basis from 20 January 2027 and replaces the Machinery Directive 2006/42/EC (European Commission). For control software the change is real. Software can now be a safety component in its own right, control systems must resist foreseeable malicious attempts, and changes to safety software after delivery must be logged. If you build machines for the EU market, your PLC code and its documentation are now part of the conformity question.
This article walks through the software-relevant parts of the regulation, in the order a controls team will meet them, and ends with a practical checklist. We are engineers, not lawyers: use it to prepare your technical questions, then settle the legal interpretation with your CE partner or notified body.
The date: 20 January 2027, with no transition period
The regulation was adopted on 14 June 2023. The published text originally named 14 January 2027, and a corrigendum moved the application date to 20 January 2027. Machinery placed on the market before that date must still comply with the old directive. There is no period in which you can choose (European Commission). A machine shipped on 21 January 2027 must meet the new rules, so any machine you are designing now almost certainly falls under them.
What the EU Machinery Regulation 2027 says about software
Software can be a safety component
Article 3 defines a safety component as "a physical or digital component, including software" (Regulation (EU) 2023/1230, EUR-Lex). In practice this means safety software placed on the market on its own, for example a safety function package sold separately from the hardware, is treated like any other safety component. As ABB summarised it, software that performs a safety function becomes a safety component, and cybersecurity evidence belongs in the technical file (ABB).
Self-evolving safety functions need a notified body
Annex I Part A lists the categories that require third-party conformity assessment. Points 5 and 6 cover safety components with fully or partially self-evolving behaviour using machine learning approaches, and machinery with such systems embedded. Software that cannot learn or evolve is explicitly outside these points. For most PLC-based safety functions, which are deterministic, this changes nothing. It matters if you are experimenting with AI-based person detection or adaptive safety zones.
Protection against corruption (Annex III, 1.1.9)
Software and data that are critical for the machine's compliance must be identified as such and protected against accidental or intentional corruption. The machinery must also collect evidence of a legitimate or illegitimate intervention in that software. For a PLC project, this points to know-how and copy protection where appropriate, access levels in the PLC and HMI, signed or checksummed safety programs, and a record of who changed what.
Safety and reliability of control systems (Annex III, 1.2.1)
Control systems must be designed so that they withstand "reasonably foreseeable malicious attempts from third parties" that could lead to a hazardous situation. They must also enable a tracing log of interventions and of versions of safety software uploaded after the machine was placed on the market, kept for five years after each upload (EUR-Lex). That is a concrete engineering requirement: your update process must leave a record that survives for five years.
Digital instructions
Instructions may be provided in digital form. They must be printable and downloadable, available online for the lifetime of the machine and at least ten years after it is placed on the market, and supplied on paper free of charge within one month if the customer asks at the time of purchase. The EU declaration of conformity may also be digital under the same rule.
How this interacts with the Cyber Resilience Act
The Cyber Resilience Act applies in full from 11 December 2027, eleven months after the Machinery Regulation (European Commission). The Machinery Regulation asks whether a cyber attack could make the machine unsafe. The CRA asks whether the product with digital elements is secure in its own right, with vulnerability handling and security updates. Many machine builders will need to answer both questions for the same control system. Our separate guide to the Cyber Resilience Act for machine builders covers the second one.
| Requirement | Where | What it means for the controls team |
|---|---|---|
| Software as safety component | Art. 3 | Safety software sold separately is in scope |
| Self-evolving safety functions | Annex I Part A, 5 and 6 | Notified body needed for ML-based safety |
| Protection against corruption | Annex III 1.1.9 | Identify critical software, protect it, record interventions |
| Malicious attempts | Annex III 1.2.1 | Threat-aware control system design |
| Safety software update log | Annex III 1.2.1 | Keep a log for five years after each upload |
| Digital instructions | Art. 10 | Online for machine lifetime, at least ten years |
A practical checklist for your next machine
- List every software item and data set that affects compliance: safety program, safety parameters, drive safety settings, HMI user management.
- Run a machine cybersecurity risk assessment. IEC 62443 gives a structure that notified bodies and customers recognise.
- Define access levels in the PLC, the safety program and the HMI, and document who holds which password.
- Use the platform's integrity features: safety program signatures and checksums in TIA Portal or TwinCAT Safety, plus know-how protection where it makes sense.
- Design a safety software update process that writes a log entry for every upload and keeps it for five years.
- Record the safety software version on the machine and in the technical file at delivery.
- Move instructions to a format you can host for at least ten years.
Insights Unveiled: The New Machinery Regulation Explained
T脺V S脺D
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeWhere outside engineering help fits
Most of the work above is engineering, not law. It means writing the safety software description, mapping access levels, building the update and logging process into the PLC project, and producing documents your CE partner can drop into the technical file. Wartens supports machine builders' design and CE teams with safety-software documentation, machine cybersecurity risk assessment and update processes, working alongside your CE partner. We do not issue CE marking.
If your team is short on capacity for the software itself, our guide to outsourcing PLC programming as fixed work packages explains how we deliver new machine programs with this documentation built in, and our post on validating safety software to EN ISO 13849 covers the validation side.
Next step: send us the software structure and safety function list of one current machine. We will map it against Annex III and tell you what is missing. See our automation engineering services or contact us.
