If you build robots, agricultural equipment, construction machinery or other off-highway machines for the European market, EN 50742 introduces a new requirement worth understanding: your machine must keep evidence of changes to its safety software and settings.
That includes legitimate changes, like a dealer updating a controller, and unauthorized ones, like someone connecting a laptop and changing a safety parameter without permission.
This is an important distinction from the way many manufacturers handle software updates today. It's not enough to maintain a record of updates performed through your own processes. The machine itself must collect evidence of interventions throughout its life.
For teams familiar with automotive cybersecurity, much of the groundwork will look familiar. UN R155 and R156 established many of the practices around software identification, update management and cybersecurity monitoring. EN 50742 brings those ideas into machinery, with a particular emphasis on recording what happens to each individual machine.
What is EN 50742?
EN 50742, Safety of machinery - Protection against corruption, is the European standard developed to address the machinery tamper-protection requirements in the EU Machinery Regulation.
It received final approval in October 2026 and is scheduled for publication on November 19, 2026.
The Machinery Regulation already requires machines to:
- Identify their safety-related software and provide that information when requested.
- Protect safety software and safety-related data against corruption.
- Collect evidence of legitimate and illegitimate interventions in software and configuration.
- Maintain a tracing log of those interventions and of safety software versions uploaded after the machine is placed on the market.
That log must be retained for five years and be available to demonstrate conformity when requested by a national authority.
EN 50742 provides a framework for implementing these requirements. It starts with the machine's existing risk assessment, adds a threat assessment and establishes what protections and evidence are appropriate.
The machine has to keep its own evidence
Most engineering organizations already track firmware releases, approve service updates and document changes made by their own teams. Those records don't necessarily tell you what happened to an individual machine in the field.
Consider a dealer connecting a laptop and flashing a controller. The update might be perfectly legitimate, but unless the machine records the intervention, the manufacturer may have no reliable way to establish when it happened or what software was installed.
An unauthorized person making the same change presents an even bigger problem.
A firmware flash that the controller accepts can look like normal operation afterward. Without something counting or recording the intervention, an investigator may have little evidence to work with.
EN 50742 requires the machine to record interventions itself, rather than relying solely on the manufacturer's update history.
That means accounting for every relevant way someone can change safety-related software and configuration: service tools, over-the-air updates, operator displays and dealer equipment.
The evidence must be available for retrieval when requested.
What exactly needs to be recorded?
The standard identifies the types of changes that matter for safety.
Not every software or configuration change needs an entry. The focus is on changes that can affect safety.
You also don't need to preserve every previous software binary. The requirement is to maintain evidence of the intervention and identify the relevant software, not archive every firmware image ever installed.
Each record needs information that establishes the sequence of events. This can include timestamps, boot counts or running counters.
The records must be protected against tampering, and deletion must follow an authorized procedure. At least the latest change of each relevant type must be retained.
The log can live in the controller, another machine component or an external storage system. The manufacturer must document its read-out format so the information can be retrieved and understood.
Where maintaining a digital record isn't practical, a physical seal is an acceptable alternative.
How much security does your machine need?
EN 50742 starts with the machine's normal risk assessment under ISO 12100 and adds a threat assessment. The result is a security level assigned to each safety function.
Manufacturers have two equally valid ways to approach this:
- Use the security requirements provided by EN 50742.
- Use IEC 62443 if the organization already works within that framework.
The security level determines the additional protection a particular safety function needs. At the lowest level, an isolated system may not need additional security measures beyond the baseline requirements.
Higher levels introduce stronger protections based on the threats identified. These can include:
- Stronger authentication and authorization.
- Software and boot integrity checks.
- Message integrity protection.
- Input validation.
- Tamper detection.
One important detail: software identification and intervention logging apply at every security level. They aren't optional features reserved for machines with more demanding security requirements.
What automotive manufacturers can teach us
For teams with automotive experience, EN 50742 has familiar foundations.
UN R155 and R156 already require manufacturers to address vehicle cybersecurity and software update management. Under R156, approval-relevant software identification can be read through the vehicle's OBD port and must be protected against unauthorized changes. Manufacturers also maintain auditable records of their own software updates.
R155 recognizes the manipulation or deletion of event logs as a cybersecurity threat.
But there's an important difference between that model and what EN 50742 asks of machinery.
The biggest difference is who owns the evidence.
In the automotive model, the manufacturer's update register primarily documents updates made through its own processes. Under EN 50742, the machine must account for changes made by anyone with access to it.
That includes a dealer's laptop, a third-party service tool or an unauthorized connection. Manufacturers can't assume their central software management system knows everything that happened to every machine in the field.
What we've learned from monitoring machines in the field
We've spent considerable time monitoring off-highway and agricultural equipment across Europe. Our starting point was a few hundred log sources generating thousands of gigabytes of data every day. Almost all of it was created for operating and troubleshooting machines, not for cybersecurity.
As Dakota Waters, who runs our Vehicle Security Operations Center, puts it:
"There's also a lot of security data that just never breaches the surface and never makes it to being ingested by a SOC."
The data you need may already exist somewhere in the machine, but that doesn't mean it's being collected, retained or made available in a useful way.
We've written about this in Continuous Monitoring Isn't 24/7. Monitoring is an engineering job built around data someone chose to create. You have to understand how the system should behave, identify which signals matter and work with real logs to test those assumptions.
We still start every monitoring build with a model of expected system behavior, then let real-world logs revise it.
As Dakota says:
"The theory never survives first contact."
The same lesson applies to intervention logging. It's easy to draw a box labeled "security log" on an architecture diagram. It's harder to establish that every relevant change generates a record, that the record survives a reboot and that someone can interpret it months later.
Machinery also has safety signals that don't necessarily have an automotive equivalent.
A tractor might refuse to start unless its armrest is down. A central tire inflation system might send commands to inflate or deflate tires depending on operating conditions. Changing a setting that affects an interlock like the armrest belongs in the machine's own evidence trail.
Settings like these are part of what makes the machine safe to operate, so they need the same record as a firmware update.
Design the evidence in, rather than reconstructing it later
For a new machine, EN 50742's evidence requirements provide a useful starting point. Instead of digging through existing logs years later to figure out what happened, the controller team can deliberately produce the required records.
Start with the machine's as-shipped software as the first entry. Then make sure each subsequent intervention produces an identifiable record.
Think through the actual implementation:
- Which interfaces can change safety software or configuration?
- Does each interface generate an entry?
- Can the machine establish the order of changes if its clock is reset?
- Does the record survive a power loss, firmware reflash or controller replacement?
- Can an authorized person retrieve and interpret the evidence?
Counters and boot counts are particularly useful. A timestamp helps, but it isn't always reliable. If someone resets the clock, a running counter can still establish that a change occurred between two known machine states.
Controller replacement deserves particular attention. If a dealer replaces a controller, what happens to the old controller's intervention history? If a service tool changes a safety parameter, does that automatically generate a record, or does someone have to remember to document it?
These are much easier questions to answer during design than after machines are already in the field.
An EN 50742 design-review checklist
We'd start with five questions:
1. Have we identified every path that can change safety-related software or settings?
Include service tools, over-the-air updates, display menus, dealer laptops and other interfaces. Each relevant path should produce an entry in the machine's evidence trail.
2. Where do the log and its counters live?
Establish whether they survive power loss, firmware reflash and controller replacement. Document how records are protected against tampering and how authorized deletion works.
3. Can we establish the sequence of events?
Use timestamps, boot counts or running counters so an investigator can establish when an intervention happened relative to other known events.
4. Can someone outside the engineering team read the evidence?
Document the read-out format and retrieval procedure now. A national authority may eventually ask for the log, and the manufacturer needs to be able to explain what it contains.
5. Where would a physical seal make more sense?
Identify places where maintaining a digital record isn't practical and consider whether a seal provides an appropriate alternative.
One other consideration: the same machine is very likely covered by the EU Cyber Resilience Act (CRA). Its vulnerability-reporting requirements apply from September 11, 2026. We've covered what that means for manufacturers in our guide to CRA reporting.
Start with the machine, not the log file
For manufacturers already working with UN R155 and R156, there's a useful head start in threat analysis, software identification and security monitoring. But the intervention-recording requirement deserves specific attention.
We've learned through our fleet-monitoring work that useful security evidence doesn't appear automatically just because a machine produces lots of data. Someone has to decide what matters, make sure it's captured and ensure it can be understood later.
We haven't delivered Machinery Regulation conformity work for a client. Our perspective comes from years of automotive R155/R156 work, threat analysis and building monitoring systems for machines operating in the field.
If you're working through EN 50742, send us your intervention list or logging design. We'd be happy to walk through it with you while the solutions are still engineering decisions.
Subject expert
Dustin Mills is Director of Product Cybersecurity Engineering & Operations at Block Harbor, where he leads end-to-end engagements with OEMs and suppliers that secure connected vehicles across their lifecycle. He's at his best when working on ambiguous problems that span multiple teams.
%201.svg){kind=logo}
