What a vulnerable dependency means for electrical utility field work

For an electrical utility, a vulnerable dependency is a flaw in software that touches operating technology: engineering laptops, configuration tools, protection and control devices, and the links between them. It matters on the shop floor because those systems affect physical equipment. Standards such as NIST SP 800-82 and ISA/IEC 62443 give a shared way to manage it.

Why is this different from office IT?

NIST describes operational technology as programmable systems and devices that interact with the physical environment, and says its guide addresses their unique performance, reliability and safety requirements. Examples named include industrial control systems, building automation and physical access control. A patch on a laptop is a Tuesday chore. A patch on a device that switches power can need an outage window, a rollback plan and a crew on site.

CISA lists energy as a sector that supports nearly every other, and notes most of its infrastructure is privately owned. That makes the supplier chain long: product makers, integrators, service contractors and the utility itself.

Where do dependencies hide?

Look at the places software enters the field.

• Engineering and configuration tools. A real CISA advisory (ICSA-16-056-01) describes a memory error in a vendor's design software. A crafted project file could run code with the user's privileges. The advisory says it was not remotely exploitable and needed a local user to open the file. The advice was to update, avoid untrusted project files and run as a standard user. Notice that the risk lived in a file a technician might receive by email or USB.
• Device firmware. Components bundle open source libraries. You rarely see them unless the supplier gives you a software bill of materials.
• Remote access. After the 2015 attack on Ukrainian distribution companies, CISA's alert recommended limited, operator-controlled, time-limited remote access and no persistent vendor connections into control networks.
• Vendor laptops. Contractors bring their own tools onto your network.

What do the standards ask for?

ISA describes the 62443 series as requirements for securing industrial automation and control systems, built on shared responsibility. It speaks to asset owners, product suppliers, integrators and service providers. Part 2-3 covers patch management, and Part 4-1 covers the secure product development lifecycle for suppliers. Part 3-3 covers system security requirements and security levels.

In practice, that means an asset owner asks suppliers how they track the components inside a product, and a supplier can show an answer. NIST SP 800-82 Revision 3, published in September 2023, covers OT topology, threats and countermeasures, and an initial public draft of Revision 4 is open for comment until 30 November 2026.

What should crews and leads ask?

1. Which software runs on the devices and tools we use in the field, and who maintains it?
2. Do our suppliers publish a bill of materials and a patch schedule?
3. Where can we test an update before it reaches a live substation or plant?
4. Who may connect remotely, for how long, and how is it logged?
5. What do we do if the control system cannot be trusted? The Ukraine alert advises planning for safe operation or shutdown on that assumption.

What to do

1. Inventory field tools, laptops and devices with their software versions.
2. Ask each supplier for a component list and a patch policy in writing.
3. Block untrusted project files and removable media on engineering laptops.
4. Separate control networks from business networks and the internet.
5. Time-limit and log every remote session.
6. Rehearse a manual operating plan.

Quick check

Sources

• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• ISA/IEC 62443 series of standards
• CISA ICSA-16-056-01 advisory
• CISA alert on the December 2015 Ukraine power distribution attack
• CISA Energy Sector overview

Last reviewed: 18 October 2026.