In a nuclear plant, software sits close to equipment that moves, measures and protects. A flawed update or dependency could change how a device behaves, so supply chain security there has to be reviewed with safety engineering. The aim is a change process that treats code provenance as a safety input.
This is a calm explainer. We describe no incident, plant or regulator ruling, and we did not read nuclear regulations for this post. Check your national regulator for binding requirements.
Where does the software supply chain touch the physical process?
Think of a chain with four links. A supplier writes firmware and libraries. An integrator packages them into a system. The plant installs and configures the system. The system then reads sensors and drives actuators.
Any link can introduce a weakness: an unmaintained library, a build server that signs the wrong artifact, a vendor laptop with outdated tools, an update delivered over an uncontrolled path. In a business application the result is usually data loss or downtime. In operational technology the system interacts with the physical environment.
NIST's SP 800-82 Revision 3 says its guidance on operational technology security must address unique performance, reliability and safety requirements. It describes OT as programmable systems and devices that detect or cause a direct change through monitoring or control of devices, processes and events. That definition is the bridge from code to consequence.
Why is the usual playbook not enough?
IT practice says patch fast. OT practice says patch carefully. A device in a safety function may need testing, vendor approval and an outage window before any change. NIST's guide exists in part because ordinary IT controls can conflict with availability and safety needs.
The ISA/IEC 62443 series, as titled on ISA's page, gives shape to shared responsibility. Part 3-2 addresses security risk assessment for system design, and Part 3-3 covers system security requirements and security levels. Part 4-1 sets secure product development lifecycle requirements for suppliers and Part 4-2 technical requirements for components. Part 2-3 is a technical report on patch management. We read titles, not clauses, so read the standards before building contracts on them.
What does a defensible approach look like?
Defense in depth. Do not rely on one control. Network segmentation, strict access, change control and monitoring each reduce the chance that a bad component becomes a bad physical outcome.
Provenance as an input. Before a firmware or software change, know where it came from, how it was verified and what it contains. An SBOM supports that last point. CISA describes it as a nested inventory of the ingredients in software components.
Separate the decision. Security finds the weakness. Engineering judges the safety impact. Operations schedules the change. One group should not carry all three decisions.
Test off line. Apply updates to a non-production unit first and observe behavior.
Plan the unpatchable. Some systems will stay on old versions for years. For these, document the exposure and compensating controls and review them on a schedule.
What should a supplier conversation include?
Ask for a component list per release, how vulnerabilities in those components are tracked and communicated, how builds are protected and signed, and how long a version is supported. Ask how updates are delivered and verified on arrival. Record the answers and revisit them at renewal.
What to do
- Map which systems perform or support safety functions and which only support operations.
- For each, list suppliers, integrators and update paths, including maintenance laptops.
- Require component lists and advisory notification in supplier agreements.
- Verify integrity of every update before it reaches the plant network.
- Create a joint security and safety review for any change to firmware or control software.
- Test changes on a non-production unit and record the behavior observed.
- Document compensating controls for systems that cannot be patched, with an owner.
- Rehearse a vendor advisory drill once a year and note what slowed you down.
Quick check
Why not just patch quickly like an office system?
Because a change to a device in a safety function can alter behavior. NIST's OT guidance stresses performance, reliability and safety requirements, so changes go through testing and review.
What does an SBOM add here?
It tells you which software components a device contains, so you can check advisories against it and judge whether you are affected.
Sources
- NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, fetched 18 October 2026
- ISA/IEC 62443 series of standards, ISA, fetched 18 October 2026
- Industrial Control Systems, CISA, fetched 18 October 2026
- Software Bill of Materials (SBOM), CISA, fetched 18 October 2026
Last reviewed: 18 October 2026.
