CIP-010 configuration change management for renewable sites: baselines, changes and monitoring

CIP-010 is the standard that asks: do you know what your systems should look like, did anyone change them without approval, and how would you find out? CIP-010-4, the version in force in the US, answers with baselines, change authorization, configuration monitoring and vulnerability assessments.

This post covers what each requirement asks, and how it lands at solar, wind and battery storage operations.

First: does CIP-010 apply to you?

CIP-010 is written for high and medium impact BES Cyber Systems and their associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS) and Protected Cyber Assets (PCA). Which of these each part covers is set out in its applicability column, so check every part.

Low impact BES Cyber Systems are not under CIP-010. Most individual solar, wind and battery plants that are BES facilities rate low impact under CIP-002, and their program is CIP-003-9. There, the closest topics are Attachment 1 Section 5 (transient cyber assets and removable media) and Section 3 (electronic access controls). Category 2 inverter-based resources are not BES facilities and are not under CIP at all.

Where renewable operators do meet CIP-010 is usually the control room. A Control Center that performs Generator Operator functions for 1,500 MW or more in a single Interconnection is medium impact under CIP-002 criterion 2.11, even when every site it runs is low impact.

R1.1: The baseline

Part 1.1 asks you to develop a baseline configuration, individually or by group, that includes:

• Operating system or firmware, where no independent operating system exists.
• Any commercially available or open-source application software intentionally installed.
• Any custom software installed.
• Any logical network accessible ports.
• Any security patches applied.

In a renewable control room, that typically means the SCADA servers and HMIs, historians, engineering workstations, RTACs, and the firewalls that serve as access points. Group baselines work well for identical HMIs built from the same image, as long as each device really matches the group.

R1.2 to R1.6: Changing a device the documented way

The rest of R1 describes what happens around a change that deviates from the baseline:

• Part 1.2: authorize and document changes that deviate from the existing baseline configuration.
• Part 1.4: before the change, determine which required CIP-005 and CIP-007 controls it could affect; after the change, verify those controls are not adversely affected, and document the result.
• Part 1.5: where technically feasible, test the change before production, either in a test environment or in production in a manner that minimizes adverse effects.
• Part 1.6: before a change to the operating system or firmware, commercially available or open-source software, or security patches in the baseline, verify the identity of the software source and the integrity of the software, when the source makes a method available.
• Part 1.3: update the baseline as necessary within 30 calendar days of completing the change.

Vendor visits are where this tends to break down at generation sites. An inverter or controller firmware update done during an outage is still a baseline change. The authorization, the CIP-005 and CIP-007 check and the integrity verification all need to exist before the work starts, not be written up afterwards.

Part 1.6 only applies when the software source offers a way to verify. A vendor that publishes signed packages or file hashes gives you that method; record which one you used and the result.

R2.1: Monitoring every 35 days

Part 2.1 asks you to monitor for changes to the baseline configuration at least once every 35 calendar days, and to document and investigate any unauthorized changes you detect. In CIP-010-4 this part applies to high impact BES Cyber Systems and their associated EACMS and PCA, so a medium impact control room is not held to it.

Comparing live configuration with the approved baseline on a schedule is still sound practice at any impact level. It is how you find the emergency fix nobody wrote down.

R3: Vulnerability assessments

• Part 3.1: at least once every 15 calendar months, conduct a paper or active vulnerability assessment.
• Part 3.2: where technically feasible, at least once every 36 calendar months, perform an active assessment in a test environment that models the production baseline, or in production in a manner that minimizes adverse effects. This part applies to high impact BES Cyber Systems.
• Part 3.3: before adding a new applicable Cyber Asset to production, perform an active vulnerability assessment of it, except for CIP Exceptional Circumstances and like replacements whose baseline models an existing one.
• Part 3.4: document the results of those assessments and the action plan to remediate or mitigate what they found, with the planned completion date and the status of each action item.

R4: Transient Cyber Assets and Removable Media

Requirement R4 asks for one or more documented plans for Transient Cyber Assets and Removable Media that include the sections in Attachment 1, for high and medium impact BES Cyber Systems and their associated PCA, except under CIP Exceptional Circumstances. O&M laptops, vendor laptops and USB drives used for firmware and configuration work are the usual examples. Low impact sites cover the same ground under CIP-003-9 Attachment 1 Section 5.

Where automated evidence collection helps

Monitoring is the part of CIP-010 that suits automation best. Read-only collection can compare each device's current state with its baseline, including firmware, software, ports and accounts, and put every difference in front of a person who decides whether to approve it into the baseline. It does not change the device. It also builds a time-ordered record that shows when a change first appeared, which helps when you check the 30-day baseline update.

What it cannot do is the judgment: authorizing the change, deciding which CIP-005 and CIP-007 controls it touches, and verifying the software source. Those remain documented decisions made by people.

Looking ahead

CIP-010-5, part of the virtualization revisions, takes effect on July 1, 2028. Until then, CIP-010-4 is the version you are audited against.