The Attack Surface Nobody Was Watching
The renewable energy transition has added hundreds of gigawatts of distributed generation equipment to the grid over the past decade, most of it managed through cloud-connected platforms that receive far less security scrutiny than traditional utility SCADA systems. Solar inverters — the devices that convert DC power from panels to AC power for the grid — are a ubiquitous, often forgotten OT endpoint. They are connected to cloud management platforms for monitoring, firmware updates, and performance optimisation. They are also connected to the grid.
In 2024 and 2025, Bitdefender researchers disclosed critical vulnerabilities in two of the most widely deployed solar inverter management ecosystems: Solarman and Deye. Together, these platforms manage approximately 195 gigawatts of installed solar capacity across residential, commercial, and utility-scale installations. The vulnerabilities allowed unauthenticated attackers to gain control of inverter settings, access energy management systems, and potentially affect grid stability at scale.
This is the solar sector’s version of the Triton/TRISIS moment for critical infrastructure security — a disclosure that demonstrates that internet-connected OT equipment at grid scale can be reached and manipulated without physical access.
The Solarman and Deye Platforms
Solarman is a Chinese-developed cloud platform used globally for solar installation monitoring and management. Deye is a major inverter manufacturer whose hardware is widely integrated with third-party management platforms including Solarman. Both brands have significant market penetration in Europe, North America, Australia, and Southeast Asia.
The management architecture is typical for this sector: inverters connect to cloud platforms via internet-facing APIs, installers and operators manage configurations through web portals and mobile applications, and the platforms provide aggregated monitoring for fleet-level management. This architecture is convenient and operationally efficient. It is also exposed to the internet by design.
Vulnerability Classes Disclosed by Bitdefender
OAuth token endpoint flaw. Bitdefender identified an OAuth implementation weakness in the Solarman platform that allowed attackers to obtain valid access tokens without completing the intended authentication flow. The token endpoint did not properly validate client credentials in certain request patterns, enabling an unauthenticated attacker to obtain tokens that granted API access. With valid API access, attackers could query plant and device configuration endpoints, retrieve site details and installation layouts, and in some configurations issue control commands to inverters.
The OAuth flaw illustrates a common pattern in IoT and OT cloud backends: authentication flows are implemented rapidly to support mobile application development, without the rigorous security review applied to the API surface those tokens then access. The gap between “this flow produces a token” and “what can that token do” is where the vulnerability lived.
JWT reuse and weak validation. JSON Web Tokens used for session management in the Deye platform were found to be vulnerable to reuse and, in some configurations, to weak signature validation. Bitdefender’s analysis identified that tokens issued to one user context could be replayed in requests for different user or plant contexts, bypassing the access control checks that should restrict which plants and devices a given token can manage.
JWT attacks of this type — claims manipulation, weak algorithm acceptance, cross-context reuse — are well-documented in web application security, but their impact in OT contexts is qualitatively different. A JWT reuse attack against a web application typically results in horizontal privilege escalation between user accounts. The same class of attack against a solar inverter management platform results in access to control endpoints for megawatts of grid-connected equipment.
Hard-coded credentials. The Bitdefender research identified hard-coded credentials in firmware or backend configuration of affected products. Hard-coded credentials are an endemic problem in IoT and OT devices — they represent development-time shortcuts or default configurations that were never designed for production security. A hard-coded credential provides a credential that is consistent across all devices of the same model, cannot be rotated by the operator, and if discovered is valid indefinitely until a firmware update removes it.
For solar inverters, a hard-coded administrative credential in firmware provides an attacker who reaches the management interface with immediate elevated access — no brute force or credential phishing required.
Attack Impact: What an Adversary Could Do
Bitdefender’s disclosure outlined the potential impact across several levels of severity:
Individual inverter configuration access. An attacker with API access to a single plant can read and potentially modify inverter operating parameters: output voltage limits, frequency thresholds, power factor settings, and active power limits. Misconfiguring these parameters can cause an inverter to disconnect from the grid, inject power quality issues, or operate outside safe parameters.
Fleet-level impact at scale. The vulnerability affected platforms managing aggregated capacity at a scale where coordinated manipulation could create measurable effects on grid stability. 195 gigawatts is approximately double the total installed nuclear generating capacity in the United States. Simultaneously disconnecting a significant fraction of this capacity during a high-demand period could create frequency deviations requiring emergency response from grid operators.
DERMS and energy management system access. Some installations integrate Solarman and Deye platforms with Distribution Energy Resource Management Systems (DERMS) and building energy management systems. API access to the solar management platform could provide a pivot point into these connected systems.
Persistent access via firmware updates. Inverter management platforms typically provide firmware update capability. An attacker with sufficient API access could potentially stage malicious firmware updates — a capability with long-term persistence implications beyond configuration manipulation.
Grid Stability Implications
The grid stability concern with distributed solar is distinct from the traditional threat model applied to large generating stations. A single 500MW power station going offline creates a significant but manageable grid event. National grid operators plan for the loss of the largest single generating unit.
Distributed generation presents a different challenge: many small units going offline simultaneously is not a planned contingency. Grid operators design for correlated failures during cloud cover events (when many solar installations simultaneously lose generation), but a coordinated cybersecurity event affecting installations across multiple utilities and grid regions is a scenario that most grid stability models have not formally integrated.
The Solarman/Deye vulnerability was disclosed to vendors and patched before a known exploitation event, but the disclosure demonstrates that the attack surface exists and is reachable from the internet.
What Energy Sector Operators Should Assess
Inventory solar management platform exposure. Energy operators, property managers, and utilities with solar assets should identify which cloud management platforms are in use across their portfolio, confirm that patched versions are deployed, and understand what API access those platforms provide to grid-connected equipment.
Confirm patch status. Solarman and Deye released updates addressing the disclosed vulnerabilities. Confirming that all connected inverters and management platform accounts are on patched firmware and software versions is the immediate action.
Review API access controls. Audit which accounts have API access to solar management platforms, what permission levels those accounts hold, and whether any service accounts have broader access than their function requires. Revoke stale credentials. Confirm that OAuth clients are properly registered and that token lifetimes are appropriate.
Assess DERMS integration security. For installations where solar management platforms are integrated with DERMS or building management systems, map the integration points and confirm that the solar platform cannot be used as a lateral movement vector into more sensitive control systems.
Monitor for anomalous API activity. Solar management platforms generate regular telemetry — monitoring and analytics calls at predictable intervals. Anomalous patterns — high-volume configuration reads, changes to inverter parameters outside maintenance windows, access from unrecognised IP ranges — should be flagged. Most commercial platforms provide audit logging that can support this monitoring.
Review vendor security posture. For future procurement, solar inverter management platforms should be evaluated against security criteria: whether they publish CVE disclosure histories, whether API authentication meets current standards (short-lived tokens, proper OAuth implementation, no hard-coded credentials), and whether security patches are promptly provided for firmware.
Broader Context: Distributed OT Security
The Solarman/Deye disclosure is part of a larger pattern. The expanding perimeter of internet-connected OT equipment in the energy sector includes not just solar inverters but battery energy storage management systems, EV charging infrastructure, smart meters, building automation systems, and grid edge devices. Each of these categories represents a similar risk profile: OT equipment managed through cloud platforms, connected to the internet by design, and historically developed with more emphasis on operational function than security hardening.
CISA’s guidance for the energy sector and the DOE’s updated Cybersecurity Capability Maturity Model (C2M2) both emphasise the need to extend OT security practices to distributed assets — not just traditional generation and transmission infrastructure. The solar inverter vulnerability class is a concrete example of what that extension needs to address.
Grid operators and utilities who have historically focused OT security resources on large generating stations, substation automation, and SCADA systems now need to map their exposure in the distributed edge. The Solarman/Deye research provides a useful framework for the types of vulnerabilities to look for: authentication implementation weaknesses in cloud management APIs, hard-coded device credentials in firmware, and insufficient access control between management plane and control plane functions.
References
- Bitdefender research disclosure on Solarman and Deye platform vulnerabilities (2024-2025)
- CISA Water and Energy Sector Cybersecurity Performance Goals
- DOE Cybersecurity Capability Maturity Model (C2M2) v2.1
- IEC 62443 Industrial Automation and Control Systems Security Standards