Cybersecurity, AI, and Software Under the New Machinery Regulation

Introduction

Machinery is now software-defined, connected, and increasingly autonomous. The Machinery Regulation (EU) 2023/1230 treats software failures as seriously as mechanical defects, requiring manufacturers to embed cybersecurity, software safety, and self-evolving system safety from the design phase, through validation and CE marking.

To allow remote monitoring, troubleshooting and productivity gains, machinery is increasingly being added to end-users computer networks. This network presence can potentially expose safety functions to malicious actors who may lack physical access to the machine but can disrupt its operation remotely. Ransomware, firmware injection, and denial-of-service attacks are no longer IT problems; they are now safety hazards that manufacturers must address during risk assessment.

Software that performs a safety function and is placed independently on the market is now explicitly a “safety component” (Article 3, Clause 3). As end-users know often from bitter experience, the wrong software update can introduce the similar level risks to a mechanical redesign.

Machine learning systems that adapt their behaviour based on operation present a fundamentally different risk profile. While popularised as ’embedded’ or ‘edge AI’, the Machinery Regulation uses the terminology of a self-evolving function, and only applies to safety related functions rather than general operation. A self-evolving safety function cannot be fully tested in advance; its behaviour depends on data it will have encountered during operation post-certification. The Machinery Regulation recognises this and requires independent third-party assessment for all safety-related machine learning systems (Annex I Part A.5-6), reflecting the opacity and autonomy that distinguishes them from traditional software.

Cybersecurity Requirements

Manufacturers must adopt “proportionate measures” to protect machinery against malicious third parties that could compromise safety (Introduction Clause 25). This is not optional IT compliance; it is a mandatory safety requirement detailed further in Annex III, Section 1.1.9 and 1.2.1.

Specifically, manufacturers must:

1. Identify safety-critical software and data and protect them against accidental or intentional corruption
2. Design hardware transmitting safety-critical signals to resist unauthorized access or tampering
3. Collect evidence of any legitimate or illegitimate intervention in safety-critical hardware and software

Certification under Cybersecurity Regulation (EU) 2019/881 demonstrates conformity with these requirements (Article 20, Clause 9).

Manufacturers without documented machinery cybersecurity face enforcement action when the authorities discover safety-critical systems lacking appropriate protection. If a cyber incident causes harm, an absence of intervention logging would prevent manufacturers from determining whether the machinery was compromised or operating as designed. Failure to protect safety-critical data can also create joint liability: non-compliant manufacturers share responsibility with the malicious actor for resulting injuries.

Safety-Related Software

The regulation distinguishes between software that is either self-evolving or not. Traditional software programmed only to execute automated functions remains subject to traditional design controls (Introduction Clause 55).

For all safety-related software, manufacturers must:

1. Include future software updates in their risk assessment at the time of placing the product on the market (Introduction Clause 32)
2. Document the source code or programming logic on reasonable request from competent authorities (Annex IV)
3. Enable traceability logging for five years after each software upload to demonstrate conformity (Annex III, Clause 1.2.1(f))

Failure to track software changes and maintain audit trails creates liability exposure and prevents manufacturers from demonstrating conformity if investigated. If an operator suffers harm from a hazard caused by an undocumented software update, the manufacturer has no documented evidence of where responsibility for the update lies.

Self-Evolving Systems and Machine Learning

Systems with fully or partially self-evolving safety functions trigger mandatory third-party (notified body) conformity assessment (Annex I). This applies whether the system is placed independently on the market or embedded within machinery.

Clause 54 of the introduction identifies why: data dependency, opacity, autonomy, and connectivity increase both probability and severity of harm.

Manufacturers must now:

1. Assess foreseeable evolution: Risk assessment must include hazards that might arise from intended evolution of autonomous behaviour during the machinery’s lifecycle (Annex III, Part B, Clause 1(e))
2. Ensure predictability: Control systems must not perform actions beyond defined task and movement space (Annex III, Clause 1.2.1(a))
3. Enable human oversight: Machinery with self-evolving behaviour must adapt its human-machine interface to operator characteristics and communicate its planned actions comprehensibly (Annex III, Clause 1.1.6(f-g))
4. Record safety decisions: Data logging on safety-related decision-making for machine learning systems is mandatory, retained for one year after collection (Annex III, Clause 1.2.1(b))

Autonomous systems that operate without predictability constraints or human oversight can cause injury before operators recognise a problem. A system that acts beyond its defined task space due to uncontrolled learning violates the essential safety requirement. Notified bodies will not certify self-evolving safety functions without demonstrable controls, and products placed on the market without proper third-party assessment face withdrawal and manufacturer liability.

Compliance Path

Manufacturers have until the regulation’s effective date to comply. The immediate steps are:

1. Audit machinery against the expanded definition of software components
2. Map safety-related software and identify which systems exhibit self-evolving behaviour
3. Conduct cybersecurity risk assessment; check eligibility for EU certification schemes
4. Engage notified bodies for self-evolving safety functions if applicable
5. Update technical files to include source code access procedures and traceability logging systems

Conclusion

The Machinery Regulation recognises that cyber vulnerabilities, software defects and rogue self-evolving systems are as much of a risk to compliance as mechanical failures. Compliance requires integrating cyber security, software safety, and safeguards for self-evolving systems into the machinery design process from the outset. Afterthought compliance is no longer viable.