Many throughout the industry, including KC Chen, cybersecurity expert at NEXCOM, see the challenges of reducing the security risks associated with advancing robotics technology as one of the key obstacles to its widerspread adoption. Compounding these concerns are humanoid and cobot developments that would take these machines beyond the plant floor.
I recently sat down to discuss these issues and how current tools like edge computing and embedded software solutions can help in implementing the necessary solutions.
Jeff Reinke, editorial director: What do you think are the general feelings of plant-floor workers towards robotics?
KC Chen, NEXCOM: From my perspective, robotics are most valuable when manufacturers treat them as tools that amplify what people can do. We already use machinery like forklifts to handle work that would be difficult, inefficient, or unsafe to perform manually, and robotics can extend that same principle to repetitive or physically demanding tasks.
Collaborative robots are particularly good examples of this, because they can work alongside people and take on certain tasks while workers focus their time and expertise elsewhere.
Workers may react differently to robotic systems depending on their previous experience. Workers who have used robots before are often more willing to accept them because they understand how robots can support their work. Workers with little or no experience with robotic systems may feel more worried. They may be concerned about losing their jobs, having to learn new skills, or having less control over their work.
If management does not clearly explain why robotics are being introduced and how workers will be positively affected and supported by the new technology, these concerns may lead to resistance.
JR: What do you feel are some of the key cybersecurity measures that manufactures fail to consider when implementing new robotics solutions?
KC: One common gap in cybersecurity considerations is treating a robot as an individual piece of equipment, rather than looking at everything it connects to and has the ability to influence. When they’re implementing new robotics solutions, manufacturers need to understand which controllers can be reached remotely, who has access to them and what changes those users or systems are permitted to make.
Network segmentation, strong remote-access controls, least-privilege permissions and management of vendor accounts are all key considerations that should happen before deployment. Security teams should also understand the physical consequences of a compromise, for instance assessing whether changes to speed, movement or control parameters could affect workers or production.
With connected robotics, the consequences of ignoring these steps can extend well beyond losing data or temporarily taking a system offline. Unauthorized access or changes to a controller could disrupt production, alter how equipment behaves or create a safety issue for people working nearby.
It can also make recovery more difficult if teams don't know which systems were affected or what changed. It’s also important to consider supply chain risks and how firmware security and SBOMs can help mitigate them, especially as new robots often include software components from third-party vendors, open-source libraries and remote maintenance access provided by the manufacturer.
JR: Can you define the term software-defined safety, and the role it could play in helping to quell some implementation concerns?
KC: Software-defined safety reflects the growing role software, sensors and computing systems play in determining a machine’s level of operational safety. As robots become more autonomous and work in less structured environments, manufacturers increasingly need to evaluate what the system is actually doing in real time rather than relying only on fixed physical barriers.
Independent sensing can provide another source of information to verify that a robot’s physical movement matches what its control system says should be happening. That additional visibility can give manufacturers more confidence as robotic systems become more complex and operate closer to people.
Because safety functions are increasingly controlled by software, they may also become targets for cyberattacks. Therefore, important safety software and safety logic should also be protected with measures such as digital signatures, strong access control, and protection against unauthorized changes.
JR: Can AI play a role in helping mitigate risks and reduce exposure to vulnerabilities when implementing robotic solutions?
KC: Yes, especially when AI is used to improve visibility into what is happening around a robotic system. For example, AI-enabled vision can provide an independent way to observe physical movement and compare it with the behavior expected from the robot’s controls. That can help identify situations where the digital status of a system doesn’t accurately reflect what is happening in the physical environment.
However, while AI can strengthen monitoring, manufacturers still need clear boundaries for what an AI system can access, what actions it can take and when human intervention is required.
JR: What advice would you offer in helping manufacturers instill a philosophy that balances risk, benefits and downtime equally when implementing any new technology?
KC: Manufacturers need incident response plans that account for both the cyber event and what’s physically happening on the plant floor. This means bringing operations, cybersecurity and functional safety into the conversation before a new technology is deployed in a critical, physical environment.
Teams should map what the system connects to, what it controls and what the operational impact would be if it failed or behaved unexpectedly. They should also decide in advance when a system needs to be restricted, stopped or shifted into a safe operating mode, rather than figuring that out during an incident.
When those responsibilities and thresholds are established early, manufacturers are in a much better position to adopt new technology without introducing unnecessary operational risk.
