The Open Door
Industrial control systems run the unglamorous, essential machinery of modern life. Power grids, water treatment, district heating. And far too many of them are still defended like it's 1979.
TL;DR: Thousands of industrial control systems are accessible directly from the internet. Many still run Modbus, a protocol from 1979 with no authentication or encryption. It's not a theoretical problem - it's searchable, and people have used it to shut down heating systems.
The Screenshot
Ten minutes on Shodan. That's all it takes to go from "random IP somewhere in Eastern Europe" to "I am looking at the remote edge of a real industrial environment." A Teltonika Networks device in Vilnius, Lithuania, tagged with ics and self-signed. Two open ports: 443 and 502. That second one should make anyone in OT security sit up straight. Port 502 is the standard port for Modbus TCP – one of the oldest industrial protocols still in widespread use, and one of the least defensible.
No zero-day, no spy thriller, no elite red team. Just an indexed device on the open internet, a search engine for exposed services, and a protocol that still assumes every packet arrives from a trusted factory floor.
This article is about that gap: the world Modbus was designed for versus the one it actually lives in now. A 46-year-old protocol with no built-in security, influencing pumps, breakers, valves, heating loops, and things that move.
What ICS Is
Industrial Control Systems is the umbrella term for the digital machinery that controls physical processes. Electric substations, water treatment plants, district heating, manufacturing lines, pipelines, transport infrastructure. Under that umbrella sit SCADA (geographically distributed systems), DCS (more localized processes), and PLCs – the rugged controllers wired into motors, relays, sensors, and valves.
For decades, these systems weren't designed for hostile networks. They ran on isolated serial links or tightly controlled plant networks where reliability mattered more than confidentiality. The assumed threat was equipment failure, not a stranger on the internet. That history explains a lot of the current mess: the protocols survived, the networks changed, the assumptions didn't catch up.
Port 502
Modbus TCP lives on port 502. Registered default. Port scanners test it first. If you find it exposed on a public IP, that's a problem. Sometimes vendors or operators shuffle Modbus to a different port hoping to hide it. That doesn't fix anything. Port 502 is still the front door.
Modicon designed Modbus in 1979 for communication between devices in trusted environments. Simplicity and uptime were the goals. Not identity, secrecy, or tamper resistance. Classic Modbus TCP doesn't include authentication, doesn't encrypt traffic, and doesn't provide message integrity. If a device can reach a Modbus server and format a valid request, the server obeys.
Practically: someone who can talk to port 502 may be able to flip a pump, change a setpoint, or falsify the values an operator is reading. No authentication means anyone can talk. No encryption means anyone on the path can listen. No integrity controls means replaying or modifying traffic is far easier than it should be in any system that touches the physical world.
That model made sense on a cabled plant floor in 1979. In 2026, on globally routed IP networks full of scanners, opportunists, and state-backed actors, it's absurd. Exposing raw Modbus TCP to the internet isn't a nuanced risk decision. It's the industrial equivalent of leaving the control room unlocked and hoping nobody curious wanders in.
Shodan
"Google for devices" undersells it. Shodan indexes services, not web pages. It scans address space, records banners, indexes ports, and tells you what kind of equipment answered and where. For internet-facing OT, exposure isn't obscure anymore. It's searchable.
The scale became measurable. Forescout had roughly 110,000 internet-facing ICS/OT devices in early 2024. SecurityWeek, citing Censys: 145,000 exposed ICS systems across 175 countries by late 2024. Different groups count differently. They all point the same direction.
The Router Is Not a Safe Boundary
One of the more persistent myths in OT is that the industrial router itself is the security strategy. Put a rugged little box at the edge, maybe give it LTE and a web UI, and somehow the plant feels protected. In practice, that box is often just another attack surface. Sometimes a very convenient one.
For Teltonika specifically: in 2023, researchers disclosed multiple vulnerabilities affecting RUT-series devices and the Remote Management System, including paths that could enable remote compromise. National cybersecurity agencies and vendors issued advisories. Teltonika published fixes. The lesson: the thing standing between your ICS and the public internet can itself be the intrusion point.
Back to that screenshot. An exposed router with a management interface and an industrial protocol behind it isn't "observability." It's stacked risk: edge exposure, possible device-level weaknesses, and a legacy protocol downstream that still assumes trust.
The Air Gap Myth
ICS security leaned on a comforting phrase for years: air gap. The idea was simple – if the control network is isolated, the attacker can't reach it. In the era of vendor remote access, cloud dashboards, engineering laptops, LTE backhaul, outsourced maintenance, and business systems that want live plant data, that assumption is more folklore than architecture.
Modern operations want IT/OT convergence because it delivers real value: telemetry, predictive maintenance, remote diagnostics, tighter planning. Every extra connection creates more routes into environments that weren't designed to defend themselves. Even without a formal convergence plan, accidental convergence happens through convenience: a contractor laptop, a forgotten modem, a remote management tunnel, a USB stick, a firewall rule that nobody closes.
Stuxnet is the reminder that "not internet-connected" isn't the same as "secure." It reached Iran's Natanz facility through removable media, manipulated Siemens PLC logic tied to uranium centrifuges, and caused physical damage while feeding operators normal readings. The air gap didn't fail because of some clever exploit. It failed because real operations involve humans, maintenance workflows, and trusted devices that move between worlds.
Where the Blame Really Lives
The easy instinct is to find one villain. Modbus, obviously – it's a trust-based protocol from 1979 that still behaves like one. Operators, sure – remote access is convenient, segmentation takes effort, and changing default credentials is a meeting nobody wants to schedule. And vendors, of course – the rugged box at the edge doesn't automatically mean rugged security.
Modbus is the obvious target. It's a trust-based protocol from 1979, and it still behaves like one. No authentication, no encryption, no replay protection. But it can't fix itself, and the real question is why deployments keep giving it modern exposure.
Then there's the operator side. Remote access is convenient. Segmentation takes effort. Default credentials stay because changing them is a meeting nobody wants to schedule. Modbus can be wrapped, filtered, and segmented. It mostly isn't.
And vendors. The rugged box at the edge doesn't automatically mean rugged security. Routers, gateways, and remote management platforms have shipped with flaws that undermine otherwise reasonable architectures. When the edge device is weak and the protocol assumes trust, compromise stops being surprising.
When It Goes Wrong
ICS insecurity is different from regular IT insecurity. The outcome isn't a leaked database or a trashed server. These systems move matter. When they fail, the consequences are mechanical, environmental, and human.
Stuxnet (2010)
The one that made the world pay attention. Siemens S7 PLCs at Iran's Natanz uranium facility, manipulated to degrade centrifuge performance while operators saw normal readings. Stuxnet didn't breach the network – it came in on removable media. Someone plugged in a USB stick.
But what Stuxnet actually proved was simpler: ICS wasn't too obscure to target, and it wasn't too isolated to reach. Once that became clear, attackers started paying attention.
Ukraine (2015, 2016)
December 2015: attackers worked through utility systems and manually opened breakers to cut power. Operators watched their own systems being driven away from them in real time. The 2016 version, CRASHOVERRIDE, codified the same tradecraft into malware. What had been careful operator-driven abuse became more automated, repeatable, scalable.
TRITON (2017)
Schneider Electric Triconex Safety Instrumented Systems at a petrochemical plant in the Middle East. These are the systems meant to shut things down when something goes badly wrong. The target wasn't process uptime. It was the last line of defense.
The campaign was uncovered after an operational error triggered an unexpected shutdown. The plant found the attackers because the attack tripped over itself. That's not a security win.
FrostyGoop (2024)
January in Lviv. Cold enough that district heating isn't a luxury. Somewhere in the utility environment, a small Windows malware sample starts doing something almost insultingly simple: it speaks Modbus over port 502.
600 apartment buildings without heat for about 48 hours. 100,000 residents in winter conditions. The malware didn't need a zero-day chain. The protocol already trusted whoever could reach it. No dramatic payload – just valid-looking industrial commands to systems built to obey them.
The consequence was literal: radiators went cold, taps ran icy. Residents found out that a protocol older than some of the buildings it serves was still deciding whether winter stayed outside.
The Numbers
ICS vulnerabilities hit record highs in 2025, with advisories crossing 500 and average severity going up. That part's probably stale by the time you read this. The trajectory hasn't changed.
On exposure: Forescout put internet-facing ICS/OT devices at around 110,000 in early 2024. SecurityWeek, citing Censys data, had 145,000 across 175 countries by late 2024. The exact numbers are moving targets. The direction isn't.
The Short List of Mistakes
| Mistake | Why it keeps happening | Why it matters |
|---|---|---|
| Exposing port 502 to the internet | Remote access is convenient, legacy systems are awkward to modernise | Modbus TCP has almost no native security. Exposed services are easy targets. |
| Treating the industrial router as "the security layer" | Rugged edge gear creates a false sense of containment | Router and management-plane flaws can become the bridge into OT. |
| Believing in the air gap after adding remote access | Operations need telemetry, support, and cloud visibility | IT/OT convergence and convenience links quietly erase isolation. |
| Keeping default or weak credentials nearby | Password hygiene is often secondary in OT operations | Weak edge credentials compound protocol insecurity and enable lateral movement. |
| Running unpatchable legacy controllers without compensating controls | Replacement is expensive, downtime is hard to justify | Old systems stay exposed long after their security assumptions are obsolete. |
What to Actually Do
No magic fix for decades of accumulated mess, but there's a floor. Below it, no serious operator should fall.
- If Shodan can see port 502 on your external range, you're already in trouble. Publicly reachable Modbus TCP is an operational failure, not a hardening backlog.
- No raw Modbus over the internet. If it must cross a wide-area link, tunnel it inside something with actual authentication. Better: terminate industrial traffic internally and expose only mediated services upstream.
- Segment. IT from OT. Within OT: safety systems, control systems, engineering workstations, and field devices should not share a blast radius.
- Put controls in front of critical systems that understand industrial protocols. Industrial firewalls that know Modbus function codes beat generic perimeter boxes that only see port numbers.
- Know what actually speaks industrial protocols on your network. A surprising amount of OT insecurity starts with nobody knowing which devices are reachable and from where.
- Scan your own external exposure the same way an attacker would. If you can find it with Shodan or Censys in under ten minutes, assume someone already has.
- Some hardware can't be patched and won't ever be. When that's the case, architecture is the control: gateways, one-way flows, aggressive access limitation.
The easy wins are unglamorous: close 502 on the WAN side, kill default credentials, disable unnecessary remote services, actually review what's exposed. The hard wins are architectural and require downtime somebody has to schedule and pay for.
Why this isn't a curiosity
That device in the screenshot isn't interesting because it's rare. It's interesting because it's ordinary. Across power, heating, water, transport, and manufacturing, similar devices are sitting exposed every day, fronting systems that still rely on protocols designed for a plant floor that no longer exists.
FrostyGoop wasn't sophisticated. It succeeded because the industry keeps giving old, trusting protocols modern exposure and hoping habit will make up the difference. The question stopped being "can this be manipulated?" years ago. Real incidents answered that.
The actual question is how many environments would survive being looked at hard tomorrow. If a stranger can find port 502 from a search bar, and a threat actor can reach equipment that still assumes every valid packet is friendly – it's not a theoretical problem. It's live, searchable, and connected to things that can break.