Electric Utility Cybersecurity Programme Guide: Building a grid security programme beyond NERC CIP

Electric utilities that run their security programme as a compliance exercise end up protecting the audited assets and leaving the paths attackers actually use: corporate IT, distribution automation, field devices and vendor connections. A utility spans generation, transmission, distribution and retail, and each of those has different assets, protocols and regulators. NERC CIP in North America and the EU network code on cybersecurity for electricity set floors, but they apply to defined perimeters, and the Ukraine grid attacks showed that disruption can start in the business network and end with breakers opened from the operator's own SCADA. This guide sets out how to build a utility-wide programme: scoping by function, threats specific to the grid, the control set by asset class, monitoring, response with manual operation, and the metrics that show progress. It is written for utility CISOs, OT security leads and the engineers who run control centres and substations.

Key takeaways

• Scope by grid function, not by audit perimeter. Map generation, transmission, distribution, control centres, AMI and DER separately, then apply regulation on top; a single programme with function-specific baselines beats separate compliance silos.
• Assume the attack starts in IT. Volt Typhoon pre-positioning and the 2015 Ukraine attack both used valid accounts and remote access from the business network; the IT to OT boundary is the most important control point you own.
• Distribution is the growing attack surface. Distribution automation, AMI head-ends, substation gateways and DER aggregation connect thousands of field devices that sit outside most high-impact perimeters.
• Monitor inside the perimeter, not only at it. CIP-015-1 now requires internal network security monitoring for high impact and medium impact systems with External Routable Connectivity; extend the same visibility to distribution where risk justifies it.
• Response means running the grid without the computers. Plans must cover manual switching, field crews, loss of telephony and rebuilding bricked gateways, and they must be rehearsed with operations, not only with the SOC.

Scoping the programme across the value chain

Start with an inventory of grid functions and the systems that deliver them. Each function has different consequences, different attack surfaces and, often, a different regulator. The table is a starting map, not an exhaustive list.

Two scoping rules prevent most gaps. First, every system that can send a command to the grid, or that holds credentials for one that can, is in scope, wherever it sits on the network diagram. Second, regulation is a property attached to a system, not the definition of the programme: a medium impact substation under CIP and an unregulated distribution substation should share the same baseline, with extra evidence for the audited one. See the OT Security Guide for the general OT model this builds on.

Regulation and frameworks a utility programme must absorb

• NERC CIP (North America): mandatory standards CIP-002 to CIP-015 for the Bulk Electric System, with impact categorisation under CIP-002 driving which requirements apply. CIP-003-9 strengthens low impact obligations, including vendor electronic remote access, and CIP-015-1 adds internal network security monitoring. Penalties under section 215 of the Federal Power Act can reach USD 1 million per violation per day, adjusted for inflation. See the NERC CIP Guide for requirement-level detail.
• EU network code on cybersecurity: Commission Delegated Regulation (EU) 2024/1366 sets sector-specific rules for cross-border electricity flows. Competent authorities identify high-impact and critical-impact entities (Article 24, notification no later than 13 June 2028); high-impact entities apply minimum controls inside a high-impact perimeter and critical-impact entities apply advanced controls inside a critical-impact perimeter (Articles 28 and 29). Entities repeat their risk assessment every three years, build a cybersecurity management system within 24 months of notification (Article 32), and critical-impact entities must verify compliance at least every three years (Article 31).
• NIS2: electricity undertakings, DSOs and TSOs are in scope of Directive (EU) 2022/2555. Recital 15 of the network code allows NIS2 authorities to treat compliance with its risk management requirements as meeting the corresponding NIS2 requirements, and the reverse. See the NIS2 Directive Guide.
• DOE C2M2: the Cybersecurity Capability Maturity Model, version 2.1 (June 2022), is a free self-evaluation tool with maturity indicator levels MIL1 (Initiated) to MIL3 (Managed) across ten domains. It is the most common way utilities benchmark the programme as a whole rather than one perimeter.
• Engineering guidance: NIST SP 800-82 Rev. 3 (Guide to OT Security, September 2023; a Rev. 4 initial public draft is open for comment until 30 November 2026), NISTIR 7628 Rev. 1 (Guidelines for Smart Grid Cybersecurity, three volumes), ISA/IEC 62443 for zones, conduits and product security, and IEC 62351 for securing power system protocols. See the IEC 62443 Guide and the IEC 62351 Guide.

Small cooperatives and municipal utilities with only low impact assets often have few mandatory requirements beyond CIP-003. For them C2M2 at MIL1 across all domains, plus the five CISA primary mitigations below, is a realistic first target. Large vertically integrated utilities should run C2M2 per function, because a single score hides weak distribution practices behind a strong control centre.

Grid threats and what they teach

The public record of attacks on electric utilities is small but unusually detailed, and every case points at a control a programme can test. MITRE ATT&CK for ICS documents three Sandworm Team (G0034) campaigns against Ukraine.

Ransomware is the more frequent threat in practice, and it usually reaches operations indirectly. The Colonial Pipeline ransomware attack started with a legacy VPN profile that had no MFA, and the six-day pipeline shutdown was a precautionary containment decision rather than a direct OT compromise. Utilities face the same choice when billing, outage management or the historian is encrypted, which is why dependency mapping belongs in the programme. See the Sandworm Threat Actor Profile and Volt Typhoon Threat Actor Profile.

Control baseline by asset class

CISA, FBI, EPA and DOE publish five primary mitigations for OT: take OT devices off the public internet, replace default passwords, secure remote access with phishing-resistant MFA and least privilege, segment IT and OT, and keep the ability to operate manually with tested backups. Treat those as the floor everywhere, then add the asset-specific controls below.

Control centres (EMS, SCADA, ADMS)

• Dedicated OT domain: a separate Active Directory forest or local accounts for control centre systems, with no trust to the corporate forest, so a stolen corporate domain database does not open the EMS.
• Application allowlisting: SCADA servers and operator consoles run a fixed software set; remote support tools are removed rather than disabled.
• Command safeguards: use the SCADA platform's own controls (select-before-operate, operator area of responsibility, two-person rules for mass operations) and alert on bulk switching commands.
• Backup control centre: independent credentials and rebuild media, tested by failing over, not by reviewing documents.

Substations and field devices

• Device credentials: unique passwords per relay, RTU and gateway, held in a vault, with role-based access where the device supports it; default and shared maintenance passwords are the most common audit finding.
• Protocol security where supported: DNP3 Secure Authentication and IEC 62351 profiles (TLS for IEC 60870-5-104 and MMS, authentication for GOOSE) on new builds; for legacy devices, compensate with encrypted backhaul and strict conduit rules. See the DNP3 Secure Authentication Guide and IEC 61850 Substation Security Guide.
• Setting and firmware integrity: keep approved relay settings and firmware versions under configuration management, compare them on a schedule, and hold spare gateways and converters with known-good images.
• Physical and transient access: engineering laptops and USB media that enter substations are a conduit; issue managed transient devices and scan media at the gate.

Distribution, AMI and DER

• Field network segmentation: separate feeder automation, AMI backhaul and corporate mobile traffic; private APNs or encrypted tunnels over public cellular networks.
• Head-end command limits: cap the number of remote disconnects or setpoint changes per period without a second approval, so one compromised account cannot switch off a city.
• DER and aggregators: put security requirements into interconnection agreements and aggregator contracts, and monitor aggregate commands. See the Distributed Energy Resources and Solar Inverter Security Guide.

Where identity fits

Valid accounts appear in every Ukraine campaign and in Volt Typhoon, so identity is a grid control, not an IT topic. The programme decisions are: a separate OT identity plane, brokered and recorded vendor access that is off by default, vaulted device passwords, and fast removal of leavers and contractors. Machine identities matter as much as people: historian replication accounts, ICCP and SCADA service accounts, AMI head-end integration credentials and DER platform API keys often have broad rights and never expire. The Energy Sector Identity and OT Access Guide covers these controls in depth, including access for remote unstaffed sites; the OT Remote Access Guide covers the broker architecture.

Monitoring and detection

CIP-015-1 is the clearest statement of what internal monitoring should do. Requirement R1 asks for network data feeds chosen on a risk-based rationale (R1.1), one or more methods to detect anomalous activity (R1.2) and methods to evaluate anomalies and decide on action, including escalation into CIP-008 incident response (R1.3). R2 requires retention of data related to anomalous activity until that evaluation is complete, and R3 requires protection of the monitoring data against unauthorised deletion or modification. These are sound design rules for any utility network, regulated or not.

Route OT detections to a team that understands operations. Analysts must be able to call the control room, and control room staff must know what a security alert means for switching decisions. See the OT Network Security Monitoring Guide.

Response, recovery and manual operation

1. Define the safe states: for each function, agree with operations what "isolate" means (cut the IT to OT link, drop vendor access, move to the backup control centre) and who can order it.
2. Plan for manual operation: crews dispatched to substations, paper switching orders, radio or satellite communications if telephony is lost; measure how long the utility can operate in this mode.
3. Hold rebuild assets: offline images of SCADA servers and HMIs, configuration backups for relays and gateways, spare hardware for converters likely to be bricked.
4. Preserve evidence: capture network traffic and host images before rebuild where safety allows; CIP-008 and NIS2 both carry reporting obligations with short clocks.
5. Exercise jointly: run at least one exercise a year that includes control room operators, field crews, the SOC and communications staff, using a scenario drawn from the table above.

See the OT Incident Response Guide and the OT Ransomware Response Playbook.

Implementing the programme

1. Months 0 to 3, visibility: build the function map and asset inventory, list every IT to OT path and every vendor connection, and run a C2M2 self-evaluation per function to set a baseline.
2. Months 3 to 9, close the doors: remove internet exposure, enforce MFA on all OT remote access, rotate default and shared device passwords, and move vendor sessions behind a broker. Test changes on a lab or backup system first, deploy during planned outages, and keep a documented rollback (previous firewall rule set, previous device configuration) for each change.
3. Months 6 to 12, separate and monitor: implement default-deny conduits between zones, stand up passive OT monitoring at control centres and priority substations in alert-only mode, then tune before using it for response.
4. Months 9 to 18, harden and recover: application allowlisting on SCADA hosts (audit mode first, enforce after a full operating cycle), configuration management for relay settings and firmware, offline backups and a rehearsed rebuild.
5. Ongoing, extend to distribution: apply the substation baseline to unregulated distribution assets, add head-end command limits and DER contract clauses, and re-run C2M2 annually.

Large utilities should give each business unit an OT security lead reporting to one programme owner, with shared tooling. Small utilities can buy monitoring and response as a managed service, but must keep the asset inventory, vendor access approvals and the decision to isolate in house.

Framework mapping

Detection and measurement: programme metrics

• IT to OT path coverage: percentage of known IT to OT and vendor paths that are brokered, MFA-protected and logged (target 100 percent).
• Default credential exposure: number of field devices with default or shared passwords, trended monthly by function.
• Monitoring coverage: percentage of control centres and substations (by load served, not count) with passive OT monitoring feeding a staffed team.
• Configuration drift: relay and controller configurations that differ from the approved baseline, and time to explain or correct them.
• Manual operation readiness: hours the utility can run in manual mode in the last exercise, and time to restore a SCADA host from offline media.
• C2M2 progress: MIL achieved per domain per function, year on year.

Common failure patterns

• Compliance perimeter as programme boundary: high impact control centres are hardened while distribution substations, AMI and the corporate domain that reaches them are left to IT.
• Corporate identity trusted in OT: a domain trust or shared jump host lets corporate credentials reach SCADA, the exact path used in 2015.
• Remote tools on operator consoles: helpdesk or vendor remote control software on HMIs gives an intruder the operator's screen.
• Forgotten legacy access: dormant VPN profiles, dial-up modems at substations and vendor accounts left enabled between visits, as in the Colonial Pipeline ransomware attack.
• Monitoring nobody can act on: OT sensors deployed with alerts routed to an IT SOC that cannot interpret function codes or contact the control room.
• Untested manual operation: plans assume crews and paper procedures that have not been exercised, so the outage lasts as long as the IT rebuild.

Practitioner checklist

• Map every grid function to its systems, regulator and owner, and run C2M2 per function.
• List every IT to OT and vendor path; close, broker or enforce phishing-resistant MFA on each.
• Separate OT identity from the corporate forest and vault every field device password.
• Remove remote control and helpdesk tools from HMIs and SCADA servers.
• Implement default-deny conduits between corporate, control centre, substation and field networks.
• Deploy internal OT monitoring to CIP-015-1 design rules (risk-based feeds, detection, evaluation, protected retention) beyond the regulated scope where risk justifies it.
• Put relay settings and firmware under configuration management and hold spare gateways with known-good images.
• Add command limits and second approval for mass operations in SCADA and AMI head-ends.
• Exercise manual operation and SCADA rebuild with operations at least annually.
• Track the six programme metrics and report them to the board alongside compliance status.

Standards and references

• NERC: CIP-015-1 Cyber Security: Internal Network Security Monitoring
• EUR-Lex: Commission Delegated Regulation (EU) 2024/1366, network code on cybersecurity for cross-border electricity flows
• US Department of Energy: Cybersecurity Capability Maturity Model (C2M2)
• NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
• NIST: IR 7628 Rev. 1 Guidelines for Smart Grid Cybersecurity
• CISA: AA24-038A PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure
• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• MITRE ATT&CK: 2015 Ukraine Electric Power Attack (C0028)

Related NHI Mgmt Group resources: NERC CIP Guide · Energy Sector Identity and OT Access Guide · OT Security Guide · MITRE ATT&CK for ICS Guide · Industroyer and Industroyer2 Malware Guide