Exhibitors & Products
Events & Speakers
Daily Program

Due to this vulnerability, an unauthenticated attacker who can access the relevant network port could execute commands on the robot’s operating system; Universal Robots rates the vulnerability with a CVSS 3.1 score of 9.8 and recommends updating to PolyScope 5.25.1 or later.

Safety alone is no longer enough

There was something reassuring about the good old robot cell. Safety fence, controller, teach pendant, emergency stop—that was it. Of course, it was never trivial, but it was tangible. You could walk around it, stick warning signs on it, and convince yourself that the danger was primarily mechanical. The robot moves, so you have to prevent anyone from getting too close at the wrong moment.

That logic is no longer sufficient. Modern robots are networked. They communicate with vision systems, MES, ERP, cloud services, edge devices, digital twins, remote maintenance systems, and data platforms. Cobots work closer to humans. AI models require updates, data, and interfaces. This transforms the robot not just into a machine, but into a cyber-physical system.

Traditional machine safety focuses on protective enclosures, forces, speeds, safe states, risk analyses, and compliance with standards. All of these remain important. But if motion programs, control access points, network interfaces, or update paths are vulnerable to compromise, security must be brought into the safety discussion. A safely designed cobot is only as safe as the environment in which it operates.

The attacker isn’t interested in organizational charts

The issue is organizationally awkward because responsibilities become blurred. Production views the robot as a piece of equipment. IT sees network traffic. Maintenance sees availability. Occupational safety sees hazards. The integrator sees interfaces. The attacker, above all, sees opportunities. And they are rarely interested in who, according to their job description, would actually be responsible within the company.

In its advisory, Universal Robots points out that UR robots are not designed for direct internet access and that robots accessible from a local network may be vulnerable to attacks originating from that network. This is an important reality check. Many production networks have evolved over time, are loosely segmented, and are full of systems that are allowed to communicate with one another because they once had to—and afterward, no one had the courage to change it—all in the name of “never change a running system” and similar nerd wisdom.

Disabling connectivity is not a strategy

The wrong reaction would be to fundamentally distrust networked robotics. Without connectivity, many productivity gains are virtually impossible to achieve. AI-powered quality inspection, adaptive robotic processes, predictive maintenance, fleet management, energy optimization, remote support, and digital twins all require data flows. The factory of the future will not be any less connected. It just needs to handle it more maturely.

This starts with taking inventory. Many companies know surprisingly precisely how many coffee machines are in the office, but only roughly which controllers, HMIs, robot systems, engineering workstations, and remote access points are active in the plant. Next comes network segmentation, access control, patching processes, monitoring, backup strategies, and clear responsibilities.

AI doesn’t simplify the issue—it makes it more complex

Physical AI and adaptive robotics further increase the demands. When robots don’t just execute programs but react adaptively using vision systems, models, and process data, new questions arise: Which model version has been approved? How is behavior validated after an update? What data influences decisions? How do we prevent incorrect sensor data from triggering incorrect actions? When does the system fall back to a safe state? This may sound like extra work, but in reality, it is part of industrialization. Any technology that moves from a pilot project to production must become controllable.

The solutions to this problem aren’t called “robot antivirus”

Securing connected robots requires a multi-layered architecture. The first step is patching: for Universal Robots, this means PolyScope 5.25.1 or later. This is followed by visibility provided by OT security platforms such as Nozomi Guardian, Claroty xDome, Tenable OT Security, Dragos, or Cisco Cyber Vision. They show which robots, controllers, and engineering systems are active on the network and which risks need to be prioritized. The second layer is segmentation: Industrial firewalls and security appliances such as Siemens SCALANCE S, Phoenix Contact mGuard, Fortinet FortiGate Rugged, Moxa EDR, or TXOne EdgeIPS ensure that robot cells are not accessible from arbitrary networks. The third layer is controlled remote access: solutions such as Secomea, Ewon Cosy+, or IXON replace improvised remote access with regulated, auditable connections.

The Immune System of the Smart Factory

For decision-makers, the message should be clear: Cybersecure Robotics is not a niche topic confined to the IT department. It belongs in procurement, plant planning, integrator selection, maintenance contracts, and risk management. When you buy a robot, you’re no longer just buying mechanics and controls. You’re buying update paths, interfaces, security promises, and, if necessary, the manufacturer’s responsiveness.

The irony of the new generation of robotics is that the smarter they become, the more vulnerable they can be. More sensors, more software, more connectivity, and more autonomy mean greater benefits, but also a larger attack surface. The solution is not fear, but professionalism. When the factory gains a nervous system, it needs an immune system. And that should not be installed only after the robot suddenly starts doing things that were not specified in the requirements document.

v-cloak>