In a nuclear plant, a vulnerable dependency is judged by what the affected system does, not by its score alone. A library flaw in a maintenance laptop is a different problem from one in equipment tied to a safety function. The practical response is inventory, vendor transparency, strict change control and isolation.
Why is this different from an office network?
The US Nuclear Regulatory Commission rule at 10 CFR 73.54 asks licensees to protect digital computer and communication systems against cyber attacks up to the design basis threat. The associated NRC guidance describes covering safety, security and emergency preparedness functions, plus support systems whose compromise could affect them.
The rule asks for a cyber security program that identifies the assets needing protection, applies defense in depth to critical digital assets and integrates with physical protection. NRC Regulatory Guide 5.71 describes one acceptable way to comply, and licensees may use other methods that meet the rule. We summarise from the eCFR page and search summaries here. The eCFR page says it is not an official legal edition, so use the official text for legal purposes.
What does a dependency look like on the shop floor?
Think of the places software shows up during maintenance. A diagnostic tool on a technician's laptop. A vendor update utility. A calibration application. A data historian. Each is built from open source and commercial libraries, and each is a path into a protected system when plugged into it.
The risk in a maintenance setting often comes from the movement of media and laptops between zones, not from an internet connection. A vulnerable parser in a tool that reads files from a vendor can matter even in a network with no outside path, if a malicious file arrives on a USB stick.
How should a vulnerable library be scored here?
Ask three plant questions before reading the CVSS number.
- What function does the system serve, and is it classified as a critical digital asset?
- Can the vulnerable code be reached by anything that is not already trusted, including files and removable media?
- What does a change to the system cost, in re-qualification and downtime?
A medium severity flaw in a system that touches a protected function may deserve more attention than a critical one in an isolated training tool. The score is an input, not a verdict.
Why is patching not the default answer?
Plant systems often need re-qualification after a change. An upgrade can be more disruptive than the exposure it removes. That makes compensating controls important: isolation, allow listing, removal of unused features and monitoring. NIST SP 800-82 Rev. 3 frames OT security around that tension between security and the performance, reliability and safety needs of the system.
What to do
- Build an inventory of digital assets and the software on them, including maintenance laptops and vendor utilities.
- Ask suppliers for an SBOM for each tool and for their process to tell you about new vulnerabilities.
- Record, for each system, whether a flaw in a given library is reachable from files, media or the network.
- Control what enters protected zones: scan media, use dedicated maintenance devices and log their use.
- Where patching needs re-qualification, write down the compensating control and the date you will revisit it.
- Map your approach to the rule and guidance that apply to you, with your regulatory staff.
Quick check
Does a software bill of materials help in a plant?
Yes, as an inventory. CISA describes an SBOM as a list of the ingredients that make up software, which lets you ask which systems contain a newly disclosed library.
Is this advice a compliance program?
No. It is general guidance. Your obligations come from the regulator and your licence.
Sources
Last reviewed: 18 October 2026.
