The EU Machinery Regulation wants a *five-year audit trail* for safety software

A receipt for every safety update

Imagine buying a dishwasher that quietly updates its own software overnight. Five years later it catches fire and someone asks: which version was running, and when did it change? Under the old Machinery Directive, nobody had to keep that receipt. Under the new Machinery Regulation, they do.

Regulation (EU) 2023/1230 takes effect on 20 January 2027 for machines placed on the market from that date ^[1]. It replaces the Machinery Directive and extends the rules to cover software much more explicitly. One detail stands out: safety-relevant software changes must be logged and kept traceable for five years ^[1]. That is longer than most warranties, and it matters because disputes about product defects can surface long after the machine left the factory.

What counts as a machine

The regulation applies to machinery, partly completed machinery, interchangeable equipment, safety components, lifting accessories, chains, ropes, webbing, removable mechanical transmission devices and related products ^[1]. Software is now explicitly part of that picture. A robot mower, a medical ventilator, a factory arm and a building lift all count, as does the software that controls them.

For the first time, a machine with self-learning behaviour gets its own mention. The regulation requires manufacturers to document how such systems adapt, what data they use and how they are monitored ^[1]. That is a step beyond static software, where the logic does not change after release.

The five-year log

Safety-relevant software changes must be logged and those logs must stay traceable for five years ^[1]. The regulation does not spell out the format or the method, but it is clear about the outcome: if someone asks what changed and when, the manufacturer must be able to show it.

Five years is a long time in software. Developers move on, systems are replaced and backups go stale. A log from 2028 that gets challenged in 2033 needs to have stayed intact, and a court or a notified body will not take the manufacturer's word for it.

The regulation also says machines must be protected against corruption ^[1]. That means guarding both the machine itself and its records against tampering. An audit trail someone could quietly rewrite is not much of an audit trail.

What this means for you

If you make or sell machines, here are four questions worth asking now:

1. Which software changes in your machines count as safety-relevant, and who decides?
2. Where do those change logs live, and will they still be readable in five years?
3. Could you show a notified body or a court that a log from 2028 has not been edited?
4. For machines with self-learning behaviour, how do you document what the system learned and when?

CE marking, risk assessment and technical documentation are still required ^[1], and the new software requirements sit on top of that foundation. Manufacturers who already version their code and keep changelogs are halfway there. The hard part is proving the log has not changed, especially when the people keeping it are the same people who could edit it.

How a digital witness would work here

The thing to seal is each safety-relevant software update: the version identifier, the release notes, the test results and the timestamp. Sealing takes a fingerprint of that record, not the record itself, so it never leaves your systems. The fingerprint is sent to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back.

Five years later, when a notified body or a court asks which version was running in March 2029, you produce the sealed record and anyone can check the fingerprint. If it matches, the record has not changed since it was sealed. Change a single character in the release notes and it will not match.

A digital witness does not replace version control, testing or quality assurance. It does not show that a version was free of defects or that the machine was safe. What it does is let you prove which version existed when, without anyone having to trust that you have not quietly rewritten the changelog.

The first 2,000 witnesses a month are free. Read the docs at witniumchain.com/docs.

How it would work

1. At release: seal the version record (identifier, notes, test results, timestamp).
2. At deployment: seal the deployment event (which version, which machine, when).
3. Years later: show the sealed records and let anyone check the fingerprints.

What to watch

The regulation applies from 20 January 2027 for machines placed on the market from that date ^[1]. Machines already on the market under the Machinery Directive are not suddenly required to comply, but any new machine or substantially modified machine will be.

The new EU Product Liability Directive, which treats software as a product from 9 December 2026, sits alongside this ^[2]. Together they mean that when a machine's software causes harm, the question of which version was running and what it contained will matter in court as well as in a conformity assessment.

If your machines learn or adapt, the documentation requirements go further. Decide now how you will show what the system learned, which data it used and how you monitored it, because those questions will come up during the conformity assessment and possibly in a dispute years later.