The situation

The CE marking manager of a machine builder has done risk assessments according to ISO 12100 for twenty years. Guards, emergency stops, performance levels. The technical file is in good order.

Then the new Machinery Regulation arrives. Two points of Annex III speak of software, remote devices and malicious third parties. Nobody in the technical office has ever done cybersecurity, and the software that produces the technical file has no chapter for it.

What the two points ask

Point 1.1.9, Protection against corruption

In plain words:

  • Connecting another device to the machine, directly or through a remote system, must not lead to a hazardous situation.
  • Hardware that transmits signals or data relevant for safety must be protected against accidental or intentional corruption.
  • Software and data that are critical for compliance with the safety requirements must be identified and protected against corruption.
  • The machine must identify the installed software that is necessary for it to operate safely, and be able to give that information at any time in an accessible form.
  • The machine must collect evidence of a legitimate or illegitimate intervention in that software, or of a modification of the software or its configuration.

Point 1.2.1, Safety and reliability of control systems

Control systems must withstand intended and unintended external influences, including reasonably foreseeable malicious attempts from third parties that lead to a hazardous situation. A tracing log of interventions and of the versions of safety software uploaded after the machine is placed on the market must be enabled for five years.

Why this is different from what you did before

These are functions of the machine, not pages of a document. A machine that cannot tell which safety software version it runs, or that keeps no record of who changed it, does not meet the text, however good the technical file is.

They are also never finished. A guard that was safe in 2027 is safe in 2032. A piece of software that had no known vulnerability in 2027 will have several by 2032.

The steps to prepare

1. Find the safety-relevant software

List the software and data that the safety functions depend on: safety PLC program, drive parameters, HMI functions that change safety settings. Give each a version.

2. Control who can connect

Every path into the machine is a possible source of corruption: the plant network, the service laptop, the remote access gateway, the USB port. Decide which paths exist in which operating state, and close the rest.

3. Record interventions

Log who connected, when, in which state and which software or configuration changed. Keep the log for five years at least.

4. Watch for new vulnerabilities

A new vulnerability in a component can turn an acceptable risk into an unacceptable one. You need a process that tells you when this happens, per delivered machine.

5. Do not wait for the standards

The harmonised standards will describe how to show conformity. They will not change what the regulation asks. The five steps above are valid in any case.

How our products help

Edge Shield covers the network side. It allows only the declared flows for each operating state, inspects them and records profile changes and blocked attempts. It addresses who can connect to the machine. It does not replace the identification of software inside your PLC.

Shield Lifecycle keeps the component list of each delivered machine and checks new vulnerabilities against it every day. It tells you when the security side of your risk assessment needs a new look.

Neither product replaces your risk assessment, your technical file or your declaration of conformity. They give you the functions and the evidence for the part that your current tools do not cover.