Wind farm security: what should defenders inspect first?

At a wind site, inspect five things first: what sits on the control network, every remote access path, the laptops and USB drives technicians carry up the tower, the firmware and software inventory of each turbine, and whether safety systems are separate from the data network. Standards such as NIST SP 800-82 and ISA/IEC 62443 give the structure.

Why is a wind site different from an office?

Operational technology has to stay safe and available first. NIST describes this in its Guide to Operational Technology Security (SP 800-82 Rev. 3, September 2023): OT systems have performance, reliability and safety needs that set them apart from standard IT. A patch window may be a calm day and a crane, not a Tuesday night.

Wind is also spread out. Turbines sit across wide areas, and the people who maintain them travel between sites. CISA's energy sector page calls the sector "uniquely critical" because it enables every other critical infrastructure sector, and notes that wind, solar and geothermal together make up about 3 percent of US electricity. It says nothing specific about wind security risks, and neither do we claim any incident here.

What to inspect, in order

1. The network map. Can you list every device in the turbine, the substation and the operations center, and how they connect? ISA/IEC 62443 is a series of standards for industrial automation and control systems, and its Part 3-2 covers security risk assessment for system design. A drawing that nobody has checked against the real network is the first finding.

2. Remote access. Vendors, operators and monitoring centers connect in. List each path, who owns it, whether it uses multi-factor authentication, and whether it can be switched off. Unknown paths matter more than weak ones.

3. Maintenance laptops and removable media. Technicians climb with a laptop or a USB stick and plug into a turbine controller. Ask what is on those devices, who updates them and how a drive is checked before use. This is a process question, not a technology purchase.

4. Firmware and software inventory. For each controller, record the vendor, version and open source components inside. Ask suppliers for a software bill of materials. ISA/IEC 62443 Part 4-1 covers secure development lifecycle requirements for product suppliers, so it is fair to ask suppliers how they handle vulnerable components. Part 2-3 is a technical report on patch management in these environments.

5. Safety separation. Confirm that emergency stop and protection functions work without the data network. A cyber incident should degrade monitoring, not safety.

How does a vulnerable dependency reach a turbine?

A controller image may include a library that has a published vulnerability. The question is not whether the library exists, but whether the vulnerable code is reachable and exposed. If you receive an SBOM from a supplier, the Safeguard CLI (@safeguard-sh/cli) can generate and scan SBOMs, and reachability analysis helps separate findings that can actually be hit from those that cannot. Your supplier's advisory still decides the fix, since you usually cannot patch a controller yourself.

What to do

1. Draw the network from what you observe, not from old diagrams.
2. List and rank remote access paths, and close the unowned ones.
3. Set rules for technician laptops and removable media.
4. Request SBOMs and patch policies from each controller supplier.
5. Test that safety functions work with the data network disconnected.
6. Map your program to ISA/IEC 62443 roles: asset owner, integrator, supplier.

Quick check

Sources

• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security, fetched 18 October 2026
• ISA/IEC 62443 series overview, fetched 18 October 2026
• CISA energy sector, fetched 18 October 2026

Last reviewed: 18 October 2026.