Distributed Energy Resources and Solar Inverter Security Guide: Fleet, Cloud and Device Controls

Millions of rooftop and commercial solar inverters, batteries and EV chargers now take commands over the internet from vendor clouds and aggregators, and a single compromised control path can reach a whole fleet at once. The US Department of Energy notes that grid-level consequences become possible once enough distributed energy resources (DER) are affected, and research in 2025 showed that a small share of inverters in a region could be enough. This guide covers the DER control chain from device to vendor cloud to aggregator to utility, the standards that apply (IEEE 1547.3, IEEE 2030.5, NIST IR 8498), the identity and update controls that matter most, and how to monitor a fleet. It is defensive guidance for utilities, aggregators, asset owners of commercial and utility-scale solar, installers and the security teams that support them. For the wider grid context, see the Smart Grid Security Guide; this page goes deeper on the DER edge.

Key takeaways

• The fleet is the target, not the device. DOE warns that an aggregator or vendor compromise can reach every DER that takes its direction, so cloud accounts, APIs and update servers deserve more attention than any single inverter.
• Every hop needs authenticated, scoped identity. Device certificates, per-site credentials and least-privilege API tokens between inverter, gateway, vendor cloud, aggregator and utility replace the implied trust that DOE says does not scale.
• Firmware and settings are the payload. Malicious updates and changed ride-through, trip or power settings are the realistic grid attacks; signed firmware, verified updates and setting change control are the core defences.
• NIST IR 8498 is the owner baseline. Its seven guidelines (unique credentials, RBAC, logging, updates, backups, disabling unused features and protected connections) are achievable today, though only two of five tested inverters could implement all seven.
• Procurement is the control that scales. Undocumented communication paths, weak cloud portals and missing security logs are fixed by contract requirements and testing before purchase, not by owners after installation.

The DER control chain and where it breaks

A modern DER installation rarely talks directly to the utility. The typical path is inverter or battery to a local gateway or data logger, to the manufacturer's cloud over customer broadband, Wi-Fi or cellular, then through APIs to an aggregator or virtual power plant operator, and finally to the utility's distributed energy resource management system (DERMS). DOE's October 2022 report, prepared by CESER and EERE, covers distribution-connected DER under 20 MW and identifies the main risks along this chain.

DOE lists the attack types that matter at grid scale: botnet-style aggregate attacks, malicious configuration or patching, manipulation of ride-through and trip settings, spoofed data and malicious control requests. In MITRE ATT&CK for ICS terms these map to T0883 Internet Accessible Device and T0822 External Remote Services for access, T0859 Valid Accounts for persistence, and T0836 Modify Parameter and T0831 Manipulation of Control for impact, with T0862 Supply Chain Compromise covering the vendor path.

Standards and requirements that apply

Grid codes and utility interconnection rules, not cybersecurity laws, are where most DER security requirements actually bite. Check what your utility's interconnection agreement and any state or national grid code require, and treat the documents above as the technical basis. In Europe, see the network code section of the Smart Grid Security Guide.

Device baseline: NIST IR 8498 in practice

NIST's seven guidelines are written for residential and light commercial owners, installers and maintainers. They also make a sensible minimum for commercial sites.

1. Change default passwords and credentials: set unique credentials at commissioning, use MFA where available, and replace factory certificates or keys used for device-to-device connections.
2. Use role-based access control: separate Installer, Maintainer and Homeowner (or Operator) roles with only the permissions each needs, and review assignments periodically.
3. Log security events: record account changes, logins, configuration changes, updates and connectivity events, and store logs somewhere other than the inverter.
4. Update software regularly: verify the source and integrity of updates, deploy security updates quickly, and replace devices the manufacturer no longer supports.
5. Back up configuration: after commissioning and after every change, so a known-good state can be restored after an incident.
6. Disable unused features: turn off unused remote protocols and wireless, and keep guest access read-only.
7. Protect communications: keep the inverter on a separate network segment or VLAN from personal and business devices, or use a VPN or dedicated cellular link.

NIST's testing found gaps: most inverters logged operational data rather than security events, only one fully supported security event logging, and only two of five could implement all seven guidelines. NIST also recommends that safety-critical control updates be performed only through a local interface, and that automatic updates be configurable and defer when conditions are unsafe. Use these findings in procurement.

Where identity fits: device, cloud and API credentials

DER security is largely a non-human identity problem. Every inverter, gateway, cloud service and aggregator integration authenticates as a machine, and fleet-scale attacks work by abusing those identities.

• Device certificates: IEEE 2030.5 deployments use TLS with device certificates, and the device identifier is derived from the certificate. Manage these like any machine identity: unique per device, issued from a controlled PKI, revocable, and tracked to expiry. See the Machine Identity, PKI and Certificate Lifecycle Guide.
• Cloud portal accounts: installer and owner accounts on manufacturer portals often control many sites. Require MFA, per-installer accounts rather than shared logins, and removal when an installer leaves.
• Aggregator API credentials: scope each API key or OAuth client to the sites and functions it needs, rotate it, and never reuse one credential across regions or customers. A single all-fleet token is the identity equivalent of a single point of failure.
• Vendor remote support: manufacturer engineers often hold standing remote access. Replace it with time-bound, approved and logged sessions. See the OT Third-Party and Integrator Access Guide and the OT Remote Access Guide.
• Update signing keys: the key that signs fleet firmware is the most powerful credential in the ecosystem. Protect it in an HSM with dual control. See the Code Signing Security Guide.

Fleet update and setting change control

DOE highlights that vendors may hold mass update capabilities outside the control of aggregators and owners, and that failed or poorly coordinated updates can themselves reduce output or disrupt grid behaviour. Treat fleet changes as grid operations.

• Signed and verified firmware: devices must reject unsigned or downgraded images (SP 800-53 SI-7). Ask for the SBOM with each release. See the SBOM Guide.
• Staged rollout: pilot a new release on a small, monitored group, then expand in rings with a pause between each, and keep a tested rollback image.
• Approval for grid-relevant settings: changes to ride-through, trip, volt-var, frequency-watt or export limits should require two-person approval and be logged with who, what, when and why.
• Rate limits on fleet commands: aggregator and vendor platforms should limit how many devices a single command or account can change at once, and alert on large simultaneous changes.
• Coordinate with the utility: agree notification for mass updates that could change output, so grid operators can tell a planned change from an attack.

Implementation roadmap

1. Inventory (month 1): list every DER asset, its firmware version, every communication interface (including cellular and Wi-Fi), the cloud service it reports to, and who holds accounts. Physically inspect a sample for undocumented radios.
2. Close the obvious (months 1 to 2): change default credentials, enable MFA on portals, remove ex-installer accounts, disable unused interfaces, and segment DER onto its own network.
3. Logging (months 2 to 3): export inverter, gateway and portal logs to a central store; where devices cannot log security events, monitor the network instead.
4. Contract and procurement (months 2 to 4): add security requirements to purchase and service contracts: IR 8498 capabilities, signed firmware, SBOM, documented interfaces, vulnerability disclosure, cloud MFA and tenant isolation, and audit rights.
5. Change control (months 3 to 6): introduce approval for setting changes and staged firmware rollout with rollback.
6. Test and exercise (ongoing): commission independent testing of devices and cloud APIs, and run a tabletop where a vendor cloud is compromised.

Small versus large owners: a homeowner or small business can realistically apply the seven NIST guidelines and segment the network. A utility-scale operator or aggregator needs the full roadmap, contractual controls on manufacturers and continuous monitoring, and should align with NERC CIP style controls where its systems connect to bulk electric system operations.

Detection and measurement

• Monitor: unexpected outbound connections from DER segments (especially to unknown cloud endpoints), new cellular or wireless interfaces, portal logins from new locations, API calls that change many sites at once, firmware version changes outside a release window, and telemetry that disagrees with physical measurements.
• Verify control requests: DOE recommends moving towards verified control requests; at minimum, compare commanded changes with approved change tickets.

Framework mapping

For IEC 62443 zone and conduit design around DER gateways and plant controllers, see the IEC 62443 Guide.

Common failure patterns

• Trusting the vendor cloud by default: CISA's April 2025 advisory ICSA-25-105-04 on Growatt cloud applications listed authorisation bypass through user-controlled key (CWE-639) and external control of configuration settings (CWE-15), with CVSS v4 9.3. Cloud-side flaws like these sit outside the owner's view, which is why contracts and testing matter.
• Exposed monitoring gateways: Contec SolarView Compact command injection (CVE-2022-29303) is in the CISA Known Exploited Vulnerabilities catalogue, added 13 July 2023. Solar monitors left on the internet are actively targeted.
• Undocumented communication paths: in May 2025 Reuters reported, citing unnamed sources, that undocumented communication devices had been found in some Chinese-made inverters and batteries; pv magazine noted it could not verify the claim. Whatever the outcome, the lesson is to inventory and test every interface rather than rely on the datasheet.
• Systemic vendor weaknesses: Forescout's SUN:DOWN research (March 2025) reported 46 new vulnerabilities across three vendors, with solar monitors and cloud backends the most affected components, and estimated that control of under 2 per cent of Europe's solar inverters could be enough to push frequency to 49 Hz.
• Shared installer logins: one installer account controlling hundreds of customer sites, kept after staff leave, turns one phished password into a fleet incident.
• Logging nothing useful: devices that log only production data leave no evidence of who changed a setting. Compensate with network monitoring and portal audit logs.

Lessons from incidents

No DER cyber attack has yet caused a confirmed grid disturbance in the public record, but the research and advisories above show the same pattern: weaknesses concentrate in cloud platforms and gateways that serve many sites, not in individual inverters. DOE's estimate that around 30 per cent DER penetration relative to peak load can begin to produce grid-level consequences, and the SolarPower Europe and DNV estimate that a targeted compromise of 3 GW could have significant grid implications, both point to fleet controls as the priority. Monitor OT and ICS Security Statistics Guide and sector advisories for new incidents.

Practitioner checklist

• Inventory every DER device, firmware version, interface, cloud endpoint and account holder; physically inspect a sample.
• Apply the seven NIST IR 8498 guidelines on every residential and commercial site you manage.
• Enforce MFA and individual accounts on manufacturer and aggregator portals; remove leavers within one working day.
• Issue unique device certificates and scoped API credentials for every hop; never share one credential across fleets.
• Require signed firmware, SBOMs, documented interfaces and vulnerability disclosure in every purchase contract.
• Roll out firmware in staged rings with tested rollback and utility notification for output-affecting changes.
• Require two-person approval and logging for ride-through, trip and export setting changes.
• Segment DER networks and monitor them for new outbound connections and mass changes.
• Track KEV and CISA ICS advisories for your inverter, gateway and cloud vendors.

Standards and references

• IEEE: 1547.3-2023 Guide for Cybersecurity of Distributed Energy Resources Interconnected with Electric Power Systems
• NIST: IR 8498 Cybersecurity for Smart Inverters
• US Department of Energy: Cybersecurity Considerations for Distributed Energy Resources on the U.S. Electric Grid
• IEEE: 2030.5-2023 Standard for Smart Energy Profile Application Protocol
• CISA: ICS Advisory ICSA-25-105-04 Growatt Cloud Applications
• CISA: Known Exploited Vulnerabilities Catalog
• SunSpec Alliance: Cybersecurity Work Group
• Forescout: SUN:DOWN, new vulnerabilities in solar power systems

Related NHI Mgmt Group resources: Smart Grid Security Guide · Energy Sector Identity and OT Access Guide · EV Charging Security Guide · IoT Security Guide