Is Modbus TCP (port 502) exposed to the internet, and how do I fix it?

Key takeaways

• Modbus TCP on port 502 has no usernames, passwords or permissions: any client that can open a TCP connection can usually read, and often write, a device’s coils and registers.
• An exposed endpoint can reveal process data, accept changed setpoints, and give an attacker a foothold in the OT network.
• Check whether your own endpoint answers an unauthenticated identity request, not just whether port 502 is open.
• Fix it by removing the port forward, segmenting the OT network, and replacing direct access with an authenticated path.

Why does Modbus have no authentication?

Modbus is one of the oldest and most widely deployed industrial protocols, originally built in 1979 by Modicon for serial connections between a PLC and nearby devices on an isolated factory network — a world where “anyone who can reach this cable is already inside the building and trusted.” The Modbus Organization, which maintains the protocol specifications today, preserved that same simple, unauthenticated request-response format when Modbus TCP later adapted the protocol to run over ordinary IP networks on port 502 (the port IANA registers for Modbus).

The problem is that “isolated factory network” assumption quietly stopped being true for a lot of equipment. Remote monitoring, vendor telemetry, and convenience-driven port forwarding for maintenance access have put Modbus TCP devices on the same internet as everything else, while the protocol itself still has no concept of a username, password, or permission check. Any client that can open a TCP connection to port 502 can typically send a valid Modbus request and get a valid Modbus response — reading holding registers, coils, and input status, and on many devices, writing to them too.

What does a Modbus TCP request look like?

Every Modbus TCP message starts with a seven-byte header, the MBAP header, defined in the Modbus Organization’s TCP/IP implementation guide. It’s followed directly by the function code and its data. There is no field anywhere for a credential:

Field	Size	Meaning
Transaction identifier	2 bytes	Matches a response to its request
Protocol identifier	2 bytes	Always 0 for Modbus
Length	2 bytes	Number of bytes that follow (unit identifier plus the request)
Unit identifier	1 byte	Which device behind a gateway should answer
Function code + data	variable	What to do: read, write, or identify

The request AdminKit’s Modbus check sends is a Read Device Identification (function 43, MEI type 14) asking only for the basic objects — vendor name, product code and revision. On the wire it is 11 bytes:

00 01  00 00  00 05  FF  2B 0E 01 00
|      |      |      |   |  |  |  +-- first object: vendor name
|      |      |      |   |  |  +----- basic identification category
|      |      |      |   |  +-------- MEI type 14 (Read Device Identification)
|      |      |      |   +----------- function code 43 (0x2B)
|      |      |      +--------------- unit identifier
|      |      +---------------------- length: 5 bytes follow
|      +----------------------------- protocol identifier: Modbus
+------------------------------------ transaction identifier

A device that answers with its vendor and product name has just shown that it accepts requests from that network path without asking who’s sending them.

What can someone do with an exposed Modbus device?

What an exposed Modbus device reveals or allows depends entirely on what it controls, but commonly includes:

• Process visibility: temperatures, pressures, flow rates, machine run/stop state, and other register values that may reveal production volumes or operational patterns to a competitor or attacker.
• Write access to coils and registers: on many devices, nothing distinguishes a read request from a write request in terms of authorization — if write function codes aren’t disabled or filtered, a connection can change setpoints, trip outputs, or alter control logic parameters.
• A foothold into the broader OT network: a Modbus device is sometimes the most exposed point on a network that also contains other, less-exposed equipment reachable once an attacker is established there.

CISA’s Industrial Control Systems guidance covers this class of risk broadly: ICS protocols that were designed for trusted, isolated networks need compensating controls (network segmentation, access control, monitoring) once any path from the internet reaches them, because the protocols themselves generally won’t say no.

The difference between looking and changing is just the function code. These are the common public function codes from the Modbus application protocol specification:

Code	Name	Effect
1	Read Coils	Reads on/off outputs
2	Read Discrete Inputs	Reads on/off inputs
3	Read Holding Registers	Reads stored values such as setpoints
4	Read Input Registers	Reads measured values
5	Write Single Coil	Switches one output on or off
6	Write Single Register	Changes one stored value
15	Write Multiple Coils	Switches several outputs at once
16	Write Multiple Registers	Changes several stored values at once
43 / 14	Read Device Identification	Returns vendor, product and revision

A firewall that only opens or closes port 502 can’t tell these apart. That’s why the fix below includes filtering write codes where an integration only needs to read.

Step 1: Is your Modbus endpoint reachable?

Only ever run this against equipment you own or are explicitly authorized to test — Modbus exposure checks interact directly with real industrial equipment, so authorization matters more here than almost anywhere else on this site. AdminKit’s Modbus exposure check tests whether a Modbus TCP endpoint on your own public IP or a verified asset accepts a connection on port 502 and answers an unauthenticated identity request (vendor and product via Modbus function 43, never a coil or register) — the specific, practical question that matters: not just “is port 502 open,” but “does it actually talk Modbus back to an unauthenticated request.”

Port check covers commonly-exposed device ports including 502, run only against your own IP with your own consent — enough to tell you whether port 502 is reachable at all.

What the checks show	What it means
Port 502 closed	No Modbus TCP exposure on that address from the internet
Port 502 open, no Modbus answer	Something listens on 502 but didn’t answer the identity request; still remove the exposure
Modbus exception reply	A Modbus device answered; it declined the identity function but accepts traffic
Vendor and product returned	A Modbus device answers unauthenticated requests from the internet; fix this first

In the last three cases the TCP connection itself succeeded, and the check reports the endpoint as exposed whether or not identification came back. A device that refuses function 43 can still answer reads and writes.

Step 2: How did it get exposed?

Modbus TCP exposure almost always traces back to one of these:

1. A port forward added for remote monitoring or vendor support, set up for a specific need and left in place indefinitely.
2. A gateway device bridging serial Modbus to Modbus TCP that was then placed on a network segment with a path to the internet, sometimes without whoever installed it realizing the bridge changed the exposure.
3. Flat network design, where the OT network isn’t segmented from the general office or guest network, so a route that was only meant to reach internal systems ends up reachable from much further away than intended.

Step 3: How do you fix it?

• Remove the port forward or firewall rule exposing port 502 to the internet, if ongoing remote access isn’t a genuine operational need.
• Segment the OT network so Modbus devices sit behind a firewall separate from general office traffic, limiting what else on the network can reach them even internally.
• If remote access is genuinely needed, replace a direct port forward with an access method that authenticates the connection before it ever reaches the Modbus device — a VPN concentrator, a jump host with its own login, or a purpose-built OT remote-access tunnel, rather than Modbus TCP itself facing the internet.
• Disable write function codes at the gateway or firewall level where possible, if a given integration only legitimately needs to read data, so a reachable endpoint can’t also be commanded.
• Review who still needs access periodically — remote-access paths set up for a specific vendor or a one-time commissioning job are a common source of exposure that outlives its original purpose.

The Modbus Organization also publishes a secure variant, Modbus/TCP Security, which wraps Modbus in TLS with certificate-based authentication; IANA registers it as mbap-s on port 802. It only helps where both the device and the client support it, which is worth asking vendors about when equipment is replaced. It doesn’t change the advice for devices already installed that speak plain Modbus TCP on 502.

Is this problem unique to Modbus?

This isn’t unique to Modbus. Other industrial protocols adapted from isolated-network origins — BACnet/IP in building automation, DNP3 on electric and water utility SCADA systems, older Siemens S7 implementations — share a similar history of weak or absent authentication, though some, like OPC UA, were designed later with authentication and encryption as built-in options. If your factory or building also runs MQTT for sensor telemetry, see our guide on port 1883 (MQTT) exposure for the closely related anonymous-access problem on that protocol.

The practical path is the steps above, starting with port check and the Modbus exposure check to find out whether port 502 is reachable. To replace port-forwarded access for good, OT Remote Access is a Netbase custom engagement that swaps it for outbound-only connections from the site and recorded maintenance sessions, so no inbound port stays open — talk to our team about your site.

Defensive use only

Every check this guide links to is for assets you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to equipment or a network you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.