A connected machine will receive software updates for years after it leaves the factory. Each update can fix a vulnerability, add a feature or change a safety function, sometimes all three. The Machinery Regulation does not forbid updates. It asks that you can tell what is installed, that changes leave evidence, and that an update never creates a hazard.
What the regulation asks
| Provision | What it means for updates |
|---|---|
| 1.1.9, para 4 | The machine identifies the software it needs to operate safely and shows it at all times in an easily accessible form |
| 1.1.9, para 3 | That software is identified as compliance-critical and protected against accidental or intentional corruption |
| 1.1.9, para 1 | A remote device, such as an update service, must not lead to a hazardous situation |
| 1.2.1(f) | Versions of safety software uploaded after sale are part of the tracing log, kept for five years after each upload |
| Art. 3(16), Art. 18 | A change the manufacturer did not foresee that creates a hazard and needs new protective measures is a substantial modification; whoever makes it becomes the manufacturer |
Make the identity readable
Give each software item that matters for safety a unique identifier and version, and let the machine show them on its own display or terminal. The operator, a service technician and an inspector should all reach the same screen without a dealer tool. Keep the list in your technical documentation and update it with every release.
Activate only when it is safe
Downloading an update and activating it are two different steps. Download can happen in the background. Activation should follow rules you can test:
- The image is signed and the signature is verified in the unit that runs it, before activation.
- The machine is in a safe state: at standstill, outputs off, no function in progress.
- The operator confirms on the machine, so nothing changes while someone stands next to it unaware.
- If activation fails, the machine keeps the previous valid image or stays in a safe idle state.
- The upload, its version and its result go into the tracing log.
Treat a security fix as a safety change
A patch that closes a vulnerability still runs on a controller that performs safety functions. Run your regression tests for the safety functions before release, record the result, and keep it with the release record. If a change was not foreseen in your update procedure and affects safety in the way Article 3(16) describes, assess it as a possible substantial modification before you ship it.
Where the CRA pulls the other way
From 11 December 2027 the Cyber Resilience Act applies in full. Its Annex I asks that vulnerabilities can be addressed through security updates, with automatic updates enabled by default where applicable and a way for users to opt out. That fits the Machinery Regulation if you keep download and activation apart: automatic download with an opt-out, activation only in a safe state with the operator's confirmation. Write that position down once and refer to it in both files.
Keys outlive algorithms
A machine may stay in service for 15 years or more. Keep at least two verification key slots, support signed key updates and revocation, and keep the private signing key off the product, in a hardware security module, with two people required for each signature.
Tell the user
The instructions for use must cover how updates reach the machine, what the operator has to do and what happens if an update fails (Annex III, 1.7.4.2; Art. 10(7) allows digital instructions). From December 2027 the CRA adds its own list, including the support period and how to turn automatic updates off.
This article explains Regulation (EU) 2023/1230 in plain words. It is not legal advice.