The EU Machinery Regulation gives software a five-year memory

The rule in a sentence

If you make machinery, software changes that affect safety must now be logged and kept traceable for five years, starting 20 January 2027 ^[1].

That's the headline in the new EU Machinery Regulation, which replaces the old Machinery Directive. It's the first major machinery rule to treat software not as an afterthought but as a safety-critical part of the machine itself.

For manufacturers, it means a new kind of record-keeping. Think of it like a car's service book: years after a machine leaves the factory, someone may ask what version of the software it was running when something went wrong. The regulation says you need to be able to answer that question.

What counts as machinery

The regulation covers machinery, partly completed machinery, safety components, lifting accessories, chains, ropes, webbing, removable mechanical transmission devices and interchangeable equipment ^[1].

Machinery includes robots, industrial arms, lifts, cranes, forklifts and medical devices that are machines. A laptop isn't machinery under this rule. A robot mower is.

If it has moving parts and software controls them, the rule probably applies.

What the software requirements say

For safety-relevant software, three duties stand out ^[1]:

1. Log changes. Safety-relevant software changes must be logged and traceable for five years.
2. Protect against corruption. The machine must be protected against corruption of software and data.
3. Limit self-learning. Machinery with self-learning behaviour must have limits on what it may learn, how it learns and how changes are validated.

The five-year period matters because disputes, product recalls and liability claims often arrive long after the machine was sold. A manufacturer who cannot show which software version ran on a given day starts a difficult conversation at a disadvantage.

The self-learning part

Self-learning machinery gets special attention. The regulation says it must have limits on learning parameters, validation methods for changes and a way to revert to a previous state ^[1].

That's aimed at systems that adapt in the field, for example a robot arm that adjusts its movement patterns over time. The rule says the manufacturer must stay in control of what the machine learns and how.

It doesn't ban machine learning in machinery. It asks for guardrails.

When it applies

The regulation applies to machinery placed on the EU market from 20 January 2027 ^[1]. Machinery already on the market under the old Machinery Directive can stay there.

Substantial modifications are the tricky part. Bureau Veritas, a notified body, says that machinery undergoing substantial modification after 20 January 2027 must meet the new requirements ^[2]. What counts as substantial isn't always obvious, so manufacturers planning upgrades to older machines should check early.

How a digital witness makes software changes checkable

Here's where the logging duty meets the evidence question.

The thing to seal is each software release: the build fingerprint, the release notes, the test results and the deployment record showing when the release went onto which machine. Sealing takes a fingerprint of the record, not the record itself, so the details never leave your systems.

You seal at two moments: when a release is built and validated, and when it's deployed to a machine.

If a machine is questioned two years later, anyone you share the record with can check that it's exactly what was written at the time of deployment. The fingerprint either matches or it doesn't. If someone with administrator access quietly edits the log afterwards, the mismatch shows.

What it doesn't do: it doesn't show that the software was free of defects, or that the deployment was the only one, or that the machine actually ran that version. It shows that the record you keep hasn't been rewritten.

For manufacturers with dozens of machines in the field and releases every few months, this turns deployment history into something you can point at in a meeting with a notified body, an insurer or a lawyer, without anyone having to take your word for it.

How it would work

1. At release: seal the build fingerprint, notes and test results through WitniumChain with the REST API or SDK.
2. At deployment: seal the deployment event (machine serial, release version, timestamp).
3. Later: anyone can check that the records match the sealed fingerprints, using the documentation.

The content stays on your systems. The first 2,000 witnesses a month are free.

What this means for you

If you make machinery that will reach the market from 20 January 2027, here are four questions to ask this quarter:

• Which software in your machines is safety-relevant, and how do you define a safety-relevant change?
• Where are software versions and deployment records kept now, and who has access to edit them?
• If a machine caused an injury in 2029, could you show which software version it was running in 2027?
• For machines with self-learning behaviour, what are the limits on learning parameters, and how do you validate a change?

The regulation gives you two years to get the records in order. Leaving it until 2026 means doing it under pressure.

What to watch

The first harmonised standards under the regulation are expected in 2026, and they will spell out what counts as adequate logging and traceability. Until then, manufacturers are working from the regulation text itself ^[1].

Notified bodies are already being designated under the new rules, so conformity assessments for high-risk machinery will start before the regulation applies ^[2].

If your machinery overlaps with the AI Act's high-risk categories, for example in Annex I section 3 (safety components) or Annex II (machinery for use in specific high-risk environments), check how the two regimes fit together. Both ask for logs, and a digital witness works for both.