Introduction
Industrial control systems and SCADA environments were not originally designed for direct internet visibility. In sectors such as electricity, building automation, transport, and industrial operations, many legacy protocols still reflect older assumptions: isolated networks, trusted communications, and limited external exposure. Today, those assumptions are much weaker. Operators are expected to manage systems that combine decades-old industrial technologies with modern IP connectivity, remote access requirements, and growing cybersecurity obligations.
That creates a broader and more important question than any single protocol:
How much operational technology is actually visible on the public internet, and how much of what we see is real rather than measurement noise?
This post approaches that question from the perspective of electricity and industrial control system security, using IEC 60870-5-104 (IEC-104) as a concrete example. IEC-104 is particularly relevant because it remains widely used in European telecontrol and power-system environments, making it a useful lens through which to examine the wider problem of internet-exposed operational technology.
The analysis summarized here is based on a passive Shodan-based measurement exercise conducted in March 2026. The goal was not to identify individual targets for public disclosure, and not to prove exploitability. The goal was narrower and more useful: to understand whether internet-visible industrial control exposure should still be treated as a meaningful operational issue, and how carefully it must be measured.
The short answer is:
Naive raw counts are misleading. But after filtering, a real and persistent protocol-confirmed subset remains.
That matters for defenders, researchers, and policy people alike.
Why this matters beyond a single protocol
Although this article uses IEC-104 as the main example, the broader issue is not limited to one port or one protocol family. In practical OT security work, internet-visible industrial assets often appear alongside other legacy services, remote management interfaces, and building automation platforms. The real lesson is wider: defenders need better ways to identify true industrial exposure, separate meaningful signals from noise, and understand when visibility reflects genuine operational risk rather than superficial scan artifacts.
That is especially relevant in the electricity sector, where telemetry and supervisory communications remain closely tied to real physical processes.
A practical note from Latvia-focused verification work
This passive analysis did not happen in isolation. In parallel with broader responsible disclosure work, a Latvia-focused verification stream reviewed 174 public IPs derived from Shodan-led reconnaissance. Of these, 116 were assessed as real OT or industrial targets, while 58 were excluded as VPS, hosting systems, or honeypots. Verification was limited to safe checks such as reachability, version confirmation, and read-only probing. No exploitation was attempted, and no target data was modified.
That work also led to multiple coordinated vulnerability disclosure reports and incident reporting to CERT.LV. Across the broader stream, the findings included 5 critical, 3 high, and 2 medium-high cases, plus 1 active incident requiring incident-style handling rather than normal disclosure. The reported issues were not abstract: they included internet-exposed industrial serial gateways with authentication effectively disabled, vulnerable building-management platforms in hotel and supermarket environments, municipal Modbus exposure, SNMP-leaking industrial HMI infrastructure, and one OT device showing signs of botnet compromise. In practical terms, this means the observed exposure was not limited to generic “open ports”, but extended to systems that could plausibly affect heating, ventilation, refrigeration, building automation, and downstream industrial field devices if left unmanaged.
That matters for two reasons. First, it shows that public ICS measurement has a real filtering problem: not everything that looks industrial is industrial. Second, it shows that passive measurement can still support meaningful disclosure and defensive prioritization when used carefully.
Why raw port counts are misleading
A common first instinct is to search for port 2404 and treat the result as “IEC-104 exposure.” In practice, that is too simplistic.
In this March 2026 passive dataset, the raw Shodan count for port 2404 was very large. But raw port-based counts should not be interpreted as true IEC-104 population estimates. Port reuse, misclassification, unrelated software, and environmental noise all distort the picture.
To get a more meaningful view, a smaller set of 171 full host lookups was reviewed and classified into confidence tiers.
Confidence tiers used in this analysis
- C0 — Honeypot or error: 32 hosts (19%)
- C1 — False positive: 32 hosts (19%)
- C2 — Contextual / ICS-adjacent: 37 hosts (22%)
- C3 — Protocol-confirmed IEC-104: 70 hosts (41%)
The most important result here is that roughly 37% of the sampled port-2404 results were not IEC-104 at all, including cases associated with Remcos RAT C2 or other non-IEC-104 services.
This is the key lesson of the measurement:
Port number alone is not enough.
That is not only a Shodan problem. It is a broader methodological lesson. If we want to understand industrial protocol exposure correctly, we need protocol-specific evidence rather than generic assumptions.
A lower-bound view still shows real exposure
Rejecting raw counts does not mean the problem disappears.
Even after filtering out honeypots, errors, and likely false positives, a meaningful protocol-confirmed subset remained. In this sample, 70 results were classified as C3, meaning protocol-confirmed IEC-104 based on Shodan scanner evidence.
This is a lower-bound view, not a full census. But lower bounds are often more useful than inflated totals, because they are easier to defend analytically.
The practical takeaway is straightforward:
- raw counts overstate the problem,
- but careful filtering does not reduce the issue to zero,
- and protocol-confirmed IEC-104 exposure remains visible in the wild.
That is enough to justify defensive attention.
Persistence matters more than a single snapshot
A one-day internet exposure snapshot can always be dismissed as temporary noise. Systems come and go. Addresses change. Some banners are stale. Some observations are one-off.
That is why persistence is more important than peak count.
In the available Shodan history window, about 57% of protocol-confirmed C3 results were observed across multiple crawl days. Because the available history depth was limited, this should be treated as a lower bound on persistence, not a complete lifetime estimate. No result exceeded the visible history ceiling, but that ceiling reflects data availability rather than true maximum exposure duration.
Even so, the result is useful:
- a meaningful share of protocol-confirmed results were not visible only once,
- repeated observation suggests at least some of this exposure is persistent rather than accidental,
- persistent exposure is much more relevant for operational risk management than a transient appearance.
This is where the story becomes more than interesting scan output. Persistence suggests governance and hygiene problems, not just statistical curiosity.
Geographic concentration is real, but raw country counts need context
Simple country rankings are often misleading because large countries naturally produce larger raw counts. That is why normalization matters.
In the normalized view of this dataset, Belarus rose to the top, with Turkey also remaining very high, while China dropped substantially compared to its raw-count position. That suggests the observed concentration is not explained only by country size.
This does not prove that all visible results belong to critical national infrastructure, and it does not justify simplistic geopolitical conclusions. But it does suggest that the concentration of likely IEC-104 exposure aligns with regions where IEC-104 deployment is operationally plausible.
That matters because it moves the conversation away from abstract protocol insecurity and toward real deployment geography.
Co-exposure shows that the issue is often not IEC-104 alone
Another useful question is not just “How many IEC-104 results are visible?” but also:
“What else is visible on the same IPs?”
Within the protocol-confirmed C3 subset, the same IPs often exposed additional services, including roughly:
- HTTPS / HTTP: about 67–69%
- VNC: about 60%
- SSH: about 50%
- Telnet: about 29%
These values should be treated carefully. Some are likely inflated by cloud-like or honeypot-like hosts with large service inventories. Even so, the broader pattern is important.
The risk is often compound exposure, not IEC-104 in isolation.
For defenders, that matters because a protocol can sit within a larger exposed management environment. From a practical standpoint, an externally visible telecontrol protocol alongside remotely reachable administration services creates a different defensive problem than an isolated industrial port alone.
That is another reason why plain service counting is not enough. Context matters.
Metadata leakage is uneven, but still meaningful
Most of the sampled results did not reveal rich identifying metadata. In itself, that is a useful result. It means the public internet is not always giving away product, hostname, or operator context as easily as some scan narratives suggest.
At the same time, a non-trivial minority of results did disclose useful context such as hostname, product clues, or version hints. Even modest metadata leakage can improve attacker reconnaissance and prioritization.
The measurement takeaway is therefore balanced:
- most visible results are not trivially self-identifying,
- but some still leak enough information to make prioritization easier,
- and defenders should treat metadata reduction as part of attack-surface management.
What this means for defenders
The point of this analysis is not to argue that every visible result is immediately exploitable. Passive measurement cannot prove that. But defenders do not need exploit proof to conclude that unnecessary exposure is a problem.
This dataset suggests five practical lessons.
1. Remove direct exposure where possible
IEC-104 and similar operational services should not be directly internet-facing unless there is an exceptional, carefully justified reason. Segmentation, VPN-based access, and controlled jump points are preferable.
2. Do not trust raw counts
If you are measuring industrial protocol exposure, do not equate open port counts with real protocol populations. Validation and classification matter.
3. Treat persistence as a priority signal
A result visible across repeated observations is more operationally important than a one-off appearance. Long-lived exposure should be triaged first.
4. Look for compound exposure
The presence of HTTP, SSH, VNC, Telnet, or other services on the same IP can change the defensive picture substantially.
5. Monitor the protocol itself, not only the perimeter
This is the deeper lesson. Even when exposure is reduced, industrial defenders still need protocol-aware monitoring inside operational environments. Perimeter hygiene helps, but it does not replace visibility into the behavior of IEC-104 traffic itself.
Why this matters for research
One reason these findings matter is that they reinforce a broader methodological point relevant to industrial cybersecurity research.
In this dataset, generic signals were not enough. Port 2404 alone produced too much noise. Better confidence required protocol-specific evidence and context.
That same reasoning appears in defensive monitoring more generally. If we want to understand or detect IEC-104-related activity reliably, generic indicators alone are often too weak. Protocol-aware analysis is stronger because it uses the actual structure and semantics of the protocol rather than only broad network-level hints.
This does not mean Shodan classification and intrusion detection are the same task. They are not. But they do share the same underlying lesson:
Protocol-specific understanding beats generic guessing.
That is useful not only for internet measurement, but also for the design of explainable, deployment-ready detection methods in critical infrastructure environments.
Limitations and ethics
This work was passive only. No active probing, exploitation, authentication attempts, or intrusive validation were performed for this public analysis.
Several limitations must be kept in mind:
- Shodan data is not ground truth.
- Port-based search results include false positives.
- Banner data can be incomplete, stale, or ambiguous.
- Country and organization attribution can be imperfect.
- Co-exposure counts may be inflated by cloud-like or honeypot-like systems.
- Visible duration in Shodan should be treated as a lower bound, not proof of continuous exposure.
- Passive observation does not prove exploitability or operational criticality.
Because of these limitations, the numbers here should be read as attack-surface measurement, not as a list of confirmed vulnerable systems.
That distinction matters.
Key takeaways at a glance
The overall message of the measurement can be summarized simply:
- raw port-based counting is noisy,
- a substantial share of sampled results were not IEC-104,
- a protocol-confirmed subset remained after filtering,
- and many confirmed results appeared across multiple observation days.
Conclusion
So, is internet-exposed ICS and electricity-related operational technology in 2026 a real problem, or mostly measurement noise?
The answer is: both, but not equally.
The raw picture is noisy enough that naive port counts are not trustworthy. A large part of what appears industrial at first glance is not what it seems. That is an important result on its own.
But once filtered, a protocol-confirmed subset remains. Some of it appears persistent across multiple observation days. Some of it coexists with additional exposed services. Some of it leaks useful metadata. Taken together, that is enough to say that exposed industrial protocol services remain a meaningful operational concern.
The right response is not panic, and not exaggerated target counting. The right response is better measurement, better segmentation, and better protocol-aware monitoring.
That is the real lesson of this exercise.
Author note
This article is part of broader research and practical work on IEC-104 security, explainable intrusion detection, and operational deployment in critical infrastructure environments. The public analysis presented here is passive, aggregated, and intended to improve understanding of industrial attack-surface measurement rather than to expose individual operators.