When you work inside real solar fields and battery storage sites every day, you start noticing things others overlook. I maintain BESS yards, inspect inverters, plug into SCADA cabinets, and deal with the everyday operational realities of modern energy infrastructure. That perspective gives me a front row seat to the challenges that utilities, developers, and integrators face as they connect more assets to the grid.
Over the last few weeks, I started a structured investigation into industrial cybersecurity across solar and BESS installations. The goal was not to exploit anything. The goal was to understand what is actually happening in the field, what risks are emerging, and where utilities and operators need to focus their attention.
This post summarizes what I uncovered through four phases of research: internet-facing device scans, vendor documentation analysis, GitHub configuration reviews, and identifying exposed control interfaces. Taken together, these steps reveal a clear pattern across the industry.
It shows how quickly the energy sector has modernized, how rapidly connectivity has expanded, and how security has struggled to keep pace.
Day 1: The Internet Already Knows More Than You Think
The first phase was straightforward. I simply used public tools and Google queries to understand what is already visible on the internet. The results were eye-opening.
Using common industrial search techniques, I found:
- 418,000 energy-related devices accessible online
- 132 utilities with public-facing systems or portals
- Dozens of substation, inverter, metering, and SCADA-related interfaces indexed by search engines
None of this required advanced skills. It required curiosity and time.
This is the reality of modern infrastructure. As utilities integrate distributed energy resources, modernize SCADA networks, and push for remote support capabilities, they inevitably increase their exposure. Remote access saves money. Remote diagnostics speed up maintenance. But if the access pathways are misconfigured or not secured, they are discoverable.
The first lesson from Day 1 was simple: everything you assume is hidden may already be indexed. Even if the asset is harmless, the fact that it can be identified matters. Attackers target what they can see.
Vendor Manuals Tell Their Own Story
Next, I examined publicly available vendor documentation. Nothing confidential, nothing internal, nothing leaked. Just PDFs the manufacturers publish online.
What these manuals reveal is striking. Many industrial devices still ship with:
- Default usernames
- Default passwords
- Default IP addressing schemes
- Setup procedures that assume a trusted, isolated network
- No meaningful password complexity requirements
One Schneider Electric power meter manual openly listed its default credentials. Another Modbus device mentioned that authentication was optional. Several devices offered web configuration portals with minimal security guidance.
None of this is surprising to anyone who works in the field. Operational technology grew up in an environment where isolation was the security model. In a fenced-off substation or behind a locked control house door, default credentials were not considered dangerous.
Today, those same devices are increasingly reachable through corporate networks, remote access paths, cloud aggregators, and vendor support tunnels. What used to be a physical security problem has become a cybersecurity problem.
Documentation often reflects the mindset of earlier eras, and that gap has real consequences.
GitHub Reveals How These Systems Are Actually Deployed
The third phase involved searching GitHub for configuration files and industrial code snippets. This was not about finding anything sensitive. It was about understanding real-world engineering patterns.
The results showed:
- Hardcoded Modbus register mappings used in production
- Cleartext host IPs for solar plants, substations, and metering systems
- Python Modbus scripts referencing port 502 directly
- Inverter integration code for Schneider, SMA, and custom EMS deployments
- Test bench configurations that look remarkably similar to real installations
Again, none of this came from private data. These were public repos created by engineers learning, experimenting, or publishing examples. But they reveal habits that carry into real deployments.
Many of the same patterns seen in GitHub examples also appear in field devices: weak authentication, insecure defaults, and systems that rely on obscurity rather than robust protection.
GitHub is not the problem. It is simply a mirror reflecting how industrial engineers work. And it shows that many configurations still assume a trusted environment, even when that no longer matches reality.
The Most Concerning Finding: Public-Facing SCADA Interfaces
Finally, I reached Phase 4, which focused on identifying public-facing login screens for industrial platforms. This is where the research became more serious.
One exposed system immediately stood out: a full Ignition Gateway login panel available over HTTP.
Ignition is widely used across utilities, BESS systems, and industrial automation. It is the backbone for HMIs, historical trending, alarms, and supervisory control. It is not a system that should ever transmit credentials without encryption.
Yet the login interface I found was:
- Accessible through a public IP
- Served over HTTP
- Showing no TLS encryption
- Presenting the full Ignition Gateway Sign In form
- Displaying the host identifier of the Windows server running it
This does not necessarily mean the system is critical. It does not mean anyone could log in. It does not mean anything is misconfigured internally. But it does confirm one thing:
A SCADA system expecting to be internal-only ended up exposed to the public internet.
There is no scenario where that should happen unintentionally.
In addition, I discovered an unrelated remote-access login on port 8105. It was hard to identify, but it presented a browser-based credential prompt over HTTP. This type of interface often belongs to remote desktop tools, embedded HMIs, thin-client gateways, or vendor maintenance utilities.
Taken together, the findings indicate a larger pattern: not all industrial systems are receiving the network isolation or encryption they require.
Why These Findings Matter
There is nothing theoretical about industrial cybersecurity. Power grids, substations, battery storage sites, and solar plants are physical systems. A misconfiguration does not compromise data. It compromises equipment, stability, and uptime.
The issues identified in this research matter because they reflect real operational trends:
- More industrial devices are connected to networks each year.
- More systems rely on remote access for support.
- More legacy devices still assume isolation that no longer exists.
- More operational technologies are migrating toward cloud-linked architectures.
In short, the grid is becoming more connected faster than it is becoming more secure.
Insurance companies already understand this. Underwriters increasingly ask about MFA on SCADA interfaces, segmentation, and remote vendor access. Regulators understand it too. Requirements are tightening across NERC, FERC, DOE, and state-level oversight bodies.
The energy sector no longer has the luxury of treating cybersecurity as an optional cost. It is now a central component of operational reliability.
What I Built to Explore the Problem
To deepen my understanding, I began building a BESS and solar security scanner. The purpose is not exploitation. The purpose is detection.
The tool is designed to identify:
- Vendor banners
- Modbus responsiveness
- Default ports
- Unencrypted interfaces
- Configuration artifacts
- Device fingerprints
- Exposure paths in solar and BESS networks
The idea is simple. If operators can discover their own exposure the same way an outsider can, they can fix issues before they become incidents.
Every solar developer, EPC, and utility should be performing this type of external-facing scan on a regular basis. It is minimal effort and high value.
Recommendations for Utilities and Operators
Based on the patterns I observed, here are the most important actions utilities should prioritize:
1. Eliminate all HTTP access to SCADA platforms
There is no justification for transmitting SCADA credentials in cleartext.
2. Audit all public IPs quarterly
If a system appears externally that should not be external, remediation is immediate.
3. Harden vendor default configurations
Remove default passwords, change default ports, and disable services that are not needed.
4. Improve segmentation between IT and OT networks
Most exposure originates from pathways that cross environments unintentionally.
5. Train field technicians and integrators
Most misconfigurations come from rushed deployments, not malicious actors.
6. Require encryption and MFA for all remote access
This is already becoming a regulatory and insurance requirement.
Industrial security is not solved by tools or firewalls alone. It is solved by awareness, engineering discipline, and a clear understanding of how operational equipment is exposed in the real world.
My research over the past few days reinforced something I already knew from field experience: the grid is more fragile than it appears, and its security depends on decisions made by hundreds of teams across thousands of assets.
The goal is not to criticize those teams. The goal is to ensure the energy transition continues without unnecessary risk.
If we want a stable, secure, and modern grid, we have to build security into it from the ground up.
Top comments (0)