Robotics Security Guide: Robots, Cobots and Identity

A compromised robot is not just a compromised computer: it can move a heavy arm, change a weld path or tell an operator it is stopped when it is not. Industrial robots, collaborative robots (cobots) and autonomous mobile robots (AMRs) now sit on the same networks as PLCs, MES servers and vendor remote access boxes, and many still ship with file services, fixed accounts and unsigned programs. Safety standards and EU product law have started to treat cybersecurity as part of machine safety, with ISO 10218:2025 and the EU Machinery Regulation leading the change. This guide covers the robot attack surface, controller and teach pendant access, ROS 2 security with SROS 2, robot identity and fleet management, AMRs, and how security and safety requirements fit together. It is written for OT security engineers, robot integrators, controls engineers and plant security leads.

Key takeaways

Treat the robot controller as a safety-relevant OT asset. It holds programs, calibration and control-loop parameters that an attacker can change to cause defects or unsafe motion, so it belongs in an OT zone with controlled conduits.
Close the side doors first. FTP file services, dashboard or remote command ports, vendor service routers and Bluetooth setup channels have caused more robot exposure than exotic exploits.
Every robot is an identity. Controllers, ROS 2 nodes, AMRs and fleet managers authenticate with certificates, keys and service accounts that need inventory, ownership, rotation and revocation like any other non-human identity.
Safety and security now meet in the standards. ISO 10218-1:2025 adds cybersecurity requirements where they affect safety, and the EU Machinery Regulation, which applies from 20 January 2027, requires protection against corruption and evidence of interventions.
Integrity beats secrecy on the shop floor. Signed programs, change detection on robot programs and parameters, and alerts on operating mode changes give more protection than encryption alone.

The robot attack surface

A robot cell is a small distributed system: the controller (a real-time computer running the vendor OS), the teach pendant, safety controllers and scanners, the cell PLC, an engineering workstation with the vendor programming suite, and often a service router that gives the integrator remote access. Cobots add dashboard interfaces; AMRs add Wi-Fi and a fleet manager.

The 2017 Rogue Robots research by Trend Micro and Politecnico di Milano tested an ABB IRB 140 arm with an IRC5 controller and defined five attack classes that still frame the problem well: altering control-loop parameters, tampering with calibration, tampering with production logic, altering the state the operator sees on the pendant, and altering the robot's true state. Halving one joint's proportional gain moved the path by under 2 mm, enough to ruin a part without an obvious alarm. The same study found robots from several manufacturers exposed through FTP, some with anonymous access, and tens of thousands of industrial routers reachable online, about 5,105 of them without authentication.

Component	Typical exposure	Impact if abused	First control
Robot controller	FTP or SMB file service, vendor protocol ports, default or fixed accounts	Program, parameter or calibration changes; denial of service	Disable unused services, change or disable default accounts, restrict by firewall to the engineering zone
Teach pendant	Physical access, pendant software, wireless pendants	Mode changes, jogging, program edits	User management on the controller, pendant role levels, physical control of the cell
Cobot dashboard or remote API	TCP command interfaces reachable from the plant network	Remote program start or stop, command execution on the controller	Disable when not needed, allow only from named hosts, patch promptly
Service router or remote access box	Internet or cellular exposure, shared VPN keys, weak admin interfaces	Direct path from the internet into the cell	Brokered, logged, time-bound remote access with MFA
Engineering workstation	Vendor programming suites, USB, email and web on the same host	Malicious program download to many robots	Dedicated hardened hosts, application allowlisting, no internet browsing
AMR and fleet manager	Wi-Fi, web UI, REST APIs, Bluetooth setup, cloud telemetry	Route manipulation, fleet-wide stop, data leakage	WPA3-Enterprise or certificate-based Wi-Fi, API authentication, egress control

See the OT Security Guide for the wider environment the robot cell sits in.

Controller and teach pendant access

Most robot controllers support local user management with role or grant levels, but the factory default often leaves an operator account with no password, or an account that cannot be removed. The Rogue Robots study found a default account that could not be changed and configuration files that could be edited to raise privileges or expose passwords. Assume the same until you have checked your controller's documentation and current firmware.

Accounts: create named accounts for programmers and maintenance staff, keep an operator role that can run but not edit programs, and restrict the administrator role to a small group. Where the controller cannot support named accounts, compensate with physical access control and a logbook of pendant use.
Operating modes: automatic, manual reduced speed and manual high speed are safety functions, normally selected with a key or mode switch and backed by a three-position enabling device on the pendant. Security controls must never weaken these. Log mode changes and alert when a mode changes outside a maintenance window.
Remote programming: many controllers allow program download from the network only in specific modes or with a remote access grant. Turn that grant off by default and enable it per change.
File services: disable FTP where the vendor supports it, or limit it to the engineering workstation by IP. Files loaded this way were implicitly trusted in the 2017 research, with no integrity check or code signing.
Remote command interfaces: cobot dashboard servers and similar TCP interfaces accept commands from any host that can reach them unless restricted. In May 2026 Universal Robots and CISA published advisories for an OS command injection flaw in the PolyScope 5 Dashboard Server, reported as CVE-2026-8153 with a CVSS score of 9.8 and fixed in PolyScope 5.25.1; the recommended interim steps were disabling the Dashboard Server and blocking its port.
Backups: take signed or hashed backups of programs, configuration and calibration after every approved change, store them off the controller and test restores. A clean backup is the fastest recovery from both tampering and failure.

See the OT and ICS Identity and Access Guide for account models that work on shared HMIs and pendants.

ROS 2 security and SROS 2

The Robot Operating System is common in research, AMRs, service robots and newer industrial applications. ROS 1 had no built-in authentication, so any host on the network could publish to topics. ROS 2 runs over DDS, and SROS 2 adds tools that generate the keys and policy files used by the OMG DDS Security specification, now at version 1.2. DDS Security defines plugins for authentication, access control and cryptography, with governance and permissions documents signed by a permissions certificate authority.

SROS 2 element	What it does	Security note
`ros2 security create_keystore`	Creates the keystore with the identity and permissions CAs	The CA private keys are the root of trust for the whole robot or fleet: keep them off the robot and offline where possible
`ros2 security create_enclave`	Creates keys, certificate and permissions for an enclave such as `/talker_listener/talker`	One enclave per node or process group gives the finest control; shared enclaves blur accountability
`ROS_SECURITY_KEYSTORE`	Points the process at the keystore	Ship only the enclave material a robot needs, not the full keystore
`ROS_SECURITY_ENABLE=true`	Turns security on	Security is off unless set: check it in every launch file and container image
`ROS_SECURITY_STRATEGY=Enforce`	Refuses to start a node that lacks valid security files	The permissive alternative quietly runs nodes without security; use Enforce in production
`--ros-args --enclave`	Binds a node to its enclave at launch	Audit launch files so nodes cannot pick a more privileged enclave
`ROS_SECURITY_ENCLAVE_OVERRIDE`	Lets CLI tools join the secured graph as a given enclave	Restrict who can use this on production robots; it is effectively an operator credential

Permissions policies: write allow rules per topic, service and action, so a perception node cannot publish velocity commands. Default deny, then add.
Vendor interoperability: the SROS 2 documentation notes that secure communication between different DDS vendors is not supported, so standardise one RMW implementation per system.
Discovery traffic: DDS discovery uses multicast by default. Keep ROS 2 domains on dedicated network segments and do not bridge them to corporate Wi-Fi.
Certificate life: SROS 2 certificates expire. Plan renewal and revocation before deployment, not after the first outage. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Robot identity and fleet management

Robots and their software authenticate constantly: the AMR to Wi-Fi and the fleet manager, the fleet manager to the warehouse management system, the controller to the vendor cloud for diagnostics, ROS 2 nodes to each other, and integrators to all of them. Each of those is a non-human identity, and robot fleets accumulate them fast.

Inventory: record each robot's serial number, controller firmware, software options, network addresses, certificates and service accounts. Passive OT asset discovery tools recognise many robot protocols. See the OT Asset Visibility Guide.
Unique credentials per robot: never reuse one Wi-Fi pre-shared key, API key or certificate across a fleet. Per-device certificates let you revoke a stolen or decommissioned robot without touching the rest. See the Device and IoT Identity Guide.
Hardcoded keys: the UniPwn research published in September 2025 showed Unitree Go2, B2, G1 and H1 robots accepting Bluetooth Wi-Fi setup packets protected only by keys fixed in firmware, then running injected values as root. Because the attack is wireless, the researchers described it as wormable between robots in range. Ask suppliers how setup channels are authenticated and whether keys are unique per device.
Fleet manager accounts: the fleet manager can send missions and stop every robot. Put it behind SSO with MFA for people, use scoped API credentials for integrations, and log every mission and configuration change.
Vendor cloud and telemetry: robots increasingly stream diagnostics, maps and camera data to vendor clouds. Review what leaves the site, allow egress only to documented endpoints, and decide whether map and video data is acceptable to share.
Decommissioning: wipe controllers, revoke certificates and remove fleet accounts when a robot is sold, returned or scrapped.

Autonomous mobile robots

AMRs differ from fixed arms in three ways that matter for security: they rely on wireless networks, they share space with people across a whole site rather than a fenced cell, and they depend on maps and sensor input that can be altered. Their safety functions (laser scanner fields, speed limits near people) should run on certified safety hardware independent of the navigation software, so an attacker who compromises navigation still cannot disable the protective stop. Confirm this with the supplier rather than assuming it.

Wireless: use WPA3-Enterprise or EAP-TLS with per-robot certificates, separate SSIDs and VLANs for robots, and roaming tested under load. See the Wi-Fi Security Guide.
Bluetooth and setup modes: disable Bluetooth and setup access points after commissioning where the product allows it. The interim advice after UniPwn was exactly this: isolate robots on their own Wi-Fi and turn Bluetooth off.
Maps and zones: treat map, zone and speed-limit edits as controlled changes with approval and history.

Safety standards and regulation: where security now fits

Robot safety used to assume accidental faults, not adversaries. That has changed in the 2025 revision of ISO 10218 and in EU law.

Instrument	Status	Security relevance
ISO 10218-1:2025 (robots) and ISO 10218-2:2025 (robot applications and cells)	Published 2025, replacing the 2011 editions; announced by A3 in February 2025	Part 1 adds cybersecurity requirements to the extent they affect safety, folds in collaborative requirements from ISO/TS 15066 and defines Class I and Class II robots. Part 2 covers integrators and applications
ANSI/A3 R15.06 and CSA Z434	National adoptions being aligned with the 2025 edition	North American route to the same requirements
EU Machinery Regulation (EU) 2023/1230	In force; applies from 20 January 2027	Annex III essential requirements 1.1.9 (protection against corruption) and 1.2.1 (safety and reliability of control systems) require protection against accidental or intentional corruption and collection of evidence of legitimate or illegitimate intervention. Article 20(9) gives a presumption of conformity for these points to machinery certified under an EU cybersecurity certification scheme
FprEN 50742 (CENELEC)	Final draft in approval in 2026, intended as a harmonised standard for the Machinery Regulation	Safety-related security levels SRSL0 to SRSL3, a manufacturer route and an IEC 62443 route, logging (with physical evidence such as broken seals where digital logs are not possible), signed software and transition to a safe state when integrity is lost
IEC 62443 series	Published series	Zones and conduits for the plant (62443-3-3) and component requirements for controllers and devices (62443-4-2)
EU Cyber Resilience Act	In force, obligations phasing in	Vulnerability handling and security updates for products with digital elements, including robot software

Integrator duty: the risk assessment for a robot cell should now include threats such as remote program change or mode spoofing, and the resulting controls should be part of the technical file.
Self-learning systems: the Machinery Regulation recitals single out safety functions with self-evolving behaviour using machine learning for stricter conformity assessment. Robots that learn grasping or navigation online need particular care. See the EU AI Act Compliance Guide for the parallel AI obligations.
Do not trade safety for security: patches, scanning and authentication must never block an emergency stop or delay a protective stop. Test every security change on a non-production cell first.

See the IEC 62443 Guide and the EU Cyber Resilience Act Guide.

Implementation roadmap

Inventory and exposure check (weeks 1 to 4): list every robot, controller version, pendant, service router and fleet manager. Check from outside that no controller, router or dashboard port is internet reachable, and from the plant network which services each controller exposes.
Quick wins (weeks 2 to 8): disable unused file services, dashboard servers and Bluetooth; change or disable default accounts; remove unmanaged service routers and replace them with brokered remote access. Do this per cell during planned downtime, with a backup taken first so you can roll back.
Segmentation (months 2 to 6): place robot cells in OT zones, allow only engineering workstations and the cell PLC to reach controllers, and route vendor access through a jump host. Start with firewall rules in log-only or monitor mode, review a week of traffic, then enforce. See the Network Segmentation Guide.
Integrity controls (months 3 to 9): baseline programs, parameters and calibration; compare against the baseline on a schedule; require signed or approved programs where the controller supports it; enable SROS 2 Enforce on ROS 2 systems after a pilot on one robot.
Monitoring (months 4 to 12): feed controller events, mode changes and program downloads into OT monitoring and the SOC, with playbooks agreed with operations.
Procurement and lifecycle (ongoing): add security requirements to robot purchase specifications: unique credentials, signed updates, documented ports, an SBOM, a vulnerability disclosure contact and a support period. Ask how the product will meet Machinery Regulation 1.1.9 and 1.2.1.

Small versus large sites: a plant with a handful of cobots can get most of the benefit from steps 1 to 3 and good backups. Multi-site fleets need central inventory, a PKI for robot certificates, a fleet-level change process and supplier security reviews.

Detection and measurement

Program and parameter changes: any download or edit outside an approved change, especially to safety configuration or calibration.
Mode changes: automatic to manual and back, or remote programming grants enabled, outside maintenance windows.
New connections: controller sessions from hosts other than the named engineering workstations; first-seen file transfers.
Fleet events: mass mission cancellation, map edits and new API clients on the fleet manager.
Quality signals: unexplained drift in part dimensions or weld quality can be the first sign of parameter tampering, so share quality alerts with security.

Metric	Target direction
Robots with a current verified program and configuration baseline	100%
Robots with default or shared credentials remaining	Zero
Controllers or service routers reachable from outside their OT zone	Zero
Program changes matched to an approved change record	100%
Median days to apply critical robot software fixes, or apply compensating controls	Falling, within your OT patch policy
ROS 2 systems running with `ROS_SECURITY_STRATEGY=Enforce`	100% of production

Framework mapping

Area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	MITRE ATT&CK for ICS
Robot and identity inventory	ID.AM-01, PR.AA-01	CM-8, IA-3	T0883 Internet Accessible Device
Controller accounts and remote access	PR.AA-05	AC-3, AC-6, IA-5	T0822 External Remote Services, T0866 Exploitation of Remote Services, T1078 Valid Accounts
Segmentation and wireless	PR.IR-01	SC-7, SC-8	T0860 Wireless Compromise
Program and parameter integrity	PR.PS-01, PR.PS-02	SI-7, CM-7, SR-11	T0843 Program Download, T0889 Modify Program, T0821 Modify Controller Tasking, T0836 Modify Parameter
Operator view and monitoring	DE.CM-01	AU-2, AU-12, SI-4	T0832 Manipulation of View, T0831 Manipulation of Control
Safety impact	ID.RA-04	RA-3	T0880 Loss of Safety, T0879 Damage to Property

In ISO/IEC 27001:2022 Annex A the closest controls are A.5.9 (inventory), A.8.2 (privileged access rights), A.8.9 (configuration management), A.8.15 (logging), A.8.22 (segregation of networks) and A.8.32 (change management). In CIS Controls v8.1, Controls 1, 4, 6, 12 and 13 carry most of the work.

Common failure patterns

The forgotten service router. An integrator installs a cellular or VPN box for commissioning and it stays, with shared keys and no logging, long after the warranty period.
Default accounts left in place. Controllers run with the factory operator account and no password, so anyone on the network with the vendor tool can edit programs.
Dashboard and command ports open to the whole plant. Cobot interfaces meant for the cell PLC are reachable from office VLANs, which turns a single remote flaw into a plant-wide risk.
SROS 2 configured but not enforced. Teams generate keys in the lab, then ship launch files without ROS_SECURITY_ENABLE or with the permissive strategy, so production robots run unauthenticated.
Fleet-wide shared secrets. One Wi-Fi key or API token used by every AMR means one lost robot exposes the fleet, and rotation needs downtime for all of them.
Robots assumed to be isolated from IT. Production depends on IT systems for scheduling, parts and quality data. The Jaguar Land Rover cyberattack in 2025 halted global vehicle production, a reminder that robot lines stop when the systems around them are hit, even if no robot is touched.

Practitioner checklist

Inventory every robot, controller version, pendant, service router, fleet manager and robot credential, with a named owner.
Confirm no controller, cobot dashboard, fleet manager or service router is reachable from the internet or from office networks.
Disable unused FTP, dashboard, remote command and Bluetooth services; change or disable default accounts.
Replace standing integrator access with brokered, time-bound, MFA-protected remote sessions that are logged.
Baseline and back up programs, parameters, safety configuration and calibration after each approved change, and test a restore.
Run ROS 2 production systems with ROS_SECURITY_ENABLE=true and ROS_SECURITY_STRATEGY=Enforce, default-deny permissions and CA keys kept off the robots.
Issue unique credentials or certificates per robot and plan their rotation and revocation, including at decommissioning.
Alert on program downloads, mode changes and new controller connections outside maintenance windows.
Add security requirements, including Machinery Regulation 1.1.9 and 1.2.1 evidence, to robot and cell procurement specifications.
Test every security change on a non-production cell and confirm emergency and protective stops are unaffected.

Robotics Security Guide: Industrial Robots, Cobots and Robot Identity