← Industry Guides
Industrial & ManufacturingCRA Guide

EU Cyber Resilience Act Guide for Robotics & Collaborative Robot Manufacturers

Important Class I for network-connected robots with remote access or safety-critical functions

Robotics and collaborative robot (cobot) manufacturers placing industrial robots, autonomous mobile robots (AMRs), and cobot platforms on the EU market must address CRA obligations alongside existing Machinery Regulation requirements. Network-connected robotic systems with remote programming, monitoring, or update capabilities are classified as Important Class I under the CRA, given their direct role in manufacturing safety and production continuity.

Article 13Article 14Annex IAnnex IIIArticle 10Article 20
Deadline: September 2026Classification: Important Class I for network-connected robots with remote access or safety-critical functions

CRA Scope and Classification for Robotic Systems

Industrial robots, collaborative robots (cobots), autonomous mobile robots (AMRs), robot operating system (ROS)-based platforms, and robotic management software are products with digital elements within CRA scope when they include network interfaces, remote management capabilities, or software that receives external updates.

Network-connected robots that can receive remote programming instructions, transmit production telemetry, or accept over-the-air firmware updates fall into Important Class I under Annex III — particularly where the robot performs functions directly adjacent to human workers (cobots) or manages safety-critical production processes. The Machinery Regulation (EU 2023/1230), which entered force in January 2024, governs the mechanical and functional safety of robotic systems; the CRA governs the cybersecurity of the digital elements within those systems. Both regulations apply concurrently — CE marking for robots must satisfy both.

CRA reference:Article 6, Annex III

Annex I Security Requirements for Robotic Systems

Robotic systems present unique Annex I challenges because cybersecurity failures can have direct physical safety consequences — unauthorised manipulation of a robot's motion parameters can injure workers or damage equipment:

  • Authenticated control interfaces: All interfaces accepting motion commands, program uploads, or configuration changes must require strong authentication. Remote programming APIs must not accept unauthenticated commands.
  • Integrity-protected firmware: Robot controller firmware must be cryptographically signed and verified. Firmware downgrades to known-vulnerable versions must be prevented.
  • Network segmentation support: Robots must support operation in segmented OT networks. Management interfaces must be separable from production data interfaces.
  • Fail-safe behaviour: If network connectivity or authentication mechanisms fail, the robot must default to a safe state — not a state that allows unrestricted operation.
  • Audit logging: All programming events, parameter changes, operator logins, and remote access sessions must be logged with timestamps and attribution.
CRA reference:Annex I

CVD Policy and Article 13 for Robotics Vendors

Robotics manufacturers typically focus security resources on functional safety (ISO 10218, ISO/TS 15066 for cobots) rather than cybersecurity, and many lack formal CVD policies. Article 13 requires a publicly accessible CVD policy covering all products with digital elements — including robot controllers, programming pendants, and fleet management software.

  • Define a clear scope covering all network-connected robotic products
  • Specify a secure submission channel for researchers and operators
  • Include a commitment to prioritising vulnerabilities that could affect worker safety
  • Coordinate with customers (factory operators) before public disclosure, given that unpatched robot vulnerabilities in production environments represent an immediate occupational safety risk

CVD Portal can serve as the intake channel for the CVD policy, with triage functionality that supports escalation of safety-critical disclosures to immediate internal response.

CRA reference:Article 13(1), Article 13(6)

Article 14 Incident Reporting for Robotics

Active exploitation of robotics vulnerabilities is a relatively novel threat scenario, but the consequences — production disruption, physical injury, corporate espionage via manufacturing data theft — make Article 14 compliance critical. The 24-hour ENISA notification requirement applies when exploitation is confirmed.

  • Unauthorised remote access to production robots used for corporate sabotage or data exfiltration
  • Ransomware deployment targeting robot controllers to disrupt production
  • Manipulation of robot program parameters by an insider or external attacker

Manufacturers should establish monitoring capabilities — ideally in coordination with their industrial operator customers — that can detect exploitation signals. The 24-hour notification to ENISA must identify the affected product, the nature of the exploitation, and any immediate mitigations such as isolating affected systems from the network. Parallel notification to affected factory operator customers is essential given production safety implications.

CRA reference:Article 14(1), Article 14(2)

Conformity Assessment and Machinery Regulation Alignment

Class I robotic products with digital elements require third-party CRA conformity assessment. Manufacturers who have already engaged a notified body for Machinery Regulation assessment should investigate whether the same body is accredited for CRA conformity assessment, potentially enabling a coordinated assessment programme.

  1. Annex I Part I cybersecurity requirements for the digital elements (controller software, remote interfaces)
  2. Annex I Part II vulnerability management — SBOM, patch process, CVD policy
  3. The relationship between cybersecurity measures and functional safety measures (the two must not conflict)
  4. Technical file completeness

Robotics manufacturers should note that IEC 62443 (industrial cybersecurity) provides a directly applicable framework for robot controller cybersecurity that aligns with CRA Annex I. Vendors investing in IEC 62443-4-2 component certification should position this as CRA conformity supporting evidence.

CRA reference:Article 24, Annex VIII

CVD Portal handles your CRA Article 13 obligations automatically.

Public CVD submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free forever for Robotics & Collaborative Robot Manufacturers.

Start your free portal

Frequently asked

Does the Machinery Regulation cover cybersecurity for robots, or is the CRA additional?+

The Machinery Regulation (EU 2023/1230) includes provisions requiring that machinery resist corruption, interference, and unintended access that could affect safety. These provisions address cybersecurity from a functional safety perspective. The CRA applies separately and addresses cybersecurity as an independent requirement — covering vulnerability management, CVD policy, incident reporting, and security update obligations that are outside the Machinery Regulation's scope. CE marking for network-connected robots must satisfy both regulations. The two sets of requirements are complementary; a cyber-secure robot is also a safer robot, but the CRA imposes obligations that go beyond functional safety.

Are autonomous mobile robots (AMRs) used in logistics subject to the CRA?+

Yes. AMRs deployed in logistics — warehouse picking robots, autonomous forklifts, delivery robots operating in public spaces — are products with digital elements that are within CRA scope when placed on the EU market. The classification depends on the robot's network connectivity, data processing, and safety-critical function. AMRs operating in proximity to human workers and accepting remote commands via cloud platforms are likely Class I. Vendors should also note that AMRs operating on public roads may be subject to additional type-approval requirements.

How do we handle software vulnerabilities in the ROS (Robot Operating System) middleware our robots use?+

ROS components embedded in your robot products are part of your product's SBOM and your responsibility under the CRA. You must monitor for vulnerabilities in the ROS packages you use (including upstream ROS 2 packages), assess their impact on your product, obtain or develop patches, and deliver security updates to your customers. The ROS security working group and ROS 2's security architecture provide resources for managing ROS vulnerabilities, but the CRA obligation to patch and update sits with you as the product manufacturer. Consider whether your robot products are running ROS versions that are still actively maintained upstream.

Need a CVD policy template for Robotics & Collaborative Robot Manufacturers?

Download a free CRA-compliant vulnerability disclosure policy and deploy it in minutes.

Browse templates →