On a car factory floor, a vulnerable dependency is not only a data risk. The same library may sit inside a robot controller, a PLC programming tool or a vision system, where a fix means scheduled downtime and a safety review. Start with an inventory of what runs where.
This post does not describe any specific incident. It explains how published standards frame the problem.
Why is the shop floor different from an office?
NIST SP 800-82 Rev. 3, the guide to operational technology security, says it is about securing OT while accounting for performance, reliability and safety requirements. It covers industrial control systems and related OT, typical topologies, threats and countermeasures. The point is in the first clause: security measures cannot assume you can reboot a system at will.
In an office, patching a library is a ticket. On a line, the same patch may need a maintenance window, vendor approval, and re-validation of a cell that must keep working safely.
Who is responsible for the dependency?
ISA describes the IEC 62443 series as consensus standards for industrial automation and control systems, built on shared responsibility among stakeholders. It names asset owners (the operators), integrators (who build and maintain control solutions) and product suppliers. Service suppliers are named too.
The series has parts for general concepts, policies and procedures (including patch management and asset owner programs), system requirements and security levels, and component requirements including a secure product development lifecycle.
For a vulnerable dependency, this splits the question. The supplier owns knowing what is inside the product and issuing fixes. The integrator owns how the product is assembled into a cell. The plant owns the patching policy and the risk decision. If any of the three has no component list, nobody can answer "are we affected?"
What changes with robots?
ISO 10218 covers safety requirements for industrial robots. Trade and testing sources report that the 2025 revision added cybersecurity requirements for the first time, scoped to how they affect robot safety, though sources differ on the exact publication dates and we did not retrieve the standard's clauses. Read the standard itself before relying on any detail.
The takeaway is directional: robot safety and cybersecurity are now discussed together. A flaw that lets someone alter a robot's behavior is a safety concern, not only an IT one.
What does a dependency look like in practice?
A few examples of where open source code can hide in plant systems, described generally:
- Engineering workstations that run programming and diagnostic tools.
- Gateways that translate between plant protocols and IT networks.
- Edge computers that run vision or analytics software.
- Vendor remote support tools.
None of these claims is a report of an incident. They are the places to look when you build an inventory.
What can you do without stopping production?
Start passive. An inventory does not touch a running cell. Ask suppliers for software bills of materials for what they ship. Compare those lists against known-exploited vulnerability lists. Then decide, per system, whether to patch, isolate or accept the risk with compensating controls, which is where network segmentation helps.
Reachability matters here as well. A vulnerable function that the product never calls is a lower priority than one on a network-facing service, and a supplier statement saying so is worth requesting in writing.
What to do
- List every software-bearing system in one area of the plant, with owner and supplier.
- Request SBOMs from suppliers, and record who could not provide one.
- Check the lists against known-exploited vulnerability data.
- Map which systems face the IT network or remote vendors.
- Agree a patching and isolation policy with operations, so security does not hold a surprise.
- Read the patch management and asset owner parts of IEC 62443 with your integrators.
- Review your robot cells against the current ISO 10218 text.
Quick check
Is a vulnerable library in a plant always urgent?
No. Urgency depends on whether the code is reachable, whether the system faces a network, and what an attacker could change. Safety and uptime constraints also shape the fix.
Who should hold the component list?
The product supplier creates it. The integrator and plant should keep a copy per installed system so they can answer exposure questions fast.
Sources
- NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
- ISA: ISA/IEC 62443 series of standards
- Control Design: ISO 10218 update makes functional-safety requirements more explicit
- TUV: robotics standard update alert
Last reviewed: 18 October 2026.
