What I Learned While Investigating Industrial Security Across Solar and BESS Sites
Source: Dev.to
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 but 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.
Findings
- 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—just 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 and speeds up maintenance, but misconfigured or unsecured pathways are discoverable.
Lesson: 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—PDFs that manufacturers publish online. Nothing confidential, nothing internal, nothing leaked.
What the manuals reveal
- 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.
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, but about understanding real‑world engineering patterns.
Results
- Hard‑coded 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
These public repos were created by engineers learning, experimenting, or publishing examples. They reveal habits that carry into real deployments: weak authentication, insecure defaults, and systems that rely on obscurity rather than robust protection.
GitHub is not the problem; it simply mirrors how industrial engineers work. Many configurations still assume a trusted environment, even when that no longer matches reality.
The Most Concerning Finding: Public‑Facing SCADA Interfaces
Phase 4 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.
- Accessible through a public IP
- Served over HTTP (no TLS encryption)
- Displaying the full Ignition Gateway sign‑in form
- Showing the host identifier of the Windows server running it
This does not necessarily mean the system is critical, nor that anyone could log in, but it confirms that a SCADA system expected to be internal‑only ended up exposed to the public internet—a scenario that should never happen unintentionally.
I also discovered an unrelated remote‑access login on port 8105. It presented a browser‑based credential prompt over HTTP. Such interfaces often belong 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 just compromise data—it compromises equipment, stability, and uptime.
The issues identified reflect real operational trends:
- More industrial devices are connected to networks each year.
- More systems rely on remote access for support.
- Legacy devices still assume isolation that no longer exists.
- 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 are tightening requirements across NERC, FERC, DOE, and state‑level oversight bodies.
The energy sector can no longer treat 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 but 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 d