The EU Machinery Regulation now asks for a *software audit trail*

What changes on 20 January 2027

Machinery safety law has long asked what a machine can do to people around it. From 20 January 2027, it also asks what the software does to the machine.

Regulation (EU) 2023/1230 on machinery products replaces the old Machinery Directive and brings software to the centre of the conformity assessment ^[1]. A machine with safety-relevant software now needs to keep track of changes to that software, in a way someone can follow five years later.

Think of it like this: if your car's service book listed every brake pad change, you would want the entries to stay the same from year to year. The new regulation asks for something similar, but for the software that keeps a machine safe.

The software requirements in Annex III

Annex III sets out essential health and safety requirements ^[1]. Among them, section 1.1.9 says machinery must be designed and constructed to be protected against corruption, particularly when it comes from outside or from the operating system ^[1].

Section 1.7.4.2 goes further. Where software is relevant to safety, the manufacturer must document the software specification, including a description of the method used to verify that the software functions as intended ^[1]. That is the foundation.

The traceable part comes next. The regulation says safety-relevant software changes shall be identified, logged and traceable ^[1].

Logs must be kept for at least five years from the date of the last change ^[1].

Self-learning machinery

Machinery that learns while it runs gets a section of its own. Section 1.1.10 in Annex III says machinery with a self-learning function that can affect safety, either directly or because it changes the behaviour of a safety function, must have mechanisms that allow the manufacturer or the user to control the learning process, monitor it and limit the behaviour ^[1].

The idea is to stop a safety function drifting into something unsafe over time.

IEC 62443 and the Cyber Resilience Act

The regulation does not tell you exactly how to protect the software or structure the logs. It sets the goal and leaves the method open.

IEC 62443 is a widely recognised standard for industrial automation and control systems security ^[2]. It covers zones, conduits, access control and, yes, logging and monitoring ^[2]. Notified bodies often look for it when they assess compliance with cybersecurity requirements.

The Cyber Resilience Act (CRA) applies separately to products with digital elements, including machinery software ^[3]. From 11 December 2027, the CRA requires products to log and monitor security-relevant events ^[3]. Where a machine falls under both regimes, the logs need to serve both purposes.

The timelines are tight. Machinery Regulation from 20 January 2027, CRA product requirements from 11 December 2027. Manufacturers are already building the logging into new designs now.

What this means for you

If you build or place machinery on the market, here are the questions to ask:

• Which parts of your software are safety-relevant, and how do you define that boundary?
• How do you log changes to that software, and who decides what counts as a change worth logging?
• Where do the logs live, and how do you keep them traceable and readable for five years?
• If the machinery learns, how do you monitor that learning process and show that you have done so?
• Does the logging setup also meet the CRA's requirements, or will you end up with two parallel systems?

A technical file that cannot show the software history will struggle at conformity assessment.

A digital witness for the audit trail

Here, the thing to seal is each safety-relevant software change as it is logged: the version identifier, the date, what changed and who authorised it.

Sealing takes a fingerprint of the log record, not the record itself, so the data never leaves your systems. The fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back. When a notified body or a market surveillance authority asks to see the audit trail, anyone you share the log with can calculate the fingerprint again and check it against the sealed one.

What it shows: that the log record is exactly what was written at that time, unchanged since, even by someone with administrator rights.

What it doesn't show: it doesn't prove the change was safe, authorised or implemented correctly, and it doesn't replace the technical documentation or the conformity assessment itself.

Your system sends the fingerprint as each change is logged. The content stays with you. To check, recalculate the fingerprint and compare it with the sealed one. The first 2,000 witnesses a month are free. Read the docs at witniumchain.com/docs.

How it would work

1. Each time a safety-relevant software change is logged, your system sends a fingerprint of that log entry to WitniumChain and gets a witness ID.
2. The log and the witness IDs are kept together, readable for at least five years.
3. When someone asks to see the audit trail, you share the log and the witness IDs. They recalculate the fingerprint and check that nothing has changed.

What to watch

• 20 January 2027: Machinery Regulation (EU) 2023/1230 applies to machinery placed on the market from that date ^[1].
• 11 December 2027: CRA product requirements, including logging of security-relevant events, apply ^[3].
• IEC 62443 updates: as the standard evolves, notified bodies update their expectations for cybersecurity conformity.

The regulation is here. The question is whether your audit trail will hold up when someone checks it in 2032.