Cobots vs. Hackers

The rise of the Industrial Internet of Things (IIoT) network of connected sensors, instruments, and intelligent devices used in industries like manufacturing, energy, and logistics is a huge net plus, optimizing processes, boosting productivity, and preventing costly equipment failures. But it has also led to a corresponding rise in concerns, among design engineers and everyone else in the manufacturing space, about the vulnerability of these systems to cyberattacks, which disrupt critical infrastructure and manufacturing operations by compromising network gateways, exploiting unpatched firmware, or hijacking devices to disrupt enterprise productivity.

And it’s no idle threat: According to the IBM X-Force Threat Intelligence Index, which tracks global cyberattack trends, incident response engagements, and threat actor behaviour, manufacturing has been the most attacked industry globally for five consecutive years. This is in large part because IIoT systems and devices present unique opportunities for attack because they connect vulnerable operational technology (OT) sensors and legacy industrial control systems (ICS) directly to corporate IT networks.

Collaborative robots, or cobots, are at the leading edge of the smart factory wave, revolutionizing industrial automation by communicating with and operating alongside humans in a shared workplace. And they’re also IIoT-class devices, and are as vulnerable to cyberattacks as PLCs, HMIs, vision systems, CNC controllers, and MES gateways if the security is weak. In fact, traditional industrial robots are often integrated even more deeply into the network, controlled by PLCs or industrial PCs as part of larger automation lines connected to MES systems. By exploiting vulnerabilities to gain unauthorized access to a cobot – and traditional robots – criminal hackers can launch attacks that range from data theft to reconfiguring the robot to perform the wrong motions, causing product damage or product recalls.

Which is why most users are concerned. “Customer questions about cybersecurity typically come from three directions at once,” said Martin Olesen, head of software product management with Universal Robots (UR), based in Odense, Denmark. “First, industry regulations governing cobots; second, the operational risk, including ransomware downtime, IP theft, and the quality control implications of compromised motion control; and third, supply chain accountability, as their auditors and end customers increasingly request evidence of secure suppliers.” Fortunately, concerns about hackers exploiting software flaws to order cobots to actually strike workers aren’t warranted today, Olesen noted. “Cobots are built with independent, safety-rated functions designed to keep protective stops and speed and force limits in place even if the main application controller is compromised,” he said.

Outlining the risks

One way to reduce the risk of a cobot being hacked, of course, is to limit how it connects to outside networks; a controller kept on an isolated, well-secured company network is a much harder target. But complete isolation isn’t feasible for cobot designers and end users who want to use connected IIoT software, which relies on network connectivity. Potential privacy weaknesses in cobots in factory processes, even when commands are encrypted, were outlined in a recent study from the University of Waterloo’s Cybersecurity and Privacy Institute, in Waterloo, Ont. The study, “On the Feasibility of Fingerprinting Collaborative Robot Network Traffic,” focused on script-based robots, where robots perform pre-programmed commands, which is a unique interface that allows robots to complete tasks with minimal human intervention. Using signal-processing techniques, the Waterloo team identified the actions of a Kinova Gen3 robotic arm, a model widely used in research settings, with 97 per cent accuracy based solely on encrypted data flow. “Picture a robot talking to its controller – you can’t understand the conversation, but you can notice when the robot is talking or not,” said Cheng Tang, the paper’s lead author and an engineering undergraduate student.

According to the researchers, their results suggest that cobots could easily leak private information, from industry secrets to patient confidentiality. “The robot could be anywhere, like a hospital, factory, or another country,” said Dr. Yue Hu, a professor of mechanical and mechatronics engineering and a co-author of the study. “Many don’t realize that once these robots are hooked into the network, they’re exposed to security risks.”

Commenting on the Waterloo paper, Olesen admitted that it raises some valid concerns. “Encrypted traffic fingerprinting is a known research area, and the Waterloo paper is a useful contribution to it, but it’s worth being precise about what a Waterloo-style traffic analysis attack would and wouldn’t reveal,” he said. “At best, it could distinguish among a small set of pre-known motion archetypes, but it doesn’t extract program code, waypoints, recipes, payload data, or part geometries. The data categories that matter most for protecting customer IP are addressed by access control, authentication, and network segmentation, not by traffic pattern obfuscation. So in the context of UR cobots deployed on a typical factory floor, we view it as a low-probability, low-impact concern relative to the more established threats that drive industrial cybersecurity work today.”

Analyzing the analysis

In principle, Olesen said, any networked device on a flat OT network can be misused for lateral movement, so the security of the network as a whole matters more than any single cobot; with segmentation, restricted data flow, and disabled-by-default services in place, a cobot is a poor pivot point. There are three main reasons, he added, why a Waterloo-style traffic analysis attack shouldn’t be a big concern for users of factory cobots. “First, industrial cobots aren’t exposed to the open internet,” he said. “A cobot sits inside a plant network, normally behind firewalls and segmentation. The Waterloo threat model assumes an attacker who can already passively wiretap the link between the robot and a remote controller. Reaching that vantage point inside a properly configured factory network is itself a significant intrusion, and once an attacker is in that position there are easier and higher value things to do than fingerprint motion patterns.”

Second, Olesen continued, the Waterloo study is a closed-world lab result. “It shows that, given a known short list of candidate motions and an identical robot used to build a training set, those motions can be told apart,” he said. “A real production cell runs many overlapping program steps with varying payloads, parts, and parallel processes, and an attacker wouldn’t have a labelled training set of what a specific factory does.”

And third, Olesen said, public ICS incident reporting doesn’t show this attack pattern. “The dominant reported attack patterns in manufacturing are credential abuse, exploitation of known unpatched vulnerabilities, ransomware on IT/OT bridges, and phishing,” he said. “We’re not aware of any documented incident where encrypted traffic fingerprinting was used to extract proprietary process information from a cobot deployment.”

The Waterloo researchers suggest that certain design choices could prevent leakage and make a system’s network steadier, including adjusting the timing of its application programming interface (API) or applying a smart traffic-shaping algorithm at run-time. Olesen doesn’t disagree with this suggestion, but notes that it has documented trade-offs around latency, bandwidth, and real-time determinism. “Determinism matters for safety functions and for cycle time, so any such mechanism would need to be designed without compromising those properties,” he said. “Traffic-shaping or padding as proposed in the Waterloo paper can be considered as one element among many.”

Defence strategies

Instead, Olesen identified other cobot design choices that have a higher value-to-cost ratio than API timing manipulation. “These include network segmentation and zoning as defined in IEC 62443 FR5, the single most effective control; modular, updatable platform architecture, such as PolyScope X – UR’s next-generation software platform – which separates the OS [operating system] from the application so that security patches can be delivered continuously without disturbing robot programs; encryption with authentication for remote access, including SSH with key-based authentication and TLS for cloud connectivity; minimal API surface and disabled-by-default services, which reduces both the attack surface and the signal an external observer can fingerprint; and authentication, RBAC, and audit logging, which are all part of UR’s IEC 62443-4-2 SL1 work for PolyScope X by 2027,” he said.

The current cybersecurity framework shaping the cobot industry, which new cobots should satisfy, includes IEC 62443-4-1 and IEC 62443-4-2; the EU Cyber Resilience Act, which applies from Dec. 11, 2027; the EU Machinery Regulation 2023/1230, which applies from Jan. 20, 2027; NIS2; and ISO 10218-1:2025, clause 5.1.16. “Globally, modern cobot platforms are being designed and certified against this framework ahead of its deadlines, while much of the broader installed IIoT base predates these requirements,” Olesen said. As one example, UR’s parent company, Teradyne Robotics, is certified to IEC 62443-4-1 ML2 and has been an authorized CVE Numbering Authority under CISA ICS since June 2025.

Older cobots, particularly those built before the current rise of IIoT, are often less secure and harder to protect than newer models. But there are ways to make even old, exposed systems safer. “For any earlier-generation fleet, UR’s recommendation is the standard defence-in-depth approach that applies to industrial equipment of that generation: place the robot on a dedicated, segmented subnet, deploy a hardware firewall between the robot and other networks, allow only the ports needed for the specific integration, restrict physical access to the teach pendant and USB ports, and monitor traffic to and from the robot subnet,” Olesen said.

With both newer and older cobots, it’s important for the user to update the robot firmware as soon as an update is released. As noted in a recent article from the Robotics Business Review, IIoT devices can suffer from security flaws for much longer than consumer devices due to their longer lifespans. Updating the firmware regularly is an essential part of counteracting these flaws.

A good offence

In the end, Olesen said, customer concerns about cyberattacks in a manufacturing setting are real, valid, and even healthy, given that the clean-up costs after a bad cyberattack can be enough to put a small company out of business. The good news is that customers are becoming more sophisticated about the risks and how to lessen them. “The conversation has shifted from, ‘Is your robot safe?’ to specific requests for an SBOM [software bill of materials], coordinated vulnerability disclosure policies, and IEC 62443 certification evidence,” he said.

But the big point to remember, Olesen continued, is that the practical security of any cobot deployment is determined far more by the network it sits on than by the protocol-level details of its communication. And while it sounds obvious, taking one fundamental, common-sense precaution at the outset is key. “Keeping unauthorized devices and people off the OT network in the first place is the highest leverage control, and it’s the foundation that the platform’s built-in security features are designed to reinforce,” he said.