Shut Up, I’m Busy!

How solar energy’s product design failure is a warning for every connected device.

Photo by David Pupăză on Unsplash

In late December 2025, Poland suffered a wave of coordinated, AI-powered cyberattacks targeting primarily its renewable energy sector. I read the incident report expecting to find a security story and found a product design story instead.

Solar energy is forecast to represent approximately one third of global generation capacity in the next five years, and according to Global Solar Council, global solar capacity reached 2 TW in November 2024. For scale: if we assume an average household energy consumption of 3,500 kWh per year, this amount could power approximately 850 million homes for a whole year — roughly every household in China, India, Indonesia, and Chile combined, according to statistics by the United Nations.

But the software that makes it work was made to transmit data, not to withstand adversarial interrogation. Solar software was designed for a world where the main threat was unfavorable weather conditions and hardware failure, not coordinated cyberattacks driven and/or enhanced by AI. The product teams that built these products were in the monitoring business, not the resilience business. DER Security identified three cyberattacks and 34 vulnerabilities in the solar sector between 2024 and the first half of 2025 alone.

At a time when AI-powered cyberattacks are becoming increasingly the norm — according to Foresiet, AI-enabled attacks rose 89% YoY, with nine major incidents between March and April 2026 alone — software product teams cannot wait for a ticket to prompt them into action. And the gap between the threat model these products were built for and the one they operate in is a product design failure that teams across industries can learn from: confusing their medium with their mission.

When the Attack Skips the Front Door

In the morning and afternoon hours of December 29, 2025, Poland suffered a series of coordinated attacks that targeted more than 30 wind and photovoltaic farms, a private company from the manufacturing sector, and a large combined heat and power plant supplying heat to almost half a million customers in the country.

While this type of action is not uncommon, what made this particular instance distinct — at least where solar farms are concerned — was the fact it did not target the supervisory control and data acquisition (SCADA) system, but instead the field-deployed Remote Terminal Units (RTUs) which collect real-time data from inverters, sensors, and meters, and send it to the central control system. SCADA¹ is the central control system; RTUs are field-level devices that feed data up to it.

Functional levels of a Distributed Control System, by Daniele Pugliesi — (own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=31527335)

According to TechRadar, “Many solar inverters connect directly to the internet, making them easy targets for cybercriminals. Attackers can exploit outdated firmware, weak authentication mechanisms, and unencrypted data transmissions to gain control.” To make matters worse, small and mid-sized farm PV operators are at bigger risk because they lack cybersecurity awareness. “Utilities can invest in expertise, technology, and knowledge to protect themselves. Small companies often don’t have a dedicated IT or cyber office,” says cybersecurity expert Roberto Setola.

RTUs were previously shielded because attacking them meant time invested in learning which commands to use and which variables to manipulate; a high-effort, low-return action, because an attack on a single RTU is negligible from an energy balancing perspective. However, impact scales: level 1 units are easier to breach than the central, well-defended system core controlling up to 3 GW (the maximum sudden loss that a TSO must be able to absorb in Europe, according to ENTSO-E). If attackers could simultaneously target a large number of RTUs and PLCs across multiple smaller operators instead of investing in a long campaign to breach supervisory or coordinating computers, the effect would be the same or bigger. And now they can — thanks to AI, and the fact most of the inverters used come from only a few manufacturers.

Governments and regulatory bodies have attempted to address the security gaps. In the EU, the Network and Information Security (NIS2) directive is meant to bolster Europe’s resilience against current and future cyberthreats, with requirements around risk management, corporate accountability, reporting obligations, and business continuity. For essential entities in the energy sector — companies with more than 50 employees or €10 million in annual turnover — non-compliance can mean fines of up to €10 million or 2% of global annual turnover, whichever is higher.

And this is where the argument gets uncomfortable. A small solar operator running a 1–5 MW farm generates between roughly €34,000 and €630,000² and typically employs fewer than five people. They fall well below NIS2’s size thresholds and entirely outside its reach. The fine doesn’t land on them, on the reasonable principle that you don’t impose enterprise-grade compliance burdens on a farm running three megawatts.

It does land on the distribution system operators collecting their output, who are in scope, and who are required under NIS2 to secure their supply chains — up to and including the thousands of sub-threshold operators feeding into their grid. It lands on the inverter and RTU manufacturers whose firmware was the attack vector, and who are large enough to qualify as important entities. It lands on the cloud monitoring platforms aggregating telemetry from dozens of small farms into a single point of compromise. In other words, NIS2 creates compliance obligations for every party around the small operator, without creating any obligation for the small operator themselves. The directive’s pressure lands on the entities with legal teams and security budgets.

I imagine this was designed as an analogue to herd immunity: if everyone around the small operator is compliant, then the operator too is protected. However, it leaves unregulated an attack surface that is the fragmented, under-resourced layer those entities depend on. NIS2’s supply chain requirement on DSOs is intended to create downstream pressure on small operators through contractual requirements, but even if it does, compliance has a relatively long implementation timeframe for operators. And while NIS2’s supply chain requirement assumes DSOs can contractually compel their sub-threshold suppliers, is that enforceable at scale? Or is it a compliance fiction for a DSO with 10,000 small operators feeding its grid?

The problem is that attackers don’t care about the legal thresholds or compliance. They care about the topology. And while the ultimate goal of the Poland attacks remains unclear, it seems plausible the attackers were stress-testing the infrastructure for scenarios that cause energy service not to be delivered without compromising the physical infrastructure itself.

In other words, a DDoS attack.

Monitoring Products in an Adversarial World

Cloudflare defines DDoS attacks as malicious attempts to disrupt a server’s service by overwhelming it or its surrounding infrastructure with a flood of traffic. “From a high level, a DDoS attack is like an unexpected traffic jam clogging up the highway, preventing regular traffic from arriving at its destination.”

Inverter APIs were designed for monitoring convenience — showing homeowners production data or enabling fleet management — with the devices exposing REST APIs that share real-time production data, historical energy output, and device metadata. They allow the exchange of data between users’ solar inverters and several distinct management apps, without forcing the need for additional hardware to negotiate the information transfer. Aggregation platforms provide normalized solar inverter data from over 20 brands through a single integration, so that a virtual power plant operator or energy management app doesn’t need to build separate connections to each manufacturer.

Solar software’s security architecture reflects the threat model it was built for: static API keys passed as URL parameters, no standardized cybersecurity certification until February 2026 (UL 2941), smaller DER systems with no cybersecurity standards at all, and widespread reliance on third-party vendors whose access operators may not even be aware of. Only 36% of energy sector professionals consider cybersecurity a critical risk, and there is a shortage of cybersecurity professionals with the necessary knowledge, experience and skills. This leaves fewer people to question what happens if an AI system probes a thousand of these endpoints simultaneously looking for the weakest authentication — which is precisely the Poland scenario at the software layer.

The risk compounds at the infrastructure level. Huawei and Sungrow alone control remote access to 168 GW of PV capacity in Europe — projected to exceed 400 GW by 2030. Those inverters phone home to the same cloud platforms regardless of which country they’re installed in. A compromise of FusionSolar or iSolarCloud gives access to every connected inverter across the continent simultaneously, a technical dependency that has been directly flagged by the EU ISS.

Judging from governmental response in the UK and the EU, it’s clear architectural responses will follow, but they’ll follow faster if product teams start asking the right questions now rather than waiting for the next incident.

Standard DDoS defenses (such as rate limiting, attack surface reduction, WAFs, always-on mitigation) are mature and proven for web infrastructure where traffic flows through identifiable chokepoints. Solar’s distributed architecture, where every field device is its own endpoint, routes around these defenses by design. The web went through the same evolution (exposed servers to firewalls to CDNs to always-on mitigation) and it took major incidents to force each step, so maybe solar is at the “exposed servers” stage now, and the Poland attack may have been its SQL Slammer moment — harmless in itself, but able to cause harm by how the system is structured.

The attacks may have been stress-testing the infrastructure for scenarios such as:

• Can the system be triggered into economic havoc by “false” supply failures?
• What happens downstream when you destabilize the system? If you have a grid set to receive N kWh from photovoltaic parks and they go down, how many backup tiers are available?
• Can you get the whole system to power down without destroying it (eg, in the event of an attack)?

It’s not just about interrupting power generation. Hackers can block software configurations, force plant owners to reset all data, or even delete communication configurations entirely, causing economic losses. Machine downtime and potential fines under the EU NIS2 directive are also possible. — Roberto Setola

Decentralization Paradox

This is particularly important given solar’s increased dominance in global growth of renewables. The IEA’s 2025 executive summary on renewables forecasts 3546 GW capacity by 2030 (representing roughly 30%–40% of global energy capacity). Coupled with local governments’ concerted effort to move away from fossil fuels — like Austria’s ‘Cheaper Electricity Act’, which allows citizens to create fully off-grid solar systems as well as small farms that feed back into the grid — governments aim to put residents at the center of the renewable push.

But “clean” energy isn’t automatically safe, and has real risks. Unlike nuclear energy, solar is not necessarily biologically hazardous, but the economic and infrastructural consequences of unsafe solar energy should also be in users’ and producers’ minds. They also must be handled by product teams and companies building said products, because while decentralization is solar’s strength against physical disruption, it is also its weakness against coordinated cyber disruption. As Setola points out, “you don’t need to target a single player controlling 3 GW of power… you can attack 1,000 smaller operators managing 3 MW each. These smaller entities are far less protected because they lack the expertise and resources of larger operators.” Uri Sadot, a solar cybersecurity expert and managing director of SolarDefend, agrees: “The reason it doesn’t just freak out individuals, but also governments are involved, is because what could happen if a million of these systems are told to turn off at once? That’s the big scare, and that throws the grid off balance.”

So grid-connected distributed generation is more vulnerable than either centralized generation or truly off-grid nodes. And yet, even though an off-grid owners’ association in Austria getting shut down may not affect “the market,” it has the potential to devastate the individual operators. Similarly, because NIS2 creates compliance obligations for every party around the small operator, it creates a structurally inevitable gap: the small, unregulated operators are precisely the decentralized attack surface that is solar’s physical strength. Meanwhile, attack vectors multiply and offensive capabilities are escalating exponentially, powered by AI.

No Company Holds a Universal Red Line

Anthropic’s Mythos Preview analysis demonstrates that general-purpose AI can autonomously discover and exploit zero-day vulnerabilities in critical software, many of which more than one or two decades old, and present in various operating systems — including OpenBSD, an OS known primarily for its security. Although the analysis does not mention solar energy infrastructure, much of it runs on the same software stack Anthropic demonstrated it can compromise autonomously and at scale — and solar systems were designed assuming that layer was largely secure.

To make matters more dire, experts from Vidoc Security Lab were able to replicate Anthropic’s results using public, patched cases with GPT-5.4 and Claude Opus 4.6. They found the key building blocks are already accessible in public models, and concluded defenders should prepare for that reality instead. According to them, “frontier models are getting much better at finding serious vulnerabilities in real software.”

With AI labs and private software contractors rushing to fulfill governmental requests for artificial intelligence deployment across portfolios, at a moment when multiple states aim to use AI as a lever (particularly in defensive and offensive military capabilities), what prevents frontier model deployment against public infrastructure? To assume companies could be relied on to override their drive for maximizing profit and instead hold ethical red-lines in such instances would be naive at best because, as Paul Ford puts it, “[c]ompanies are companies. They will, eventually, be expected to turn a profit. Humanistic goals will become subsumed by data-driven metrics.” No company holds a universal position against weaponizing AI: they hold a “not against our interests” position. Once a government decides to target others, those lines dissolve — as Google’s dropped pledge demonstrates, and as the current US administration’s behavior toward its traditional allies confirms.

When corporate and governmental interests collide, ethical and humanistic guardrails usually get crushed. In a recent, concrete example, Anthropic held some ethical red lines on parts of a $200 million Pentagon contract — specifically against AI use in fully autonomous weapons and in domestic mass surveillance in the US. The Pentagon then designated the company a supply chain risk, a label previously reserved for foreign adversaries. Meanwhile Palantir, which drew no such lines, had its Maven system formalized as a program of record worth up to $10 billion. And neither is Anthropic a purely ethical actor: its red lines were geographically selective, arguing for protection of domestic users while implicitly permitting the same capabilities abroad.

We’ve seen how regulations can leave an attack surface wide open that is growing in size due to the incorporation of homeowners into electricity production; how AI — unconstrained by effective ethical and legal regulations — is exponentially better at exploiting these vulnerabilities; and how current technology is not designed to handle these threat vectors. In no uncertain terms, it is the product teams who are responsible for addressing this gap. Here’s what this means.

Whose Job Is It Anyway?

The sinking of the RMS Titanic is a useful illustration of how organizational design can route critical signals to the wrong person. Most people think the ship was sunk by an iceberg, but the real story is far more complex — and more relevant to this problem.

The Titanic received at least seven ice warnings from other ships. The radio operators were employed by the Marconi Company — pioneer of wireless long distance communication — to handle passenger telegrams, and treated ice warnings as secondary to their commercial KPI. The last ship to make contact was the SS Californian and when they tried to warn the Titanic was surrounded by ice, operator Jack Phillips (who was working through a backlog of passenger messages) shot back: “Shut up! I’m busy!”

The information and the technology existed, but the organizational design routed life-saving signals to someone whose job was to handle passenger telegrams, not the ship’s communication. The same pattern plays out in solar: the vulnerability information exists, the cybersecurity tools exist, but the product teams are optimizing for monitoring convenience and cost, not adversarial resilience. And as a KAUST researcher recently demonstrated, it is possible to detect malicious interference at the firmware level with up to 100% accuracy using a single hardware counter — but current communication standards don’t transmit the firmware-integrity signal to operators.

The detection capability exists at the device level; there’s no protocol to surface it. In solar, software is increasingly playing the role of Jack Phillips.

In her article The Napoleon Express, Erika Flowers argues that every medium ever built was mistaken by its operators for the mission itself, when the mission is always the message reaching the recipient. Applied to solar software: if a company is in the business of enabling customers to generate, store, and/or transmit solar energy, then in this threat environment they cannot think of themselves as being in the monitoring business. They need to think about the core problem: reliable, trustworthy energy delivery. Solar is a trust relationship mediated by software, and security is intrinsic to that trust.

For product teams, this means taking action on:

• Who has the right to access the equipment and its data, how, and for what purposes — different valid actors have distinct use-cases, and likely need different privileges when interacting with devices;
• System architecture — what are attack vectors enabled by the technology used, and how can they be mitigated/handled;
• What is the unit-economics of your product? Is it possible to reduce attack surface without forcing customers to buy, configure, and maintain additional pieces of hardware or software?
• Are there ways to incentivize small operators to buy in? Are these within the scope of the company/product, or do they require governmental involvement?

If every field device is internet-connected — and so essentially indistinguishable from an IoT device — the lessons from decades ago also apply here: internet-connected endpoints need a protective layer in front of them. But a better question is why are we exposing every field device to the internet in the first place, and what would it take to design the system differently? Are there architectural models — gateway-mediated, local-first with selective sync — that would preserve monitoring capability without individual device exposure?

Smart, interconnected devices have become ubiquitous; they are in our homes, on our persons, in our transportation. Key sectors such as health, biotech, energy, telecommunications, and banking are increasingly underpinned by AI/ML capabilities. We cannot design for the happy path and hope the adversarial one doesn’t arrive. The health sector is concerned by the mounting threat of private data breaches, and the International Monetary Fund (IMF) suggests extreme cyber‑incident losses could trigger funding strains, raise solvency concerns, and disrupt broader markets.

Solar energy customers are looking for more than just a rebate in their utility bills or infrastructure costs. They look for better ways to live with the environment, to mitigate their impact in the world. Solar customers don’t want to become security experts just to contribute to the grid. They want to buy equipment they can trust, use it without specialist training, and not discover later they became an attack vector. Product teams are responsible for making that possible: their job is to ensure their products don’t turn users into technicians, market specialists — or victims.

The Titanic had the wireless telegraph, the web had exposed servers, solar has exposed inverters — and in each case, the technology to protect the system existed but the product design hadn’t caught up to the threat model. The people who recognized the gap earliest were the ones who could act before the next disaster forced everyone’s hand.

Notes

1. The SCADA system is a control system architecture comprising computers, networked data communications and graphical user interfaces for high-level supervision of machines and processes. It also covers sensors and other devices, such as programmable logic controllers, also known as a distributed control system (DCS), which interface with process plant or machinery. The key attribute of a SCADA system is its ability to perform a supervisory operation over a variety of other proprietary devices.
2. A 1–5 MW operator in Europe faces installed costs averaging around €720/kW (IRENA RPGC, 2025), generates between 1,000 and 1,800 MWh per MW annually depending on location (JRC PVGIS), and sells power under PPA contracts currently ranging from €34 to ~€70/MWh in most markets excluding outlier markets like Ireland (LevelTen Energy, Q3 2025). This translates to gross annual revenues in the range of €34,000 to €630,000 — before OPEX, debt service, a cyberattack, a compliance failure, or both. Sources: IRENA TEC RPGC in 2024.pdf; Global average solar LCOE stood at $0.043/kWh in 2024, says IRENA — pv magazine Global; European solar PPA prices fall below €35/MWh in Q3 2025 — PV Tech; EU Photovoltaic Geographical Information System