The Machinery Regulation asks for a *five-year trail* of software changes

A five-year receipt for every change

Most machines keep a service log in a folder somewhere. The EU's Machinery Regulation wants something more: a traceable record of every safety-relevant software change, kept for five years and protected against corruption ^[1].

It's the same idea as when a mechanic stamps your service book. The difference is that software changes don't leave oil stains, so the trail has to be deliberate.

The regulation applies from 20 January 2027 to machines placed on the market from that date ^[1]. It replaces the Machinery Directive and brings cybersecurity, software traceability and self-learning systems into the safety rules for the first time.

What counts as safety-relevant

Not every firmware tweak needs logging. Safety-relevant means changes that affect the machine's ability to keep people safe: updates to safety controllers, modifications to emergency stop logic, changes to speed limits or collision avoidance, and patches that fix a known hazard ^[1].

A cosmetic change to a display probably doesn't count. A change to the PLC program that controls a robotic arm almost certainly does.

The regulation doesn't define safety-relevant in one sentence, but the pattern is clear: if a failure in that software could cause injury, the change is safety-relevant.

The five-year rule

Each logged change must be traceable for five years from when the machine was placed on the market ^[1]. That doesn't mean five years from the change itself, but from the day the machine left the factory gate or the warehouse.

So if a robot is sold in March 2027 and gets a safety patch in August 2029, the record of that patch must be kept until at least March 2032.

The practical question is how to prove, years later, that a log hasn't been quietly edited. A spreadsheet on the engineer's laptop isn't going to convince a notified body or an insurer.

Protection against corruption

The regulation requires machines to be protected against corruption ^[1]. In software terms, that means unauthorised changes to code, configuration or logs.

Access control is the foundation: only authorised people can push updates. Monitoring is the next layer: you log who did what, and when. But those measures still leave a gap, because the people with legitimate access are also the ones who could change the logs.

That's where a sealed record helps. A fingerprint taken at the moment a change is logged shows whether the log has been altered since, even by someone with administrator rights.

Machines that learn

Machines with self-learning behaviour get special attention ^[1]. A collaborative robot that adapts its movements based on sensor data, or a welding system that tunes its parameters through machine learning, has to meet extra requirements.

The manufacturer must assess risks arising from the learning itself, ensure the machine stays within safe limits, and document how the learning is controlled ^[1].

For those machines, logging isn't just about the updates you push. It's also about the changes the machine makes on its own.

What this means for you

If you make, integrate or maintain machines sold in the EU, start asking these questions now:

• Which of your software changes are safety-relevant?
• Who logs them, in what format, and where is that log kept?
• Could you show, three years from now, that a log record hasn't been edited?
• For machines with learning behaviour, how do you document what the machine learned and when?
• How do you protect your update process and logs against corruption?

The notified bodies that assess machinery conformity are going to ask. So will insurers, once the first claim turns on which version was running.

A sealed change log

Here's where a digital witness fits. The thing to seal is each safety-relevant software change as it is logged: the machine identifier, the change description, the version number, the person who approved it and the date.

Sealing takes a fingerprint of that record, not the record itself, so the log stays in your own systems. Years later, when someone asks whether the log has changed, you calculate the fingerprint again and compare it with the sealed one. If they match, nothing has changed. Alter a single character and it won't match.

Anyone you share the record with can check it themselves, without having to trust whoever kept the log.

WitniumChain (get access) gives you that checkable trail through a REST API, an SDK or an MCP server. The record itself never leaves your systems, and the first 2,000 witnesses a month are free. Documentation shows how to seal a record in three lines of code.

What it doesn't do is decide what counts as safety-relevant, or replace your change management process. It doesn't make you compliant with the regulation. It gives you a way to show that the log you kept is the log you're presenting, unchanged.

How it would work

1. Your maintenance system logs the change.
2. It sends a fingerprint of that log entry to WitniumChain and gets a witness ID back.
3. When the notified body or an insurer asks, you produce the log and the witness ID. They calculate the fingerprint themselves and check it against the sealed one.

What to watch

The regulation applies from 20 January 2027. Machines already on the market under the old Machinery Directive are not affected, but anything placed on the market from that date must comply ^[1].

Notified bodies are still working out how they will assess software traceability in practice. The first assessments will set the pattern for everyone else.

The AI Act's high-risk requirements for safety components of machinery come into force on 2 August 2027 ^[2]. Some machines will fall under both regimes.

Sources

1. Regulation (EU) 2023/1230 of the European Parliament and of the Council on machinery, EUR-Lex, 29 June 2023, https://eur-lex.europa.eu/eli/reg/2023/1230/oj
2. Timeline for the implementation of the EU AI Act, European Commission AI Act Service Desk, https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act