Machinery Regulation: safety-relevant software must be logged for five years from 20 January 2027

A recording duty for safety software

From 20 January 2027, the Machinery Regulation requires manufacturers to keep a record of safety-relevant software changes, traceable for at least five years. Think of it as a flight recorder for machinery: when something goes wrong, the question isn't just what the machine did, but which version of the software was running at the time.

The regulation doesn't define exactly what counts as safety-relevant, so manufacturers will have to decide that themselves and document the reasoning. What's clear is that a change which could affect whether a machine complies with safety requirements falls within scope. That includes updates to control logic, sensor calibration and fault-handling routines.

The five-year period starts when the machinery is placed on the market. ^[1] A log stored in a format that the manufacturer can quietly edit is easier to question later. The rule says what to record, not how to protect the recording.

Protection against corruption

Machinery must be protected against corruption that could lead to a dangerous situation. ^[1] The requirement covers both accidental and deliberate interference, from malware to an update gone wrong.

The word corruption is broad. It includes unauthorised changes to software, but also anything that degrades the machine's ability to operate safely. That means backups, access controls and monitoring are part of the picture, not just cybersecurity in the narrow sense.

For machinery that updates itself over a network, the update process is part of what needs protecting. A compromised update could turn a compliant machine into a hazard.

Self-learning machinery

If a machine changes its behaviour through machine learning and those changes could affect safety, additional requirements apply. ^[1] The manufacturer must ensure the machine can be returned to a previous safe state, and that the learning process itself doesn't introduce risks.

This is where traceability gets harder. A model that learns in the field doesn't have discrete versions in the way a manually updated firmware does. The regulation asks for the ability to revert, which suggests keeping something like snapshots of the model's state at intervals, alongside records of what the machine learned and when.

The exact mechanism is left to the manufacturer, but the principle is clear: you can't let a machine learn itself into a dangerous state with no way back.

What this means for you

If you make machinery that will be placed on the market from 20 January 2027, now is the time to ask:

• Which software changes in your machines are safety-relevant, and how will you document that decision?
• How will you log those changes in a way that stays traceable for five years?
• What protects your machinery against corruption, and does that protection cover the update process?
• If your machinery learns, how will you keep snapshots of its state and ensure you can revert to a safe one?

The regulation applies to new machinery, not to machines already on the market under the old directive. ^[1]

Seal the log as it's written

Here, the thing to seal is each safety-relevant software change as it's written to the log: the version identifier, the change description, the timestamp and who approved it. Say a robot injures someone and a notified body asks which software version was running on the day. You produce the log, and the question is whether anyone has edited it since.

Sealing takes a fingerprint of each log entry, not the entry itself, so the record never leaves your systems. WitniumChain gives you a witness ID for each one. Five years later, anyone you share the log with can calculate the fingerprint again and check that it matches the sealed one. Change a single character and it won't match.

It doesn't show that the software was free of defects or that the machine was safe. It shows that the log is the one written at the time, unchanged since.

You can seal releases and deployments as part of your build pipeline, through the REST API, the SDK or the MCP server. The first 2,000 witnesses a month are free.

How it would work

1. At each safety-relevant software change, your system writes the log entry and sends a fingerprint to WitniumChain.
2. You get a witness ID back and store it with the entry.
3. When the log is questioned, you share the entry and the witness ID. The recipient checks the fingerprint against the sealed one.

What to watch

20 January 2027 is the application date for the Machinery Regulation. If you're developing machinery now, the requirements are already relevant to your design and documentation.

National market surveillance authorities will enforce the regulation, with penalties set by each member state. ^[1]