CIP-007 system security management: what generator owners need to know

CIP-007 is the standard most people picture when they think of NERC CIP day to day: closing ports, tracking patches, keeping malware protection current, reviewing logs and managing passwords. It is also the standard that produces a steady flow of evidence, because most of its parts run on a clock.

For solar, wind and battery storage owners, there is an earlier question to answer first: does CIP-007 apply to you at all?

Who CIP-007 applies to

CIP-007-6 lists Generator Owners and Generator Operators among its functional entities. But section 4.2.3.5 exempts "Responsible Entities that identify that they have no BES Cyber Systems categorized as high impact or medium impact according to the CIP-002-5.1 identification and categorization processes."

In plain terms: if every BES Cyber System you own is low impact, CIP-007 does not apply to you, and your cyber security obligations for those systems sit in CIP-003 (the low impact plan). If you have even one medium or high impact BES Cyber System, CIP-007 applies to that system and to its associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS) and Protected Cyber Assets (PCA).

So the answer depends on your CIP-002 categorization. A single low impact solar plant is outside CIP-007. A fleet operator whose control center is rated medium impact is inside it, for that control center. Our post on low and medium impact ratings walks through where a site usually lands.

Not every part applies to every medium impact system

CIP-007-6 is written as five tables, and each row has an "Applicable Systems" column. Some rows apply to all medium impact systems; others only to medium impact systems with External Routable Connectivity (ERC), or only to those at Control Centers. Reading that column is the first step in scoping the work. For medium impact systems:

• 1.1 Enable only needed logical ports: with ERC.
• 1.2 Protect unneeded physical ports: at Control Centers.
• 2.1 to 2.4 Patch management: all medium impact.
• 3.1 to 3.3 Malicious code prevention: all medium impact.
• 4.1 Log security events: all medium impact. 4.2 Alerts: with ERC. 4.3 Keep logs 90 days: at Control Centers. 4.4 Review logs every 15 days: high impact only.
• 5.1 Enforce authentication: at Control Centers, or with ERC.
• 5.2, 5.4 and 5.5 Generic accounts, default passwords, password rules: all medium impact.
• 5.3 and 5.6 Shared account users, password changes: with ERC.
• 5.7 Limit or alert on failed logins: at Control Centers.

R1: Ports and services

Part 1.1 asks you to enable only the logical network ports you have decided you need, where technically feasible. The standard is practical about embedded devices: "If a device has no provision for disabling or restricting logical ports on the device then those ports that are open are deemed needed." The guidance is also clear that the control belongs on the device: "Blocking ports at the ESP border does not substitute for this device level requirement."

Part 1.2 covers physical ports (network, serial, USB) and accepts protections ranging from configuration to port locks or signage.

Typical evidence: a list of listening ports per device or device type, with a reason for each.

R2: Security patch management

This is the part with the tightest clock:

• 2.1 Have a process for tracking, evaluating and installing cyber security patches, including the sources you monitor for each updateable Cyber Asset.
• 2.2 At least once every 35 calendar days, evaluate patches released since the last evaluation for applicability.
• 2.3 Within 35 calendar days of finishing that evaluation, for each applicable patch, either apply it, create a dated mitigation plan, or revise an existing one.
• 2.4 Carry out each mitigation plan in the timeframe it states, unless the CIP Senior Manager or delegate approves a revision or extension.

Two points matter at generation sites. First, R2 is not an "install every patch" rule: the guidance says the main intention is to "be aware of in a timely manner and manage all known vulnerabilities," and a mitigation plan is a valid outcome when patching a running system carries more risk. Second, the source is often not the operating system vendor alone. Inverter, controller and SCADA vendors frequently qualify patches before you can apply them, and your process should name them as sources.

Typical evidence: the list of patch sources, a dated record of each 35-day evaluation, and installation records or dated mitigation plans.

R3: Malicious code prevention

• 3.1 Deploy methods to deter, detect or prevent malicious code.
• 3.2 Mitigate the threat of detected malicious code.
• 3.3 Where methods use signatures or patterns, have a process for updating them that covers testing and installing.

The standard does not prescribe antivirus. The guidance names antivirus, white-listing, network isolation and intrusion detection or prevention as options, and notes that a Cyber Asset with no updateable software, whose executing code cannot be altered, is considered to have its own internal method of deterring malicious code.

R4: Security event monitoring

• 4.1 Log events, per system or device capability, including at minimum successful logins, failed access and login attempts, and detected malicious code.
• 4.2 Generate alerts for, at minimum, detected malicious code and a detected failure of event logging.
• 4.3 Where technically feasible, keep those logs for at least the last 90 consecutive calendar days.
• 4.4 Review a summary or sample of logged events at intervals of no more than 15 calendar days (high impact only).

If a device does not have the capability of logging a given event, the guidance says the entity remains compliant for that event. The work is in documenting what each device can log and showing it is configured to do so.

R5: System access control

• 5.1 Enforce authentication of interactive user access, where technically feasible.
• 5.2 Identify and inventory known enabled default or other generic account types.
• 5.3 Identify the individuals with authorized access to shared accounts.
• 5.4 Change known default passwords, per Cyber Asset capability.
• 5.5 For password-only authentication, enforce a minimum length (the lesser of eight characters or the device maximum) and complexity (the lesser of three character types or the device maximum).
• 5.6 For password-only authentication, enforce a password change at least once every 15 calendar months, where technically feasible.
• 5.7 Either limit unsuccessful authentication attempts or alert after a threshold, where technically feasible.

Field devices with shared or fixed accounts are common at renewable sites, which is why 5.2 and 5.3 deserve early attention.

How long to keep the evidence

CIP-007-6 asks each Responsible Entity to keep evidence of each requirement for three calendar years, unless its Compliance Enforcement Authority directs it to keep evidence longer. Where that period is shorter than the time since the last audit, the CEA may ask for other evidence covering the full period. In practice, the 35-day patch cycle and the 15-month password cycle both need a record that holds together over years, not weeks.

Which version is in effect

CIP-007-6 is the version in effect today. In March 2026, FERC Order No. 919 approved NERC's virtualization revisions to the CIP standards, which take effect about two years after the order. We will update this post when they do.

Where to start

• Confirm your CIP-002 categorization. If nothing is medium or high impact, CIP-007 does not apply.
• For each medium impact system, write down whether it has ERC and whether it sits at a Control Center. That decides which parts apply.
• List patch sources per device type, including the control system vendors.
• Record what each device can log, and where those logs go.
• Inventory generic, default and shared accounts.