Cybersecurity & Software in Machinery Risk Assessments: What's covered

For most engineering teams, "cybersecurity" has lived with IT, and "machine safety" has lived with engineering and compliance. Machinery Regulation (EU) 2023/1230 puts the two in the same document.

From 20 January 2027, machinery placed on the EU market must show that safety functions, software and data are protected against corruption, and that the risk assessment has considered it. If your risk assessments still stop at mechanical and electrical hazards, they will need updating before you can sign a Declaration of Conformity under the Regulation.

At IES, we've supported CE and UKCA compliance for high-technology equipment since 1991. This article sets out what the Regulation now expects and what a risk assessment needs to cover to keep pace.

Key Takeaways: Cybersecurity and Software in Machinery Risk Assessments

● Cybersecurity is now treated as a machine safety issue, not just an IT one.

● The key requirements sit in Annex III of the Regulation, sections 1.1.9 (protection against corruption) and 1.2.1 (safety and reliability of control systems).

● Risk assessments must account for cyber risk as well as mechanical and electrical hazards.

● Machines must be able to evidence interventions in safety-related software, and safety software must be identifiable.

● Existing machinery isn't re-certified automatically, but software changes that affect safety can trigger new obligations.

Why Has Cybersecurity Become a Machine Safety Requirement?

Modern machinery is connected. Controllers sit on networks, vendors dial in for remote diagnostics, firmware is updated over the air, and safety functions increasingly depend on software. A safety function that can be altered, disabled or corrupted, whether accidentally or deliberately, is a hazard in its own right.

The Regulation reflects that. It doesn't ask you to solve every IT security problem. It focuses on one question: can a fault, a connection or an attack stop a safety function from working when it's needed?

What Does the Regulation Actually Require?

Two clauses in Annex III do most of the work.

Protection against corruption (1.1.9). In broad terms:

● Connecting another device, locally or remotely, must not lead to a hazardous situation.

● Hardware components that transmit signals or data and can access safety-critical software must be protected against accidental and intentional corruption.

● Safety-related software and data must be identified, and installed safety-related software must be identifiable at all times.

● The machine must collect evidence of interventions, whether legitimate or not, in safety-related hardware and software.

Safety and reliability of control systems (1.2.1). Control systems must be designed to withstand intended operating stresses and external influences, including reasonably foreseeable malicious attempts by third parties that could lead to a hazardous situation. This is where safety and cybersecurity are explicitly linked.

The Regulation also expects a tracing log for interventions and for versions of safety software uploaded after the machine is placed on the market or put into service. Sources describe a minimum retention period of five years after an upload, so check the exact wording in the Regulation for your machine.

What Does Your Risk Assessment Now Need to Cover?

Here is a practical way to extend an existing risk assessment. It isn't a substitute for the Regulation's text, but it covers the ground teams most often miss.

1. Identify safety-related software, data and hardware. Start with an inventory: which controllers, safety PLCs, drives, sensors and HMIs carry safety functions, and which software, firmware, parameters and configuration data they depend on. You can't protect, log or version-control what you haven't identified.

2. Map every connection and access route. List every way something can reach those components: networks, wireless links, USB and service ports, remote access by the OEM or a supplier, and data links to other machines or factory systems. Include connections that only exist during maintenance.

3. Treat foreseeable malicious attempts as a cause of hazard. For each safety function, ask what happens if it is bypassed, altered, delayed or disabled through one of the routes you mapped. The Regulation's wording is "reasonably foreseeable", so the test is realistic threats, not theoretical ones.

4. Define protective measures and confirm they stay effective. Record how each safety function is protected, for example through access control, segregation, integrity checks, tamper resistance or restricted service modes, and consider what happens after updates, repairs and reconfiguration.

5. Provide evidence of interventions. Decide how the machine will record changes to safety-related software and configuration, who can access those records, and how they'll be read. Where digital logging isn't reasonably possible, think about physical evidence of tampering.

6. Control software updates and changes. Safety-related software supplied separately after a machine has been sold can itself count as a placing on the market. A software or firmware change that introduces a new hazard or increases a risk can amount to a substantial modification, making whoever made the change responsible as the manufacturer. Put change control in place before updates are made, not after.

7. Reflect it in the technical file and instructions. The risk assessment, protective measures, logging approach and identification of safety software should all appear in the technical file, and users need clear instructions on how to operate and maintain the machine securely. We cover the wider documentation steps in

How to Update Your Declaration of Conformity for Regulation 2023/1230. 

What About AI and Self-Evolving Behaviour?

If any safety function uses machine learning or self-evolving behaviour, additional requirements apply, and the conformity route can change. In some cases a notified body must be involved. Confirm this early, as it affects both timeline and evidence.

Does This Apply to Machines Already in Use?

Not retrospectively. Machinery placed on the market before 20 January 2027 stays under the Directive and does not need to be re-certified. But three points still matter:

1. Modifications and updates. Changes to software or control systems that affect safety can bring a machine into the Regulation's scope for the person making the change.
2. Second-hand imports. A used machine imported into the EU from outside it is treated as new to the market, so its software and connectivity will be assessed against the Regulation.
3. Duty of care. Regardless of which regime applies, you're still responsible for safe operation of equipment in use, and a machine with an uncontrolled remote access route is a risk whichever law it was built under.

Who Should Own This?

The most common failure we see in compliance work is a gap between teams. Safety engineers understand hazards but not always network architecture, and IT teams understand security but not always safety functions. The Regulation's requirements only work if both sit at the table, so agree early who owns the risk assessment, who owns the connections and who signs off changes.

Standards and Support

Harmonised standards give a route to demonstrating conformity, but the picture for corruption protection is still developing. A draft standard, prEN 50742, has been published to address Annex III 1.1.9 and 1.2.1, and general industrial cybersecurity frameworks such as IEC 62443 are widely used for wider security management. Check the current status of any standard before you rely on it, and note that following one doesn't automatically demonstrate conformity unless it's harmonised and covers the relevant requirements.

What About Great Britain and Northern Ireland?

The Regulation applies directly in Northern Ireland from 20 January 2027. In Great Britain, the UK Government has confirmed it will continue to recognise CE marking, and that machinery CE-marked to the new Regulation can still be placed on the GB market without separate UKCA certification. For manufacturers selling in both markets, a single well-documented approach to software and cybersecurity risk will do a lot of the work.

Why This Can't Wait

If the risk assessment doesn't cover software and cybersecurity, the technical file is incomplete, and if the technical file is incomplete, you can't make a defensible Declaration of Conformity. That puts shipments, commissioning and revenue at risk from 20 January 2027, with penalties set by individual Member States.

Industry guidance suggests compliance programmes for complex machinery can take 12 to 24 months, and the deadline is fixed. Cybersecurity is often the hardest area to assess late, because it involves people and systems outside the engineering team. The practical priority is to find the gaps first.

Download the Checklist: Is Your Declaration of Conformity Ready for 2027?

Our short, practical checklist covers the risk assessment, technical file and declaration steps, including the software and cybersecurity points above, so you can see at a glance where your documentation needs work.

Once you've downloaded it, our team will follow up to offer a free 20-minute consultation to talk through your results. Book your free consultation here.

See our full guide to the Machinery Regulation changes for the complete picture. Machinery Regulation (EU) 2023/1230: A Practical Guide For Manufacturers.

With over 35 years of hands-on engineering experience, IES tests, documents and certifies complex equipment start to finish, so you don't have to coordinate multiple suppliers.

This is a general guide, not legal advice. The right approach for your equipment depends on its design, connectivity and destination market.