Smart Grid Security Guide: Distributed Energy, Substations and Grid Edge

The power grid now runs on software that sits in places a utility does not fully control: rooftop inverters, aggregator clouds, digital substations and vendor remote access paths. Each of those connections can carry a command that opens a breaker or curtails generation, so a cyber weakness at the grid edge becomes a reliability problem, not just a data problem. This guide covers the operational side of the smart grid: distributed energy resources (DER), digital substations built on IEC 61850 and secured with IEC 62351, field and control centre protocols, and the regulatory baselines that apply (NERC CIP in North America, the EU Network Code on Cybersecurity for electricity). It is written for utility OT security teams, DER aggregators and compliance staff; metering and AMI are covered in the Smart Meter Security Guide.

Key takeaways

• Control, not data, is the asset. The worst smart grid outcomes come from unauthorised command messages to breakers, relays and inverters, so integrity and authentication of control traffic matter more than confidentiality.
• The grid edge multiplies the attack surface. Thousands of DER devices managed through vendor and aggregator clouds can be steered by one compromised platform account, which makes fleet management systems as critical as a substation.
• IEC 62351 is how the protocols get secured. It adds TLS profiles, message authentication for GOOSE and Sampled Values, role-based access control and key management to the IEC 61850 and IEC 60870-5 world, but only where devices support it.
• Regulation now expects detection inside the perimeter. NERC CIP-015-1 requires internal network security monitoring for in-scope systems, and the EU Network Code (Regulation (EU) 2024/1366) builds a cyclical risk assessment and control regime for cross-border electricity flows.
• Ukraine showed the playbook. The 2015, 2016 and 2022 attacks on Ukrainian utilities combined IT intrusion, remote access abuse and native grid protocol commands, which is why remote access, protocol monitoring and manual fallback are the first priorities.

What makes the smart grid different

A conventional OT security programme protects a bounded plant. The smart grid adds three properties that change the design.

• Distributed control: decisions that were once made in a control centre are now spread across protection relays, substation automation, distribution management systems (ADMS and DERMS), aggregators and the inverters themselves.
• Hard real time: IEC 61850 GOOSE trip messages and Sampled Values have delivery budgets measured in milliseconds. Controls that add latency, such as deep inspection inline on the process bus, can be unsafe.
• Long lifecycles and mixed estates: a substation may contain relays from several decades, serial links converted to Ethernet, and new digital process bus equipment side by side. Many legacy devices cannot do cryptography at all, so compensating controls carry most of the load.
• Physical consequence at scale: a coordinated change to many small DER units can have a system-level effect even though no single unit matters. NIST IR 7628 Rev. 1, the US reference framework for smart grid cybersecurity, was written around this logical interface view of the grid.

For the general OT programme (asset inventory, zones and conduits, patching under change control) see the OT Security Guide and the IEC 62443 Guide. This page focuses on what is specific to power systems.

Grid domains, protocols and their security options

Most smart grid risk sits on a small number of protocols. The table summarises where each is used and what security it can carry.

Securing digital substations with IEC 61850 and IEC 62351

IEC 62351 is the security series of IEC TC 57, the committee that owns IEC 61850, IEC 60870-5 and the CIM. The IEC webstore lists the series as a set of standards, technical specifications and technical reports, with recent editions including IEC 62351-3:2023, IEC 62351-5:2023, IEC 62351-7:2025 and IEC 62351-8:2026.

In practice, implementation runs in this order:

• Segment first: separate station bus, process bus, engineering access and the WAN conduit, with deny by default rules at the substation gateway. See the Network Segmentation Guide.
• Protect engineering access: the engineering workstation that holds SCL configuration files (SCD, CID) and relay setting tools can reprogram protection. Treat it as a privileged system with named accounts, MFA through an intermediate system and change records.
• Turn on TLS where supported: MMS and IEC 104 links to newer IEDs and gateways, with certificates from an OT PKI rather than self-signed defaults.
• Add RBAC: replace shared IED passwords with IEC 62351-8 roles or central authentication where the vendor supports it; at minimum, unique per device credentials held in a vault.
• Authenticate GOOSE and SV selectively: pilot IEC 62351-6 on new bays, measure added latency against the protection scheme, and keep unauthenticated legacy bays on isolated VLANs with monitoring.

Certificates and group keys need an owner: expiry on a substation device is an outage risk, so lifecycle tooling matters as much as the cryptography. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Distributed energy resources and the grid edge

DER security is where the smart grid differs most from classic OT. The control path often runs utility to aggregator cloud to vendor cloud to inverter, over the internet and customer broadband. NIST SP 1800-32 (final), the NCCoE practice guide for securing DER as industrial internet of things devices, demonstrates authentication and access control between distribution and DER operators, integrity protection of exchanged data, malware detection, behavioural monitoring, and an independent immutable register of commands exchanged. IEEE 1547.3-2023 provides guidance on cybersecurity of DER interconnected with electric power systems, and IEEE 2030.5-2023 (the Smart Energy Profile application protocol, RESTful over HTTP and TCP/IP) defines the security features used to protect DER, demand response and EV messages.

• Know the real control path: map every route by which a setpoint, curtailment or firmware update can reach a device, including the manufacturer's own fleet portal.
• Authenticate both ends: device certificates for inverters and gateways; strong, scoped credentials for aggregator and DERMS integrations; no shared API keys across customers or regions.
• Bound the commands: rate limits and plausibility checks on aggregate commands (for example, refuse a curtailment that would drop more than a set share of a feeder's DER at once without a second approval).
• Keep a command record: NIST SP 1800-32's immutable command register idea lets both parties prove what was sent and when.
• Control firmware updates: require signed firmware, staged rollouts by cohort, and the ability to halt an update campaign. See the Firmware and Boot Security Guide.
• Contract for it: procurement terms for DER vendors and aggregators should cover vulnerability disclosure, remote access logging, data location and incident notification.

For consumer device baselines (default passwords, update support periods), see the IoT Security Guide.

Where identity fits

Most grid control is machine to machine, so identity in the smart grid is mostly non-human: IED and gateway certificates, SCADA service accounts, ICCP peer credentials, DERMS and aggregator API credentials, and vendor remote access accounts. Common weak points are shared IED passwords that never change, service accounts on historians and front end processors with domain rights, and vendor accounts left enabled between visits. NERC CIP-005-7 already requires an intermediate system, encryption and MFA for interactive remote access to high impact and medium impact (with external routable connectivity) systems, plus the ability to determine and disable active vendor remote access, including system to system access. See the OT and ICS Identity and Access Guide and the Energy Sector Identity and OT Access Guide.

Regulation: NERC CIP and the EU Network Code on Cybersecurity

NERC CIP (North America)

NERC CIP standards apply to the bulk electric system (BES). CIP-002 categorises BES Cyber Systems as high, medium or low impact using bright line criteria (for example, transmission facilities at 500 kV or above and generation of 1,500 MW or more at one plant are medium impact) and must be reviewed at least every 15 calendar months. The rest of the family applies controls in proportion. Points that matter most for the smart grid:

• CIP-003-9: adds Attachment 1 Section 6 for low impact assets: a process to determine vendor electronic remote access, disable it, and detect known or suspected malicious inbound and outbound communications.
• CIP-005-7: electronic security perimeters, electronic access points with deny by default, malicious communication detection, and remote access controls (Parts 2.1 to 2.5), with R3 extending vendor remote access controls to EACMS and PACS.
• CIP-015-1 (INSM): requires processes to monitor network activity inside the electronic security perimeter of high impact systems and medium impact systems with external routable connectivity: risk-based selection of data feeds (R1.1), detection of anomalous activity (R1.2), evaluation (R1.3), retention of data related to anomalies (R2) and protection of that data from unauthorised deletion or modification (R3). FERC approved it in Order No. 907 on 26 June 2025; according to legal commentary on the order, requirements take effect in phases, starting with certain control centres about three years after the order became effective, with other entities given a further 24 months, and FERC directed NERC to extend INSM to EACMS and PACS outside the perimeter. Check the NERC implementation plan for your exact dates.
• Supply chain: CIP-013 requires supply chain risk management plans, which is the natural home for DER and relay vendor security requirements.

See the NERC CIP Guide for the full family.

EU Network Code on Cybersecurity (Regulation (EU) 2024/1366)

Commission Delegated Regulation (EU) 2024/1366 of 11 March 2024 establishes sector-specific rules for cybersecurity aspects of cross-border electricity flows and entered into force on 13 June 2024. It applies to entities identified as high-impact or critical-impact using an Electricity Cybersecurity Impact Index (ECII), a category that recital 7 says is separate from NIS2 essential and important entities. The list of possible entities is broad: electricity undertakings, nominated electricity market operators, critical ICT service providers, recharging point operators, managed security service providers and others.

For an EU utility the practical message is that the network code runs alongside NIS2, not instead of it. See the NIS2 Directive Guide.

Threats, mapped to controls

MITRE ATT&CK for ICS documents the Ukraine campaigns: the 2015 Ukraine Electric Power Attack (C0028), in which Sandworm Team (G0034) used BlackEnergy3 and KillDisk against transmission and distribution substations; the 2016 attack (C0025), which used Industroyer (S0604) against distribution substations and which ATT&CK describes as the first publicly known malware designed to impact grid operations; and the 2022 attack (C0034), in which unauthorised commands were sent from the utility's SCADA system. Industroyer2, which spoke IEC 104, was found before it caused impact. The table maps the techniques that recur in grid incidents to defensive controls.

Implementation roadmap

1. Inventory and categorise (months 0 to 3): list control centres, substations, protection schemes, DER fleets and every external connection, including aggregator and manufacturer clouds. Apply CIP-002 style impact categorisation even where NERC does not apply.
2. Close remote access gaps (months 0 to 6): route all interactive and vendor access through an intermediate system with MFA, record sessions, and build the ability to disable vendor access quickly.
3. Segment and baseline (months 3 to 9): zones and conduits per substation, deny by default gateway rules, configuration baselines for IEDs and RTUs, and secure storage of SCL files and relay settings.
4. Deploy internal monitoring (months 6 to 12): protocol-aware passive monitoring on SPAN or TAP ports at control centres first, then high value substations. Run in learning mode, tune, then alert. Protect the collected data from tampering (CIP-015 R3).
5. Introduce protocol security on new builds (ongoing): make IEC 62351 support and an OT PKI a procurement requirement; pilot TLS and GOOSE authentication in a lab with the protection engineers before production, with a documented rollback (disable the security profile and revert to the previous configuration).
6. Bring DER into scope (months 6 to 18): contractual security terms, certificate-based device identity, command plausibility checks and a command register for aggregator interfaces.
7. Exercise (every year): run exercises where SCADA is unavailable and staff operate substations manually, and include DER curtailment and vendor cloud loss scenarios.

Small vs large utilities: a small distribution utility gets most value from steps 1, 2 and 7 plus a managed monitoring service; a TSO or large integrated utility needs the full programme, its own OT PKI and a dedicated OT SOC capability.

Detection and measurement

Log and alert on: new or unknown masters talking to outstations; control commands outside schedules or from unexpected hosts; IED configuration downloads and setting changes; firmware updates; GOOSE publisher changes; remote access session start and end, especially vendor sessions; and bulk DER commands through aggregator interfaces.

• Remote access coverage: percentage of interactive and vendor access paths that go through the intermediate system with MFA (target 100%).
• Monitoring coverage: percentage of control centres and high value substations with protocol-aware internal monitoring.
• Credential hygiene: number of IEDs and DER gateways still on default or shared credentials, trending down.
• Protocol security adoption: share of new substations commissioned with IEC 62351 TLS or RBAC enabled.
• Time to disable vendor access: measured in exercises; minutes, not hours.
• Anomaly triage time: median time from INSM alert to evaluation complete.

See the Security Operations Metrics Guide for how to report these.

Framework mapping

Common failure patterns

• Treating the aggregator cloud as out of scope: the utility secures its DERMS but not the manufacturer or aggregator platform that can push setpoints and firmware to the same fleet.
• Remote access that bypasses the intermediate system: a cellular modem in a substation cabinet or a vendor's own remote support tool installed on an engineering workstation.
• Monitoring only at the perimeter: firewall logs show nothing when an attacker uses a legitimate SCADA host to issue commands, which is what happened in the Ukraine attacks.
• Enabling protocol security without the protection engineers: GOOSE authentication or TLS turned on without timing tests, causing misoperation, and then switched off for good.
• Certificates without lifecycle: device certificates issued at commissioning and left to expire, creating a choice between an outage and disabling authentication.
• No manual fallback: operators who have never run a substation without SCADA, and no spare serial to Ethernet converters or gateways if firmware is bricked.

Practitioner checklist

• Map every control path to substations and DER, including manufacturer and aggregator clouds.
• Route all interactive and vendor remote access through an intermediate system with MFA and the ability to disable it in minutes.
• Replace default and shared IED, RTU and inverter credentials; vault what cannot be centralised.
• Segment station bus, process bus and engineering networks, with deny by default at the gateway.
• Deploy protocol-aware internal monitoring at control centres and priority substations, and protect its data.
• Make IEC 62351 support, signed firmware and certificate lifecycle part of every relay, gateway and DER procurement.
• Add plausibility checks and a command record for aggregate DER commands.
• Confirm your NERC CIP-003-9 and CIP-015-1 dates, or your status under Regulation (EU) 2024/1366, with your compliance team.
• Exercise manual operation and vendor cloud loss at least yearly.

Standards and references

• NERC: CIP-015-1 Cyber Security, Internal Network Security Monitoring
• NERC: CIP-005-7 Cyber Security, Electronic Security Perimeter(s)
• NERC: CIP-003-9 Cyber Security, Security Management Controls
• EUR-Lex: Commission Delegated Regulation (EU) 2024/1366, network code on cybersecurity aspects of cross-border electricity flows
• IEC: IEC 62351 Power systems management and associated information exchange, Data and communications security
• NIST: IR 7628 Rev. 1 Guidelines for Smart Grid Cybersecurity
• NIST NCCoE: SP 1800-32 Securing Distributed Energy Resources
• MITRE ATT&CK: 2016 Ukraine Electric Power Attack

Related NHI Mgmt Group resources: OT Security Guide · IEC 62443 Guide · OT and ICS Identity and Access Guide · IoT Security Guide