The EU Machinery Regulation (EU) 2023/1230 replaces the Machinery Directive 2006/42/EC. It is the legal framework a machine must comply with before it gets the CE marking and is placed on the EU market. The Regulation entered into force in 2023 and applies in full from 20 January 2027, the date the old Directive is repealed. For PLC programmers the main change is legal. A Directive had to be transposed into national law, while a Regulation applies directly and identically in every Member State. The Regulation also says much more about software than the Directive did. Safety-related code, remote updates, network connections and logic that learns from data now appear explicitly in the essential health and safety requirements (EHSRs) of Annex III. Before, they were inferred from general wording.
In particolar modo vedremo:
Why control software is now explicitly in scope
Under the Directive, a PLC program was part of the “control system” requirement. It was mostly assessed through harmonised standards such as EN ISO 13849-1 and EN IEC 62061. The Regulation keeps that link but adds obligations that apply directly to the code and to how the code is managed after delivery. Three areas matter most to anyone who writes or maintains machine logic.
- Protection against corruption (Annex III, section 1.1.9). Connecting the machine to another device, or to a remote system, must not create a hazardous situation. Hardware and software that carry safety-critical signals or functions must be protected against accidental or deliberate corruption. Safety software has to be identifiable, and the machine must be able to collect evidence of legitimate or illegitimate interventions on it.
- Safety and reliability of control systems (section 1.2.1). This requirement now covers resistance to malicious attempts that could lead to a hazard. It also requires a log of interventions and of safety-related software versions uploaded after the machine was placed on the market. The log must be retained for five years after each upload and used only to demonstrate conformity.
- Self-evolving behaviour. Control logic that changes its behaviour through machine learning must stay within the task and movement space defined in the risk assessment. Safety components that use such logic, and machines that embed them for safety functions, move into the category that needs third-party conformity assessment (Annex I, Part A).
In practice, your code now needs a documented security posture and real version control. Field changes also have to be traceable, which means an online edit with no record behind it is no longer acceptable.
Directive 2006/42/EC vs Regulation 2023/1230: comparison
| Topic | Directive 2006/42/EC | Regulation (EU) 2023/1230 |
|---|---|---|
| Legal form | Transposed into national law, so wording could vary between countries | Directly applicable with identical text in all Member States |
| Software as a safety component | Implicit at best | Explicitly recognised, including software placed on the market on its own |
| Cybersecurity | Not addressed | EHSRs 1.1.9 and 1.2.1 require protection against corruption and malicious intervention |
| Traceability of software changes | No specific requirement | Log of interventions and uploaded safety-software versions, kept for five years |
| AI / machine learning | Not addressed | Self-evolving safety logic listed among the high-risk categories in Annex I, Part A |
| Substantial modification | Covered only by guidance, interpreted differently in each country | Legally defined. Whoever substantially modifies a machine takes on the manufacturer’s obligations |
| Instructions | Paper | Digital format allowed. A paper copy must be supplied free of charge if the buyer asks at the time of purchase |
Step-by-step: preparing a PLC project for 20 January 2027
The sequence below is for an integrator or OEM software team. It assumes you already work to EN ISO 13849-1 or EN IEC 62061 and that you have a risk assessment for the machine.
- Find out which legal framework your delivery falls under. A machine placed on the market before 20 January 2027 can still be certified under the Directive. From that date, new machines must meet the Regulation. If commissioning straddles the date, design to the Regulation now.
- Separate safety-related code from functional code. Put safety functions in clearly bounded program units, ideally on a safety PLC or a safety task with its own checksum or signature. Section 1.1.9 requires safety software to be identifiable, and that is much easier when it isn’t spread across standard routines.
- Lock down how changes reach the controller. Disable or password-protect online editing of safety programs. Restrict engineering-station access by role and close any programming ports and services that are not needed. Write down in the technical file which interfaces can change the program and how each one is protected.
- Implement the intervention log. Make sure every upload of safety-related software records at least a version identifier, a checksum, a timestamp and the source of the change. Many safety controllers already keep a change history. Check that it survives power cycles and firmware updates and that the records can be exported, because they must be kept for five years.
- Assess the network attack surface in the risk assessment. Treat remote-access gateways, OPC UA servers, MQTT bridges and HMI web servers as possible ways of corrupting the system. IEC 62443 (in particular 62443-4-2 for components and 62443-3-3 for systems) is the usual reference for the countermeasures, even though it is not yet harmonised under the Regulation.
- Check for self-evolving logic. If an adaptive algorithm, a trained model or an auto-tuning routine influences a safety function, the product may fall under Annex I, Part A. In that case a notified body must be involved, so flag it to your project manager early.
- Update your harmonised-standards references. The presumption of conformity depends on standards cited in the Official Journal under the new Regulation. Check the current list before you rely on a specific edition of EN ISO 13849-1 or EN IEC 62061.
- Plan the documentation. Safety function specifications, PL/SIL verification, software validation records, the cybersecurity description and the change log all go into the technical file. The manufacturer must keep the technical file for ten years after the machine is placed on the market.
Substantial modification: the retrofit trap
Retrofit jobs carry the most legal risk for a PLC programmer. The Regulation defines a substantial modification as a change that was not foreseen by the original manufacturer and that affects safety. Typical examples are a change that creates a new hazard or increases an existing risk, so that new protective measures or a change to the safety control system are needed. If you make such a change, you become the manufacturer for the modified machine. That applies whether you are the end user or the integrator working for them, and it means a conformity assessment and CE marking for the affected scope.
Some typical cases in control work:
- Raising axis speeds or forces beyond the original design limits.
- Removing or bypassing a guard interlock and replacing it with a software function.
- Adding a robot cell, a new operating mode or remote operation to a line that never had one.
Replacing an obsolete PLC with a newer model is usually not a substantial modification if the safety functions and their performance levels are reproduced one-to-one. Record that reasoning in writing, because you will need it if the change is questioned later.
Frequently asked questions (FAQ)
Do machines already in service need to be recertified in 2027?
No. The Regulation applies to machinery placed on the market or put into service from 20 January 2027. Machines already in use do not have to be re-assessed. A later substantial modification brings the modified machine under the new rules. Workplace safety obligations for existing equipment remain under the separate Work Equipment Directive 2009/104/EC.
Is a standalone software update considered a safety component?
It can be. The Regulation recognises that software performing a safety function and placed on the market separately can be a safety component in its own right. If you distribute a safety-related update to machines you did not build, check whether that brings you under the manufacturer’s obligations for that component.
Does the Regulation require IEC 62443 certification?
No. The Regulation sets requirements, not certification schemes. IEC 62443 is a recognised way to show that the cybersecurity-related EHSRs are met, and the overlap with the Cyber Resilience Act (EU) 2024/2847 makes aligning with it a good idea. A certificate is not a legal requirement under 2023/1230.
Can I still use EN ISO 13849-1 for PL calculations?
Yes, and in practice you will keep doing so. Make sure the edition you use is cited in the Official Journal for the Regulation, not only for the old Directive. Without that citation it gives you no presumption of conformity. In that case you have to show compliance with the relevant EHSRs directly in your technical file.
“Semplifica, automatizza, sorridi: il mantra del programmatore zen.”
Dott. Strongoli Alessandro
Programmatore
CEO IO PROGRAMMO srl
