Power line repair: when a software dependency becomes a safety risk

When software controls a physical tool, a flawed or tampered component can affect the safety of the crew and the grid, not just the confidentiality of data. For line repair equipment, treat every software dependency as part of the safety case: know what is inside, who updates it, and what the machine does if it fails.

Why is this different from an office application?

NIST defines operational technology (OT) as programmable systems and devices that monitor or control physical processes. Its guide, SP 800-82 Revision 3, says securing OT must account for performance, reliability and safety requirements, and lists energy among the sectors it covers. Equipment used on energized lines, such as controllers, sensors and remote-operated tools, falls in that frame.

In an office, the standard response to a vulnerable library is to patch quickly. On a machine working near live conductors, a rushed update may change timing, behavior or calibration. The same patch that closes a hole can open a safety question. Both risks are real, and both need an owner.

Where does the software supply chain enter?

A repair machine is built from layers: a vendor's application, open source libraries, an operating system, and firmware on boards and sensors. A vulnerable or malicious component in any layer is inherited by every unit shipped with it.

The ISA/IEC 62443 series sets out roles for this. Asset owners decide the security level their operations need. Integrators build and maintain the solution. Product suppliers develop the products, and part 4-1 of the series addresses a secure product development lifecycle. The page we reviewed stresses shared responsibility across those groups, which means an asset owner cannot assume the supplier handled it, and a supplier cannot assume the owner will ask.

When CISA published its guidance on the Log4j flaw, it told operators of OT and industrial control systems to enumerate vulnerability status against product advisories, keep control systems off the internet, segment them behind firewalls, and apply patches or vendor mitigations after testing. Notice the last phrase: after testing.

What should an asset owner ask a supplier?

• Which third-party and open source components are in this product, and which versions? Request a software bill of materials.
• How do you tell us about a vulnerability in one of them, and how fast?
• How are updates delivered, signed and verified?
• What does the machine do when software fails? Is there a safe state independent of the software?
• Which updates need a recertification or a field test before use?

What does safe patching look like?

Separate three decisions that office teams often merge.

1. Is this vulnerability reachable in our configuration? If the vulnerable code path is not exposed, the urgency drops.
2. Can we reduce exposure without changing the software? Segmentation, disabled services and blocked outbound traffic often buy time.
3. What testing does the update need before it goes near a live job? Bench test first, then a controlled field trial.

What to do

1. Build an inventory of every software-driven tool, with supplier, model and firmware version.
2. Request an SBOM from each supplier, and store it next to the asset record.
3. Subscribe to supplier and CISA advisories for those products.
4. Define a test path for updates, from bench to controlled field use.
5. Put control systems on segmented networks without direct internet access.
6. Write down the safe state for each tool, and test it.

Quick check

Sources

• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
• ISA: ISA/IEC 62443 series of standards
• CISA: Apache Log4j vulnerability guidance, advisory AA21-356A

Last reviewed: 18 October 2026.