Machinery Regulation 2027: safety logs must be traceable for *five years*

Five years is a long time

If you make machines, imagine someone asking you in 2032 which software version a particular machine was running in early 2028, and whether anyone changed the safety logic in between. That is what the new Machinery Regulation is quietly asking for.

From 20 January 2027, machines placed on the market must log safety-relevant software changes and keep those logs traceable for five years ^[1]. The regulation also says machines must be protected against corruption, and if a machine learns as it runs, you need to document how that learning could affect safety ^[1].

It is a big shift from the Machinery Directive it replaces, and it matters to anyone who builds, sells or maintains machines with software on board.

What counts as a machine

The regulation defines a machine as an assembly with at least one moving part, driven by something other than direct human or animal effort, and intended for a specific application ^[1]. That includes industrial robots, lifts, conveyors and automated guided vehicles. Partly completed machinery counts too, as do safety components sold separately ^[1].

If the machine has software that affects safety—which most do—the new logging and traceability rules apply.

The five-year log

Here is the requirement, in plain terms. Safety-relevant software changes must be logged, and those logs must be traceable for five years from when the machine is placed on the market ^[1].

That is not the same as keeping the logs safe in a cupboard. Traceable means you can show what changed, when it changed and, by implication, that the record itself has not been quietly edited since. It also means the logs have to survive longer than the warranty period, longer than the average maintenance contract and, in many cases, longer than the people who wrote the original code stay in the same job.

The regulation does not say how to make logs traceable, just that they must be. Access controls and timestamped backups are the foundation. A sealed fingerprint of each log segment is one step further, because a change shows up even if it is made by someone with administrator rights.

Protection against corruption

Machines must also be designed and constructed so that software, including safety-related software, is protected against corruption ^[1]. Corruption here means unauthorised changes: someone tampering with the code, a badly written update overwriting something important, or malware slipping in through a maintenance interface.

The requirement applies to the software as it sits on the machine, not just to the development process. If a machine can receive updates over a network, or if maintenance staff plug in a laptop, you need to think about how to keep the wrong changes out and how to show, if asked, that the software running on the machine is the software that is supposed to be there.

Machines that learn

If your machine has self-learning behaviour—software that changes how the machine operates based on what it encounters—there are additional rules ^[1]. You must document how the learning could affect the machine's safety functions, set limits on what the machine is allowed to learn and make sure the machine stays within its intended use even as it adapts.

Learning here does not just mean advanced AI. A system that adjusts conveyor speeds based on load patterns, or tunes motor torque over time, can count as self-learning if the adjustments affect safety.

The regulation says nothing about logging the learning itself, but if a machine's behaviour changes in a way that matters to safety, the five-year traceability rule starts to look relevant.

Technical files and software versions

Manufacturers must keep technical files for ten years after the last unit of a model is placed on the market ^[1]. The file has to include a description of the machine, drawings, risk assessments, test results and instructions, and it must show which version of the software was present at the time of manufacture ^[1].

That version number needs to tie back to something checkable. If a notified body, a market surveillance authority or an insurer later asks which build was on a particular machine, the technical file has to give a clear answer.

How a digital witness fits

The thing to seal here is each software release as it is built and each deployment event when a release is loaded onto a machine: the build fingerprint, the release notes and the test results at release, and the machine serial number, software version and timestamp at deployment.

Sealing takes a fingerprint of the record, not the record itself, so the data stays on your systems. Anyone you share it with—a notified body, a surveillance authority, an insurer—can later check that the version record is exactly what it was at the time of manufacture, unchanged even by someone inside the organisation.

What it shows is that a release and its deployment record existed at that time and have not changed since. What it does not show is that the version was free of defects, or that it was the right version for the job.

Your build pipeline already versions the code. WitniumChain gives you a way to show the version record itself has not been rewritten. That gap becomes visible when someone outside your organisation needs to trust the record.

How it would work

1. At build time, your CI/CD pipeline calculates a fingerprint of the release package and seals it with the release notes and test summary.
2. At deployment, when the software is loaded onto a machine, you log the machine serial number, software version and timestamp, and seal that too.
3. Five years later, if someone asks which version a machine was running, you produce the sealed deployment record and they can check it has not changed.

What this means for you

If you manufacture machines with software on board, here are the questions to ask now, before 20 January 2027:

• Which software changes count as safety-relevant in your machines, and are those changes being logged?
• Can you show, five years from now, which software version a particular machine was running at manufacture and which changes were made to it since?
• How are your machines protected against unauthorised software changes, during manufacture, deployment and maintenance?
• If a machine has self-learning behaviour, have you documented the limits on what it is allowed to learn and how that learning affects safety?
• Do your technical files include the software version present at manufacture, in a way that ties back to a verifiable build?

The regulation is clear on the outcome it wants. The method is up to you.

What to watch

The Machinery Regulation applies from 20 January 2027 ^[1]. Machines already on the market under the Machinery Directive do not have to comply, but any machine placed on the market from that date does.

If your machines are also subject to the AI Act, the Cyber Resilience Act or sector rules like the Medical Device Regulation, the requirements stack. A robot used in surgery, for example, falls under all three, and the logging and traceability duties do not cancel each other out.

National market surveillance authorities will enforce the regulation, with penalties set by each member state ^[1]. How strictly they enforce the five-year log requirement will become clear over the next few years, but the rule itself is unambiguous.