EU Machinery Regulation: Five-Year Logs and *AI Safety Checks* from 2027

What changes on 20 January 2027

The EU Machinery Regulation comes into force on 20 January 2027, replacing the Machinery Directive that has been in place since the 1990s ^[1]. It covers anything from factory robots to lawnmowers, if it has moving parts and a power source.

The new regulation adds cybersecurity to the old mechanical and electrical safety rules. That means manufacturers now have to think about software versions, corruption and logs, not just whether a guard rail will stop someone losing a finger ^[1].

It's a bit like the difference between building a safe car and building a safe car that also updates its software over the air. The brakes still matter, but so does making sure nobody can mess with the code that controls them.

Five-year logs for safety changes

Annex III, section 1.1.9, says machinery must allow "the recording and tracing of changes to safety-relevant software" throughout its lifecycle ^[1]. Those records have to be kept for at least five years from when the machinery was placed on the market or, if longer, during the expected lifetime ^[1].

Safety-relevant means any software that affects whether the machinery meets the essential health and safety requirements in the regulation. A firmware update that changes how an emergency stop works counts. A cosmetic change to a display screen probably doesn't.

The wording is careful: the machinery must allow the recording and tracing. It doesn't prescribe a particular system, but it does mean manufacturers can't just wave their hands and say they don't keep records.

Protection against corruption

Section 1.1.9 also requires machinery to be protected against corruption ^[1]. Corruption here means unauthorised changes to software or data that could affect safety.

That includes updates pushed from outside, but it also includes someone with a USB stick and five minutes alone with the control panel. Access controls, signed updates and monitoring all help, though the regulation doesn't list a specific set of measures.

The test is whether the machinery can reasonably resist tampering that would compromise safety. A robot that could be reprogrammed by anyone with physical access wouldn't pass.

Self-learning systems

Machinery that continues to learn after it is placed on the market gets its own paragraph. Section 1.1.9 says such systems must have "measures to ensure that the machinery remains safe" throughout their learning phase ^[1].

That's vaguer than the logging rule, and it reflects the fact that nobody is quite sure how to make a self-learning lawnmower safe for all the things it might learn to do. The regulation asks for measures, plural, and leaves it to the manufacturer to say what those are and why they work.

Expect notified bodies to ask hard questions about this one.

What manufacturers must document

The regulation's documentation requirements are detailed. Manufacturers must keep a technical file with a description of the machinery, drawings, risk assessment, the standards or specifications applied, test reports and, where relevant, a copy of the instructions ^[2].

For software, that means documenting what the software does, which version is in which machine, how updates are delivered and how safety-relevant changes are recorded. It also means keeping those records for ten years after the last unit was made ^[2].

Conformity assessment depends on the category. Most machinery is self-certified by the manufacturer. Some categories, listed in Annex IV, require a notified body to check the technical file or the production process ^[2]. Self-learning machinery is more likely to end up in front of a notified body, even if it isn't explicitly listed.

What this means for you

If you make or sell machinery in the EU, here are the questions to ask now, eighteen months before the date:

• Which of your products contain safety-relevant software, and how do you define that?
• Can you show, for a machine delivered two years ago, which software version it was running and what changes have been made since?
• How do you protect machinery against unauthorised changes, both remote and physical?
• If your machinery learns, what stops it learning something unsafe, and how would you demonstrate that to a notified body?
• Where are those records kept, who can access them, and how long do you keep them?

The penalties for non-compliance follow national market surveillance rules, which vary, but they generally allow authorities to order recalls, stop sales and impose fines.

A checkable record of versions and changes

The regulation asks manufacturers to log safety-relevant software changes and keep those logs traceable for five years. The question it doesn't answer is how you show, three years later, that the log is the one written at the time and hasn't been edited since.

Here, sealing each change record as it happens gives you a checkable history. The thing to seal is the change entry: which version, when it was deployed, what it changed and who approved it. Sealing takes a fingerprint of that record, not the record itself, so the details stay in your own systems.

Anyone you share the record with later, a notified body, a customer or an investigator, can check the fingerprint and see that the entry is exactly what was logged on the day. Change one character in the log and the fingerprint won't match.

A digital witness doesn't replace version control or access restrictions. It's an extra layer that makes the history independently checkable, even by someone who doesn't trust your systems. That can matter when a machine has been in the field for four years and a safety question comes up.

You can seal release records and deployment events as part of your build pipeline, through the REST API, the SDK or the MCP server that works with AI development tools. The content stays with you. The first 2,000 witnesses a month are free, and the full details are in the documentation at WitniumChain.

It doesn't show that a version was safe or that the log is complete, but it does let you prove the log you're showing is the one you wrote, unchanged.

How it would work

1. At each software deployment, your system calculates a fingerprint of the change record (version, date, approver) and seals it.
2. The sealed fingerprint is stored alongside the record, with a witness ID.
3. Three years later, when a notified body or a customer asks for the change history, you share the records and the witness IDs, and they check the fingerprints.

What to watch

The Machinery Regulation applies from 20 January 2027. Machinery placed on the market before that date can still be sold under the old Machinery Directive until 20 January 2029, as long as it was already on the market ^[1].

If your machinery contains AI that counts as high-risk under the AI Act, you will also need to meet the AI Act's requirements, including the logging duty in Article 12, which applies to Annex III high-risk systems from 2 December 2027 ^[3]. The two regulations overlap but are separate: machinery can be in scope of one, both or neither.

Guidance from the Commission and from industry bodies is still being written. Watch for updates on what counts as safety-relevant software and what protection against corruption looks like in practice.