Sector · Manufacturing
Rules · 2026-10-16 · 4 min read
The Machinery Regulation puts *software logs* on the list for 2027
From 20 January 2027, machines placed on the market must log safety-relevant software changes for five years and be protected against corruption. For self-learning machines, the requirements go further.
The regulation and the date
Regulation (EU) 2023/1230, the Machinery Regulation, takes effect on 20 January 2027 [1]. It replaces the Machinery Directive and applies to machinery, partly completed machinery, interchangeable equipment and safety components placed on the market from that date. Think of it like the warranty on a washing machine: once you buy it, the rules in force that day apply, not the ones from when it was designed.
The regulation brings software to the front. If a change to a machine's software can affect safety, that change must be logged, and the log must be traceable for five years after the machine is placed on the market [1]. The machine must also be designed and built to prevent corruption and unauthorised modification of software [1].
What counts as safety-relevant
A safety-relevant software change is one that could affect whether the machine meets the essential health and safety requirements in Annex III of the regulation [1]. The line can be subtle: a patch that fixes a fault in an emergency stop routine is clearly relevant, but so might be a performance update that changes how the machine responds under load.
The manufacturer decides what counts, documents the reasoning and keeps a log. Five years is a long time in software, and the question of which version was running when something happened can turn up years after the event.
Self-learning machines get their own rules
Machines with self-learning behaviour, meaning they can adapt their operation on the basis of experience, face extra requirements [1]. The manufacturer must log changes to the learning algorithms and to the training data used, and those logs must also be kept for five years.
The point is traceability. If a robot in a factory learns over time how to move more quickly and later injures someone, the investigation will want to know what the machine had learned, when it learned it and from what data. A self-learning excavator that adjusts to different soil types is convenient until the day it digs through a gas pipe, and then the question is what it had been trained on and whether the training accounted for buried utilities.
Logs and the manipulation question
The regulation says the logs must be traceable, not how they must be protected. Traceability means being able to follow the thread from a machine's behaviour back to the software version and the changes that led to it. That's straightforward if the log sits on the machine and nobody has touched it, but less so if it's been exported, copied or archived on a system the manufacturer controls.
A log you can quietly edit is a diary. A log you can show hasn't changed is something closer to a receipt.
Where a digital witness fits
Here, the thing to seal is each safety-relevant software change as it is logged: the change identifier, the timestamp, the version number and a summary of what was altered. Sealing takes a fingerprint of that record, not the record itself, so the log never leaves the manufacturer's systems.
Anyone checking the log later, whether it's a notified body, an investigator or a court, can recalculate the fingerprint and compare it with the one sealed at the time. If they match, the record is exactly what was logged on the day. Change a single character and the fingerprint won't match.
For self-learning machines, the same applies to changes in algorithms and training data: seal a record of what changed, when and why, as each update happens.
What sealing a log record does is remove the need to trust that nobody with access to the system has edited it since. What it doesn't do is show that the change itself was safe, that the machine was properly maintained or that the log is complete. It shows that what you're looking at now is what was written then.
How it would work:
- Each time a safety-relevant change is logged, the system sends a fingerprint of that log entry to WitniumChain through the REST API, the SDK or the MCP server, and gets a witness ID back.
- The witness ID is stored alongside the log entry, or in a separate index.
- When someone asks to see the log, you share the record and the witness ID. They calculate the fingerprint and check it against the sealed one at the verification link.
The content stays with you. The first 2,000 witnesses a month are free. Full documentation is at witniumchain.com/docs.
What this means for you
If you manufacture or import machinery that will be placed on the EU market from 20 January 2027, ask:
- Which software changes in our machines could affect safety, and how are we documenting that reasoning?
- Where are safety-relevant software logs kept, and for how long?
- If an incident happened and someone questioned a log two years later, could we show it hadn't been altered?
- Do any of our machines learn from experience, and if so, what records are we keeping of algorithm and data changes?
- Who decides what counts as safety-relevant, and is that decision documented?
The regulation doesn't prescribe the method, but it does require traceability, and traceability depends on logs people can rely on.
What to watch
20 January 2027: the Machinery Regulation applies to machinery placed on the market from this date.
Notified bodies will publish guidance on how they assess software documentation and log traceability as the date approaches. The European Commission's machinery pages will be the place to watch for that [2].
Sources
- [1]Regulation (EU) 2023/1230 on machinery, EUR-Lex, 2023-06-29
- [2]Machinery Regulation: overview and guidance, European Commission, 2024-10-15
- [3]Regler for maskiner (gældende fra 20. januar 2027), Sikkerhedsstyrelsen (Denmark), 2024-09-12