The Machine Regulation brings *five-year traceability* for safety-relevant software

A regulation where software matters

The Machine Regulation applies from 20 January 2027 and replaces the Machinery Directive ^[1]. It covers machinery, related products and safety components placed on the market after that date. If you make industrial robots, construction equipment, lifts, automated warehouse systems or anything else that counts as machinery under the regulation, the rules change.

One change stands out: the regulation treats software as part of the machinery's safety, and it asks manufacturers to prove what changed and when. Think of it like this. A car's service history shows which parts were replaced and when. The Machine Regulation wants the software equivalent: a record of every safety-relevant change, kept in a form you can show a notified body or an inspector five years later.

What the regulation says about software

Annex III, section 1.2.1, says machinery must be designed and constructed so that it is protected against corruption, and that safety-related software changes are logged and traceable ^[2]. That applies to the machinery itself and to any safety function that depends on software.

Section 1.1.9 adds a rule for machinery that can modify its behaviour through machine learning or logic ^[3]. The manufacturer must describe how it learns, what data it uses, the limits it observes and the metrics it is validated against, and that documentation has to cover the whole lifecycle. In plain words: if your machine teaches itself something that affects safety, you must be able to explain what it learned, when and from what.

The five-year traceability duty runs from the date the machinery is placed on the market ^[2].

What this means for you

If you make machinery, here are three questions to ask this week.

First, which software changes in your machinery count as safety-relevant? That includes firmware, control logic, vision systems, path planning and anything else a risk assessment says matters. Once you know that, you know what to log.

Second, where will those logs live, and who can reach them? The regulation doesn't prescribe a system. It asks for traceability: when an inspector or a notified body asks what changed in version 2.4.1 on 3 March 2025, you must be able to show them, five years on. An internal wiki or a version control system is a start, but traceability also means showing that the record is the one written at the time, not edited later.

Third, how will you show that the log hasn't been quietly rewritten? A log the manufacturer keeps and could edit is a diary. A log that can be checked against an independent record is evidence. The regulation wants the second.

Sealing software changes as they happen

Here, the thing to seal is each safety-relevant software change: the version identifier, the release notes, the test results and the deployment date. Sealing takes a fingerprint, not the code itself, so the software never leaves your systems.

When it's sealed, the fingerprint goes to WitniumChain, which returns a witness ID and stores the fingerprint in a way that any later change would show. If an inspector or a notified body asks about a version three years later, you share the log with them and they check it. They calculate the fingerprint again from the version you hand them, compare it with the sealed one, and see that it matches. If someone had quietly edited the release notes, the fingerprints wouldn't match.

The regulation doesn't require this, but it does require traceability for five years. A digital witness gives you a way to show that the record you keep today is still the one you show in 2032.

You can seal changes as part of your build pipeline, through the REST API, the SDK or the MCP server. The content stays with you. Read more at the documentation.

How it would work

1. At release, seal the version identifier, release notes and test results.
2. At deployment, seal the deployment event with the machine serial number and date.
3. When asked, share the sealed record and let the recipient check it.

Machines that learn

Section 1.1.9 is new ^[3]. If your machine modifies its own behaviour through machine learning or logic, you must document how it learns, which data sets it uses, the limits it observes and the validation metrics. That documentation must cover the whole lifecycle, meaning it has to be updated as the machine learns.

This is harder than it sounds. A self-learning welding robot or an automated inspection system that improves over time doesn't just run a fixed program. It changes. The question the regulation poses is: can you show what it learned, when, and from which data?

The same sealing approach works here. Seal a manifest of each training data set when it is frozen, seal each model update when it is deployed, and seal the validation report that shows the machine still meets its safety requirements. That way, if something goes wrong a year later, you have a record that shows which version of the model was running and which data it learned from, unchanged since the day you documented it.

What to watch

The Machine Regulation applies from 20 January 2027 ^[1]. That leaves just over a year to update your processes.

In Sweden, the Work Environment Authority published new regulations in 2023 that align with the Machine Regulation ^[4]. They apply to machinery placed on the Swedish market from 20 January 2027, and they contain the same software traceability and corruption protection requirements.

If you make machinery with self-learning behaviour, expect notified bodies to ask detailed questions about your documentation. The regulation is clear that they must understand how the machine learns and how you keep it within its validated limits ^[3].