Car factories: how software supply chain risk reaches physical safety

In a car factory, software controls robots, conveyors and test rigs, and the vehicles that leave carry software too. A vulnerable component from a supplier can therefore affect worker safety on the line and driver safety later. The remedy is traceability: know each component, who supplies it, and how updates are verified.

Where does software reach physical processes?

Two places, and they need different standards.

The plant. Robot cells, programmable controllers and monitoring systems are operational technology. NIST SP 800-82 Revision 3 defines OT as programmable systems that monitor or control physical processes and lists manufacturing among its sectors. It says securing OT must account for performance, reliability and safety.

The vehicle. Cars are connected computers. Their software comes from many tiers of suppliers.

Which standards matter?

• ISA/IEC 62443 splits duties among asset owners, integrators and product suppliers. Part 4-1 covers a secure product development lifecycle, and part 3-3 covers system security requirements and security levels.
• ISO 10218, the industrial robot safety standard, was updated in 2025 in two parts, one for manufacturers and one for integrators and robot cells. Trade coverage says the update adds cybersecurity measures for industrial robots to the extent that they relate to safety. Read the standard itself for exact requirements.
• UN Regulation 155 is a binding regulation on vehicle cybersecurity. Per an NXP summary, it requires vehicle makers to hold a certified cybersecurity management system, reassessed at least every three years, and to show that supplier related risks are identified and managed. It took effect in Europe on 6 July 2022.
• ISO/SAE 21434 sets cybersecurity engineering baselines for road vehicle electrical and electronic systems across the lifecycle, and explains how to build the management system R155 requires. The same summary says suppliers provide evidence to makers, and that following the standard is a practical way to do it.

Which ones apply to you depends on your role: plant owner, robot integrator, component supplier or vehicle maker. Confirm with the standards bodies and your customers.

How does a supplier flaw travel?

A library flaw in a controller vendor's product reaches every plant that runs it. A flaw in a supplier's firmware reaches every vehicle that carries the part. The party who finds out last is often the one who owns the risk.

Three habits shorten that delay.

1. Bills of materials. Require a software bill of materials for each component, including firmware, in SPDX or CycloneDX, per release.
2. Disclosure channels. Know how each supplier reports vulnerabilities, and how fast.
3. Update verification. Know how updates are signed and checked before they reach a robot cell or a vehicle.

What does a plant owner do when a flaw is announced?

Separate the questions, as in any OT environment. Is the component present? Is the vulnerable code reachable in our configuration? Can we cut exposure without changing software, for example by segmentation? What testing does a change need before it touches a live line? The last one matters, since a rushed patch on a robot cell can create a safety issue of its own.

What to do

1. Inventory every software driven asset on the line, with supplier and firmware version.
2. Put SBOM and disclosure clauses in supplier contracts.
3. Segment line networks from office and internet access.
4. Build a bench test step for firmware and software updates.
5. Map your role against 62443, 10218 and, if you make vehicles or parts, R155 and 21434.
6. Run a drill: a library flaw is announced, and you must say which assets contain it within a day.

Quick check

Sources

• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
• ISA: ISA/IEC 62443 series of standards
• Modern Materials Handling: ISO 10218 updates for 2025
• NXP: the auto industry is taking cybersecurity seriously (UN R155 and ISO/SAE 21434)

Last reviewed: 18 October 2026.