An exposed Modbus service is not just an open port. It’s an industrial device, gateway, or control-adjacent system that is reachable from networks where it was never meant to be visible.

As of May 2026, internet-wide scanning identifies over 30,000 Modbus-speaking devices on TCP port 502, responding to standard Modbus function codes from any source IP. No credentials required. No TLS. No authentication of any kind.

That number comes from our own scan data, cross-validated across independent sources. And the banners these devices return don’t just confirm the protocol. They expose manufacturer names, PLC model numbers, firmware versions, project names, and last-modified timestamps.

The question isn’t whether Modbus is insecure. Everyone knows that. The question is how many devices are sitting on the public internet right now, what they’re revealing about themselves, and who owns them.

Modbus in 30 Seconds

Modbus was designed by Modicon in 1979 for serial communication between PLCs. Modbus TCP, its Ethernet variant, runs on port 502 and has been a standard in industrial environments for decades.

It was built for isolated networks. There is no authentication mechanism in the protocol. There is no encryption. Any device that can reach a Modbus TCP endpoint can read holding registers, write coils, and query device identification data. The protocol simply does what it’s asked.

That wasn’t a problem when Modbus lived on air-gapped plant networks. It becomes a serious one when these devices are reachable from the public internet.

Modbus is still everywhere: power metering, water treatment, building HVAC, solar inverters, manufacturing PLCs, and remote telemetry units. Its longevity is a function of simplicity and reliability. Replacing it isn’t trivial, and for many operators, it hasn’t been a priority.

How Many Modbus Devices Are Internet-Exposed?

To get a reliable count, we ran parallel queries against two independent internet scanning platforms, each using different probes and scanning schedules.

Method	Count
——–	——-
Primary scan: port 502, Modbus Unit ID in banner	30,434
Primary scan: port 502, Device Identification in banner	27,110
Cross-validation scan: port 502, protocol-confirmed Modbus	27,923

The two platforms converge within roughly 9%, which is expected given differences in probe methodology, timing, and response classification. The convergence gives us reasonable confidence that the actual population of internet-facing Modbus endpoints is in the range of 28,000 to 31,000 devices.

Not all of these are real industrial equipment. We’ll address honeypots below.

Geographic Distribution

The United States accounts for the largest share at 16.3%, but this is a global problem. Ten countries each have more than 1,200 exposed Modbus services.

Country	Count	Share
———	——:	——:
United States	4,975	16.3%
South Korea	3,309	10.9%
Spain	2,110	6.9%
Italy	1,795	5.9%
Turkey	1,739	5.7%
Sweden	1,725	5.7%
France	1,515	5.0%
Lithuania	1,337	4.4%
Germany	1,311	4.3%
China	1,289	4.2%
Taiwan	969	3.2%
Canada	680	2.2%
Poland	633	2.1%
Romania	490	1.6%
Japan	462	1.5%

South Korea’s position at number two is notable. Nearly all of those 3,309 devices are registered to Korea Telecom (2,970), suggesting a large cellular-connected or broadband-connected device population, likely industrial telemetry or building automation systems using mobile data connections.

Turkey shows a similar pattern. Of 1,739 exposed devices, 1,341 sit on Turkcell’s mobile network. Lithuania’s 1,337 devices are largely on Bite Lietuva, another mobile carrier. These patterns suggest industrial devices connected via cellular gateways with public IP addresses and no firewall between the device and the internet.

What the Banners Reveal

This is where the exposure goes from “open port” to “identified industrial asset.”

When an internet scanner probes a Modbus service, it sends standard function codes: Read Device Identification (FC 43/14) and Report Slave ID (FC 17). Devices that respond to these requests hand back structured data about themselves.

Of the 30,434 devices, 27,110 respond with Device Identification data. The top ten product identifiers paint a clear picture of what’s out there:

Product	Count	What It Is
———	——:	————
BMX P34 2020	842	Schneider Electric Modicon M340 CPU module
TM221CE40R	187	Schneider Electric Modicon M221 PLC (40 I/O, relay)
TM221CE40T	181	Schneider Electric Modicon M221 PLC (40 I/O, transistor)
TM221CE16T	157	Schneider Electric Modicon M221 PLC (16 I/O)
TM241CE40T_U	149	Schneider Electric Modicon M241 PLC
TM221CE24T	137	Schneider Electric Modicon M221 PLC (24 I/O)
Conpot	132	Honeypot (not a real device)
TM241CE24T_U	131	Schneider Electric Modicon M241 PLC
TM251MESE	109	Schneider Electric Modicon M251 PLC
TM221CE16R	99	Schneider Electric Modicon M221 PLC (16 I/O, relay)

Schneider Electric dominates the identifiable device population. Across all Schneider-identified banners, we found 2,940 devices. That’s not a Schneider-specific vulnerability. It’s because Schneider’s Modbus implementation returns detailed Device Identification responses by default. Other vendors’ devices may respond to Modbus but return less identifying information, making them harder to fingerprint.

ABB devices account for another 632, though the org distribution for those skews heavily toward cloud hosting providers (Linode, Alibaba Cloud), which suggests many are honeypots or simulation environments rather than field-deployed hardware.

What Banners Actually Look Like

Here’s a sanitized example of what an internet scanner sees when it probes a real exposed Modbus device. The IP address and exact location are redacted, but this is the type and detail of information returned:

Unit ID: 0
-- Device Identification: Schneider Electric BMX P34 2020 v2.5
-- CPU module: BMX P34 2020
-- Memory card: BMXRMS008MP
-- Project information: [project name] V4.1 [workstation name]
-- Project revision: 0.5.168
-- Project last modified: 2026-02-26 09:19:00

That single response tells a remote observer:

• The vendor and exact model: Schneider Electric Modicon M340
• The firmware version: v2.5
• The memory card installed: BMXRMS008MP
• A project name that may reference the facility or process
• The workstation name of the engineer who last programmed it
• A project revision and last-modified date, confirming the device is actively maintained

This is not theoretical information leakage. This is what the device returns to anyone who sends the right Modbus function code to its public IP address.

Another banner from Turkey shows a power analyzer:

Unit ID: 1
-- Device Identification: ENTES ELEKTRONIK CIHAZLAR IMALAT VE TICARET AS.
   MPR-47S HW 01.01.01

And from Sweden, a building HVAC controller:

Unit ID: 0
-- Device Identification: AB Regin

PM710 power meters, RTUs on Canadian mobile networks, libmodbus-based custom implementations in Italy. The device diversity is wide.

Who’s Hosting These Devices?

Knowing the countries is useful. Knowing the network operators is more telling, because the ISP data reveals how these devices ended up on the internet in the first place.

Organization / ISP	Count	Likely Explanation
——————–	——:	——————-
Korea Telecom	2,970	Mobile/broadband-connected devices in South Korea
Verizon Business	2,247	Cellular M2M or enterprise broadband in the US
Turkcell Internet	1,341	Mobile-connected devices in Turkey
Telefonica de Espana	1,059	Fixed/mobile broadband in Spain
Telia Network Services	815	Nordic broadband/mobile
Bite Lietuva	796	Mobile network in Lithuania
Cogent Communications	688	Enterprise transit/hosting in the US
Vodafone Italia	627	Mobile-connected devices in Italy
Chunghwa Telecom	607	Broadband in Taiwan
Aliyun / Alibaba Cloud	~730	Cloud-hosted (likely honeypots or simulations)

Two things stand out.

First, mobile carriers dominate. Korea Telecom, Turkcell, Bite Lietuva, Vodafone Italia, Telia. These are cellular networks. The pattern suggests industrial devices connected through cellular routers or gateways with public IP assignments and no network-level access control. This is common in remote monitoring: a solar inverter, water pump, or power meter with a 4G modem plugged into it for telemetry.

Second, cloud hosting providers appear in meaningful numbers. Alibaba Cloud, Linode, Cogent, and Hurricane Electric together account for well over 1,000 services. Some of these are legitimate protocol gateways or data aggregation services. Many are likely honeypots or research nodes. We found 132 devices that explicitly identify as “Conpot” in their banners, but the real honeypot count is certainly higher.

The Verizon Cluster

Verizon Business alone accounts for 2,247 Modbus endpoints, nearly all in the United States (2,247 US, 1 Puerto Rico). This is one of the largest single-ISP concentrations in the dataset.

Verizon Business provides cellular M2M connectivity and enterprise broadband services commonly used by utilities, energy companies, and large facility operators. A Modbus endpoint on a Verizon Business IP likely represents a remote monitoring device, a cellular-connected RTU, or a substation gateway.

What Attackers Can Do with Exposed Modbus

Modbus has no concept of identity. Any TCP connection to port 502 can issue any function code. For an exposed device, this opens up a progression that mirrors how an attacker would actually work.

Start with reconnaissance. FC 43 returns vendor, product, model, and firmware. Without writing a single value, an attacker can build a precise inventory of the target: what brand of PLC, what firmware version, what project is loaded.

Then read the process data. Holding registers and input registers contain live process values: voltage, current, flow rate, temperature, pressure, valve positions, setpoints. The device will not log or alert on these reads. From its perspective, a read from an unknown IP looks the same as a read from the local HMI.

Then, if the goal is disruption, write. Function codes 5, 6, 15, and 16 allow writing to coils and holding registers. On a PLC, this can change physical outputs. On a power meter, it can alter configuration. On a gateway, it can modify forwarding behavior. The protocol doesn’t verify who is writing or whether the write makes sense.

FrostyGoop: Modbus as a Weapon

In January 2024, the FrostyGoop malware was used against a municipal energy company in Lviv, Ukraine, causing a 48-hour heating outage during sub-zero temperatures. The malware communicated directly with ENCO controllers using Modbus TCP, sending commands to manipulate heating system setpoints. [Source: Dragos, “FrostyGoop ICS Malware Analysis,” July 2024]

FrostyGoop was significant for several reasons:

• It was the first publicly documented ICS malware to use Modbus TCP as its primary command channel
• It targeted the protocol itself, not a vendor-specific vulnerability
• It worked because the Modbus endpoints were network-reachable without authentication
• The controllers simply executed the commands they received, as Modbus is designed to do

The 30,000+ devices in our scan data respond to the same function codes FrostyGoop used.

Scanning Activity Is Increasing

In early 2025, Cato Networks documented a coordinated Modbus scanning campaign: over 14,000 unique source IPs generated 235,500 Modbus probe requests targeting systems across 70 countries over several days. [Source: Cato Networks, CTRL Threat Research, 2025]

This was not opportunistic. It was systematic mapping of the Modbus attack surface, the same surface our scan data reflects.

The Honeypot Problem

Any count of exposed Modbus devices needs a caveat: some are honeypots.

Conpot, the most widely deployed ICS honeypot, emulates Modbus among other protocols. In our data, 132 devices identify themselves as “Conpot” in the product field. But Conpot’s default configuration mimics a Siemens S7-200 or Schneider device. Modified Conpot instances won’t self-identify.

We also see meaningful clusters on cloud hosting providers (Alibaba Cloud, Linode) where the “devices” are almost certainly not physical industrial equipment. Adding cloud-hosted totals to the explicit Conpot count, a conservative estimate is 300 to 500 honeypots in the dataset.

Subtracting the high end from the total: roughly 30,000 real Modbus endpoints are internet-exposed.

This is consistent with how Dragos, Censys, and Bitsight have reported similar figures in their respective industry analyses. [Source: Verify against Dragos OT Cybersecurity Year in Review 2024, Censys Internet Exposure Reports, Bitsight ICS Exposure Research]

The Ones Hiding on Other Ports

The 30,000 figure only counts port 502. But not all Modbus services run on the standard port.

We found another 431 devices with Modbus banners on non-standard ports. The top ports tell their own story: 21 (FTP, 107 instances), 1883 (MQTT, 73 instances), 5353 (mDNS, 42 instances), and 8081 (HTTP alt, 20 instances). Some of these are protocol gateways that bridge Modbus to web or MQTT interfaces. Others may be running Modbus on an alternate port as a form of security through obscurity. Either way, they’re discoverable through banner matching, and the same zero-authentication risk applies.

Poland stands out here, accounting for 108 of these non-standard-port Modbus services, more than any other country in this subset. If you’re only scanning port 502, you’re missing part of the picture.

What Defenders Should Look For

If you’re responsible for OT security at an organization that uses Modbus in any capacity, the starting point is knowing what’s visible from the outside.

That means inventorying your internet-facing IP space, and not just the ranges in your CMDB. Include cellular M2M SIMs and broadband connections at remote sites. Scan for port 502 from outside your network, or use an external attack surface management tool to do it continuously.

When you find an open port, go deeper. A port scan that shows 502/open doesn’t tell you whether a real Modbus device is behind it. Send a Read Device Identification request. If you get a vendor and model back, you have an exposed industrial device. If you don’t, you may still have a gateway or relay that accepts Modbus commands.

Pay special attention to cellular-connected devices. Our data shows that mobile carriers are the most common path for Modbus exposure. Devices connected via 4G/5G routers often get public IPs by default. If the router doesn’t have a firewall rule blocking inbound traffic on 502, the device is exposed. This is the single most frequent pattern in our dataset.

Also look beyond what you know about. Shadow OT is real. A facilities team installs a power meter with a cellular modem for remote monitoring. A vendor sets up a VPN that also exposes the Modbus port. An HVAC contractor connects a controller to the building network that routes to the internet. None of these appear in your CMDB, and nobody files a change request.

Finally, check what your devices are telling the world. If your Modbus devices are returning project names, workstation identifiers, and last-modified dates in their Device Identification responses, that information is available to anyone who probes them. Some devices allow disabling these responses. Others don’t.

Reducing Exposure

The fix is straightforward in concept, harder in practice:

• Network segmentation. Modbus devices should not have routable paths to the internet. This is the single most effective control.
• VPN or encrypted tunnels for remote access. If an operator needs to reach a Modbus device remotely, that connection should go through an authenticated, encrypted channel.
• Firewall rules on cellular routers. Block inbound connections on port 502 (and ideally all unsolicited inbound traffic) at the cellular gateway level.
• Modbus TCP security wrappers. Some vendors offer TLS wrappers or Modbus/TCP security extensions (per IEC 62351). Adoption is low but growing.
• Continuous external monitoring. A device that wasn’t exposed yesterday can become exposed today when a router reboots, a firewall rule changes, or a new SIM card is provisioned. Point-in-time checks miss this.

How External Scanning Finds What Internal Tools Miss

Internal network monitoring tools see traffic inside the plant network. They’re good at detecting anomalous commands between devices that are already known. But they have a blind spot: they can’t tell you what the internet sees.

An exposed Modbus device may be functioning normally from the plant’s perspective. The PLC runs its logic, the HMI shows green, the historian logs data. Nothing inside the network looks wrong. But from the outside, that device is responding to Modbus probes from arbitrary source IPs.

External attack surface management, the approach ShiftSix Security uses, works from the attacker’s perspective. It scans the internet-facing surface, identifies Modbus endpoints, fingerprints devices by protocol response, and maps them to organizations by IP ownership. This is how we built the dataset in this article.

The value for defenders is closing the gap between “what we think is exposed” and “what actually is.” In our experience, the second number is usually larger.

For a broader look at how this practice works across all industrial protocols, see What Is OT Exposure Management?.

The Takeaway

Roughly 30,000 Modbus devices are reachable from the public internet right now. They span 50+ countries, sit on mobile carrier and enterprise networks, and return detailed information about their make, model, firmware, and configuration to anyone who asks.

This isn’t new. Modbus has been insecure since 1979. What’s changed is the scale of connectivity. Cellular M2M, cloud-connected gateways, and remote monitoring have put thousands of devices on public IPs that were never designed to face the internet.

The fixes are known. Network segmentation, firewall rules, VPN tunnels, and continuous monitoring. The challenge is knowing which devices are exposed in the first place.

That’s the part most organizations get wrong. They assume their network segmentation is working. They assume the vendor configured the cellular router correctly. They assume the contractor didn’t leave a port open. Our data suggests those assumptions don’t hold up at scale.

Get weekly OT exposure research and analysis. Subscribe to the OT Exposure Briefing newsletter.

This analysis is based on data collected in May 2026 using multiple internet scanning platforms and cross-validated across independent sources. All data comes from existing public indexes. IP addresses and identifying details of specific organizations are excluded.

This Modbus analysis covers one of seven OT protocols examined in our research. For the complete multi-protocol analysis covering 57,930 exposed OT devices across Modbus, DNP3, BACnet, OPC UA, Siemens S7, EtherNet/IP, and Niagara Fox, download the 2026 OT/ICS Internet Exposure Briefing.

See what’s exposed. ShiftSix Security provides free OT exposure reports that show internet-facing industrial assets mapped to your organization. No scanning required on your end. Request your free OT exposure report.