Security obligations for systems that act in the physical world. This is where a security requirement and a safety requirement have to be satisfied at the same time, by the same design.
What we track
EU Machinery Regulation
EU. Cybersecurity requirements for machinery, confirmed for January 2027, including software that affects safety functions.
Robot safety standards
International. ISO and IEC work aligning safety standards with security controls, including collaborative cells.
AI Act safety components
EU. High-risk classification where an AI system is a safety component of a machine.
Autonomous vehicle regimes
EU, UK and US. Approval and in-service requirements where a vehicle drives itself.
Industrial deployment guidance
All jurisdictions. Sector guidance for mobile robots and automated systems operating alongside people.
Incident and recall practice
All jurisdictions. What happens after a failure, who has to be told, and how quickly.
Who is in scope
Manufacturers and integrators of machinery, and the operators who deploy it. The Machinery Regulation reaches anyone placing machinery on the EU market, and an integrator who assembles a line from components can become the manufacturer of the resulting machine.
Operators are reached through workplace safety law, through NIS2 where the site is in scope, and increasingly through insurance conditions. A warehouse running autonomous mobile robots has obligations even though it built nothing.
Where the deadlines fall
Machinery cybersecurity requirements are confirmed for January 2027, which sounds distant and is not, because machinery design cycles run longer than that. Standards alignment work is arriving in parallel, and a harmonised standard is what most manufacturers will actually build against.
Autonomous vehicle regimes work on approval cycles instead, so the binding date attaches to your model programme.
Where organisations get caught
Safety and security pull in opposite directions. A safety case usually assumes a system fails into a known state, and a security control that stops the system can be the thing that creates the hazard. Standards bodies are only now aligning the two, and the engineering answer is often a redesign instead of an added control.
Ownership. A robot is bought by operations, integrated by a supplier and secured by nobody in particular, until someone asks who signed off the network it is on. The security team frequently learns about the deployment from an incident.
Re-certification. Changing software on a machine can invalidate its conformity assessment, which means a security patch has a safety consequence and a paperwork consequence. Organisations that patch first and ask later create a different problem from the one they solved.
Questions worth asking now
- Which machines on our sites run software we can update, and who is allowed to update it?
- Does patching any of them invalidate a conformity assessment or a safety case?
- Who integrated the line, and are they still contractually responsible for its security?
- What network are these systems on, and who approved that design?
- If a robot behaved unexpectedly, who would investigate, safety or security?
- Are any of our AI systems a safety component of a machine, in the AI Act sense?
Related domains
Cyber-kinetic and OT security covers the wider plant environment. Product security covers what you place on the market. AI governance covers AI as a safety component.