CRA Compliance Checklist: Industrial Robotics & Collaborative Robots
Annex III Class I — industrial robots and collaborative robots in manufacturing environments are important products with safety-critical digital elements; Class II if integrated into critical infrastructure control
Industrial robots and collaborative robots (cobots) are safety-critical connected systems deployed in manufacturing, logistics, and process automation. Their CRA classification depends on deployment context — standalone industrial robots are Annex III Class I, while those integrated into critical infrastructure control systems may be Class II. Safety and security are inseparable in robotics: a cyber attack that disables safety interlocks can cause physical harm.
1. Scope & Classification
Determine whether industrial robots in your product line qualify as Annex III Class I as industrial control or safety-critical systems
Industrial robots with network connectivity and software-defined safety functions are likely Annex III Class I. Review the Annex III criteria against each product line.
Assess whether robots integrated into SCADA or critical manufacturing infrastructure require Class II classification
Robots forming part of critical infrastructure control (energy, water, automotive assembly for national supply chains) may be Class II, requiring third-party conformity assessment.
Assess the intersection with the EU Machinery Regulation (2023/1230) — CRA cybersecurity and Machinery Regulation safety requirements must both be satisfied
The Machinery Regulation includes cybersecurity-related requirements for machinery with digital control systems. Coordinate CRA and Machinery Regulation compliance to avoid gaps and duplication.
Compile a full SBOM covering robot controller OS, motion planning software, safety modules, and all network-facing components
Robot controllers run complex software stacks including real-time OS, motion control frameworks, and OPC-UA or ROS2 middleware. All must be tracked.
2. Product Security (Annex I Part I)
Implement role-based access control with strong authentication for all robot programming and administration interfaces
Unauthorised access to robot programming interfaces can cause physical harm. Enforce MFA and role separation between operators, programmers, and administrators.
Encrypt all communications between robots, controllers, and supervisory systems
Robot-to-controller and robot-to-SCADA communications must be encrypted. Industrial protocols (OPC-UA, MQTT) should be deployed over TLS.
Implement network segmentation to isolate robot control networks from corporate IT and the internet
Robot control networks should be on isolated VLANs or air-gapped segments. Internet connectivity for remote monitoring must be mediated by a secure gateway.
Ensure safety function integrity is preserved under cyber attack — safety interlocks must not be software-defeatable
Hardware-enforced safety limits (torque limits, speed limits, workspace limits) must be independent of the software control stack and not overridable via network commands.
Implement tamper-evident audit logging of all robot configuration changes, program uploads, and safety parameter modifications
Forensic logging is essential for incident investigation. Logs must be tamper-evident and stored off the robot controller.
3. CVD Policy & Vulnerability Handling
Publish a CVD policy and security contact for robot controller software and associated management platforms
Industrial robotics platforms have attracted increasing security research attention. A clear CVD policy is required and demonstrates responsible security stewardship.
Define security patch delivery process for robot controllers in production environments with minimal downtime
Industrial operators cannot take robots offline arbitrarily. Develop an update process supporting scheduled maintenance windows with validated patch testing.
Establish a coordinated disclosure process with industrial customers for site-specific vulnerability remediation
Enterprise and industrial customers need advance notice of security patches to plan maintenance windows. Build customer notification into your CVD process.
4. Article 14 Incident Reporting
Define what constitutes an actively exploited vulnerability in a robot system — focus on safety, production disruption, and data exfiltration
For robotics, a remotely exploitable vulnerability that could affect safety interlocks or cause uncontrolled motion is the highest-severity trigger for Article 14.
Document the Article 14 notification chain including OT security team, legal, and ENISA reporting platform contact
Industrial incidents often involve both IT and OT teams plus safety officers. The Article 14 process must involve all relevant stakeholders.
5. CE Marking & Technical Documentation
For Class I products, conduct internal conformity assessment and document against Annex I requirements
Class I allows self-assessment but requires rigorous documentation. Consider voluntary third-party assessment for products with safety implications.
Prepare integrated technical file covering both Machinery Regulation and CRA requirements to avoid duplication
Robot technical files typically already exist for Machinery Regulation compliance. Extend them with CRA cybersecurity risk assessment, SBOM, and CVD policy sections.
Issue EU Declaration of Conformity referencing both the CRA and Machinery Regulation
A single DoC can reference multiple directives/regulations. Ensure the CRA is explicitly listed alongside the Machinery Regulation and any other applicable legislation.
Track your Industrial Robotics & Collaborative Robots compliance progress in CVD Portal.
Public CVD submission portal, Article 14 deadline alerts, SBOM tracking, and CSAF advisory generation. Free forever for manufacturers.
Start your free portalFrequently asked
Is a collaborative robot (cobot) treated differently from a traditional industrial robot under the CRA?+
The CRA does not distinguish between cobots and traditional robots — both are products with digital elements subject to the same requirements. However, cobots operate in close proximity to humans, which makes the safety-security intersection particularly critical. A security compromise affecting cobot safety functions has direct physical harm potential and should be treated as the highest severity.
Our robots run ROS2 — does the open-source middleware affect our CRA obligations?+
Using open-source middleware like ROS2 does not reduce your CRA obligations as the product manufacturer. You are responsible for the security of the entire product, including all open-source components. You must include ROS2 and all its dependencies in your SBOM and monitor them for CVEs. The open-source community maintains ROS2 security advisories that you should subscribe to.
We supply robots to automotive manufacturers who integrate them into their production lines — who is responsible for CRA compliance?+
As the robot manufacturer, you are responsible for the security of the robot as a product. The automotive manufacturer integrating robots into their production line becomes an 'operator' and takes on responsibilities for the security of the integrated system. Both parties have distinct but complementary obligations. Your sales contracts should clearly delineate responsibilities and require customers to apply security patches.
Need a CVD policy for Industrial Robotics & Collaborative Robots?
Download a free CRA-compliant disclosure policy template and deploy it in minutes.