In brief · As of October 2026
From 20 January 2027 the Machinery Regulation sets four requirements that in practice land on the control system. The machine must be protected against accidental and intentional corruption, including through connections to other devices. It must identify the software needed for safe operation and make that information available at all times in an easily accessible form. It must collect evidence of legitimate and illegitimate interventions in that software and its configuration (Annex III section 1.1.9). And interventions as well as safety software versions uploaded later must remain traceable for five years, for the authority only (Annex III section 1.2.1). An audit trail of every operator action is not in the text.
With the Machinery Regulation, cybersecurity becomes a requirement on the control system itself. In a conversation with a design engineer this week, this was the very first question: how deep does logging have to go? Is it enough to record which user level was logged in when, or does every program change have to be compared with the archived project?
The short answer: as deep as the risk assessment requires. This article separates what the text says, what we derive from it for a PLC-controlled machine and what is not required. How the assessment itself is built is covered in the article on the risk assessment under the CRA and the Machinery Regulation.
What does Annex III require of the control system?
Two sections of Annex III contain the cybersecurity requirements: 1.1.9 (protection against corruption) and 1.2.1 (safety and reliability of control systems). Section 1.1.9 addresses the machinery or related product, section 1.2.1 explicitly the control systems. Because software, configuration and interfaces live there, implementation ends up with PLC and HMI in practice.
- Protection against corruption (1.1.9): Connecting another device, including remotely, must not lead to a hazardous situation. Hardware components transmitting signals or data relevant for access to the safety-critical software must be adequately protected against corruption. Software and data critical for compliance with the safety requirements must be identified as such and adequately protected.
- Identify the software (1.1.9): The machine must identify the installed software needed for safe operation and be able to provide that information at all times in an easily accessible form.
- Evidence of interventions (1.1.9): The machine must collect evidence of legitimate and illegitimate interventions in that software, its modification and its configuration, and likewise of interventions in those hardware components.
- Five years traceable (1.2.1): Tracing logs of the data generated in relation to an intervention and of safety software versions uploaded after placing on the market must be enabled for five years after the upload, solely to demonstrate conformity following a reasoned request from the authority.
The regulation prescribes no method, format or technology.
What does "evidence of an intervention" mean on a PLC-controlled machine?
From here on it is interpretation. For a typical machine with PLC, HMI and remote maintenance router, we read it like this, as Werkspilot's assessment and not legal advice:
- HMI logins with user level and timestamp. This shows who could change parameters when.
- Detecting changes to PLC program and configuration, for example via a checksum of the loaded program or a comparison with the archived project. Store the event with old and new state, not the whole code.
- Firmware updates of PLC, HMI and safety controller with date and version. These are exactly the versions section 1.2.1 requires for five years.
- Physical interventions on configuration switches of safety equipment where there is no electronic record, for example via seals. A broken seal is evidence too.
- Remote access via the maintenance connection. The router's connection log belongs in scope if software or configuration can be changed through it.
Identifying the software can usually be solved with an info page on the HMI. It should read the loaded versions rather than show a text fixed at release, otherwise the display is wrong after the first firmware update.
How deep does logging have to go?
As deep as interventions can lead to a hazardous situation. Section 1.2.1 explicitly names reasonably foreseeable malicious attempts by third parties leading to a hazardous situation. A parameter that disables a protective function needs complete evidence. A recipe change without a safety function does not. The risk assessment draws the line and should justify it.
Two documents give orientation, neither of them binding. The draft standard FprEN 50742 (protection against corruption) is in the final vote as of October 2026 and not listed in the Official Journal. IEC 62443-3-3 describes auditable events as system requirement SR 2.8. For typical plants we consider security level 2 a realistic target; that is experience, not a requirement.
Where are the records kept for five years?
The regulation does not say where. Because many operators do not allow a permanent connection to the outside, the authoritative copy belongs on the machine itself, for example on storage in the HMI or PLC that survives updates. An additional copy at the manufacturer makes sense but does not replace the local one. Section 1.2.1 limits the purpose to demonstrating conformity to the authority. It contains no obligation to hand the records to customers or others.
Where does this overlap with the CRA?
From 11 December 2027 the CRA requires providing security-related information by recording and monitoring relevant internal activity, including access to or modification of data, services or functions, with an opt-out mechanism for the user (Annex I Part I point 2(l)). This too applies only insofar as the risk assessment calls for it. The purpose differs: the CRA wants security incidents to be detectable, the Machinery Regulation wants interventions to be demonstrable to the authority.
One logging concept can serve both if it is planned for both from the start. Conformity with one regulation does not automatically satisfy the other, as the Commission also stresses (FAQ v1.4 point 2.4.1). How the two regulations relate overall is covered in CRA and the Machinery Regulation for integrators and plant builders.
What is not required?
- No audit trail of every operator action, no specific technology, no format.
- No cloud connection and no permanent link to the manufacturer.
- No retrofitting of machines placed on the market before 20 January 2027, as long as they are not substantially modified (Art. 18).
- No handing over of records to third parties, except on a reasoned request from the authority.
Which interventions belong in the logging concept?
The table shows the form, not the content. The risk assessment decides which rows a machine needs.
| Intervention | captured by | stored in | retention | reference |
|---|
| Login, user level | HMI user management | HMI | per risk assessment | Annex III 1.1.9 |
| Change to PLC program or configuration | checksum, project comparison | PLC or HMI | 5 years | Annex III 1.1.9, 1.2.1 |
| Upload of safety software or firmware | version with date | PLC or HMI | 5 years after upload | Annex III 1.2.1 |
| Remote access | router connection log | router, copy on the machine | per risk assessment | Annex III 1.1.9 |
| Intervention on safety hardware | seal, switch position | on the machine, inspection record | until next inspection | Annex III 1.1.9 |
Risk assessment under the MR and CRA, per plant type.
Which interventions a machine has to record follows from the risk assessment. We produce it in two sessions, with outputs for both the Machinery Regulation and the CRA.
Risk assessment →
This article reflects the state as of October 2026 and is not legal advice. The regulation itself is authoritative; FprEN 50742 is a draft standard and the Commission FAQ is not binding.
