News
Sungrow: Who can control your equipment remotely?
The fixed iSolarCloud vulnerability illustrates an operational risk: central remote access to many installations. Review access, dependencies and fallback operation.
An installation stands on your premises. It may also be controlled through a cloud whose administrative access you do not manage yourselves. The Sungrow case makes that distinction visible: your inventory needs to include the device and the route through which others can change it.
What is known, and what does not follow from it
Security company Jakkaru published research into Sungrow’s iSolarCloud on 7 October 2026. The researchers describe an authentication bypass and potential access to administrative functions for managing installations. According to their timeline, remediation was completed on 14 September. Sungrow lists CVE-2026-107194 as mitigated in its advisory overview. Jakkaru’s research, manufacturer’s overview
Checked on 24 October 2026. This is an analysis of an already remediated vulnerability, not an alert about a newly discovered, unresolved flaw. It does not establish that a widespread power outage actually occurred. A dramatic possibility does not replace evidence of damage.
For operators, one specific question remains: do we know which external access paths can control our operational equipment?
The device is only part of the dependency
For an important installation, we recommend recording four things together: its operational purpose, the responsible operator, the external service and what that service can do. “Manufacturer cloud present” is too vague.
Read-only access to yield data has different consequences from access that can change settings, firmware or operating state. Service provider accounts matter too: who created the access, who uses it today and who removes it when the contract ends?
| Inventory entry | Review question |
|---|---|
| Installation and location | Which service becomes unavailable if the installation fails? |
| Cloud or remote maintenance service | Which functions depend on it? |
| Parties with access | Which organisation can read, change or switch off? |
| Operational responsibility | Who may approve changes and assess faults? |
| Manufacturer information | How do we learn about security problems and remediation? |
Operations, administration and the manufacturer provide technical answers. Procurement can request evidence and contacts. A supplier audit should examine this specific relationship rather than ask only for a general certificate.
One shared service can affect several locations
Consider a fictional business with three locations. Each installation has a local owner, but all three depend on the same remote maintenance platform. Three entries marked “low impact” can conceal a shared risk.
Look beyond individual devices. What would an outage or misuse of the shared control system mean? Could locations be affected simultaneously? Do they share administrators, recovery access or the same service partner? Who prioritises assistance if everyone needs support at once?
The same principle applies to cloud dependencies in refrigeration systems: operational consequences arise from the connection between a technical service and a business process.
Establish fallback operation before disconnecting anything
“We will switch off the cloud” is not a tested continuity plan. Disconnection may impair monitoring, maintenance or necessary control functions. Establish with the responsible people and manufacturer which local functions remain available and what a safe state looks like. Changes to installations belong in an agreed operational process.
A discussion without intervention in production makes a useful small exercise: the external service is unreachable. Which information is missing? Who decides whether operation continues? How are local faults detected? Which contacts and documents remain available independently of the failed portal?
Assign owners and deadlines to unresolved points. A document titled “continuity plan” is worth less than an answered question that enables a decision during an incident.
Turn the review into an evidenced improvement
In Kopexa, you can bring together information assets, other assets, risks and measures. Protection requirements analysis and business impact analysis help connect technical dependencies with operational consequences. This replaces neither the manufacturer’s investigation nor technical protection of the installation. It establishes the context your team needs for its work.
Start with one installation whose failure would matter. Have its remote access explained, assess the operational consequences and agree on evidence for the next unresolved measure. When a manufacturer reports remediation, record which service and version or state that statement covers.