Modbus security: the protocol will not help

Modbus security is not a setting you switch on, because the protocol has nothing to switch on: no password field, no encryption, no log. Everything that protects an installation therefore has to come from the network around it. After this lesson you can point at what plain Modbus does and does not give you, name the measures that take that job over, and judge whether a remote access proposal opens a path into the site.

What happens when someone listens in

Whoever can open a TCP session to port 502 can read every register and write to the writable ones, without proving who they are. Here is such a write on the wire: value 3 into holding register 40002 (datasheet number, 1-based), which is PDU address 1 (0-based).

The response is those same twelve bytes back, byte for byte, because FC06 echoes the request as its confirmation. Nothing in the exchange recorded who asked.

Now look for the field that names the sender. There is none. The MBAP header is 7 bytes (transaction id, protocol id, length, unit id) and the PDU is a function code plus data. No identity, no key, no session token, no signature. Modbus carries addresses, not credentials.

Change one thing and nothing improves. Behind a gateway the unit id is 01 rather than FF, because it points at server address 1 on the RS485 bus. Still an address, and anyone can type a 1.

Why the protocol was designed this way

Modicon introduced Modbus in 1979 for a closed factory network with no route to anywhere else, so the lock on the cabinet door was the access control. When Modbus/TCP was registered with IANA in 1996 and given port 502, the message format came over unchanged, and the assumption about the network came with it.

What you fix at network level

Three measures, in this order, because each one makes the next cheaper.

1. Put the field devices in their own VLAN. One boundary covers every device in the zone at once, including the ones nobody documented, and it needs no cooperation from the equipment.
2. Allow only the client that has business there. One firewall rule from the IP address of your gateway or controller to port 502. Everything else denied, guest wifi and camera recorder included.
3. Never port forward to port 502. If the site must be reachable from elsewhere, let the traffic start from inside.

The specification itself offers one thing and no more. Its Access Control Module is an optional list of authorized source IP addresses, and a connection from an address that is not on that list gets closed. That is filtering, not authentication, because an IP address can be spoofed.

Manufacturers agree, and some enforce it. NIBE writes that "Modbus/TCP communication over the open internet is very risky and is not recommended", and its S-series accepts connections only from the private RFC1918 ranges. Fronius can limit control to specific IP addresses, but read the fine print: that restricts writing, not reading. What each device needs on the network is covered in Modbus TCP network requirements.

Why outbound beats inbound

A gateway that dials out itself needs no open port at all, and that difference settles most remote access arguments. Your firewall passes the return traffic because it belongs to a session it saw start from the inside, so a scanner on the internet finds nothing.

A VPN and a port forward both do the opposite. A port forward exposes a device with no authentication to anyone scanning the address space. A VPN is far better, because it authenticates and encrypts, but it is still an inbound path with credentials to manage and revoke. That can be the right call. It is a different call.

What each model costs you in data ownership is set out in the guide to remote Modbus monitoring.

What Modbus/TCP Security adds

There is a secure variant, and the specification explains it with an analogy that saves a paragraph: mbap and mbaps relate the way http and https do. It listens on port 802 instead of 502 and wraps the same ADU in TLS 1.2 or newer, with negotiating down to TLS 1.1 or lower explicitly forbidden.

Two things make it more than a tunnel. Authentication is mutual: both ends present an x.509v3 certificate, and a client that sends none has its connection terminated. In HTTPS a client certificate is the exception, here it is the rule. And authorization travels in the certificate: the client's role sits in an extension identified by the Modbus.org OID 1.3.6.1.4.1.50316.802.1, which the server checks before processing the request. An unauthorized request comes back as exception code 01, the same code as "illegal function code".

Inside the envelope nothing changes: same MBAP header, same function codes, same registers, so the MBAP header and unit id lesson still applies.

Why you rarely see it in the field

Because the certificates have to come from somewhere. The specification depends on a public key infrastructure and requires every client device to be provisioned with its own certificate, yet describes no provisioning protocol at all. Issuing and renewing certificates on a few hundred field devices is therefore a manual, vendor specific job, and the role names are vendor specific too.

Age is not the obstacle: that version of the specification dates from 30 July 2021 and the IANA port registration from 10 June 2014. In the installations you meet today, plain Modbus TCP on port 502 is the norm and port 802 a rarity.

How much equipment is actually exposed?

Enough to make the network measures worth the afternoon they cost, and not so much that panic helps. Bitsight counted roughly 170,000 to 180,000 unique IP addresses per month exposed across the 15 ICS/OT protocols it monitors during 2025, peaking at roughly 170,000 in January 2025 and then holding steady, with the expected climb to 200,000 never arriving. Modbus and Niagara FOX together make up about half of all internet reachable ICS/OT devices there.

Censys counted more than 145,000 exposed ICS services worldwide in its November 2024 report, split 38 percent North America, 35 percent Europe and 22 percent Asia, and observed Modbus more widely in Europe than elsewhere. Whether a gateway can dial out at all is worth checking before you buy, and the industrial IoT gateway comparison covers that.

Common mistakes

Forwarding port 502 so you can check the site from home. It works on the first try, which is the trap. Anyone who finds that address gets the same access you have, including writes, because the device cannot tell you apart. Use an outbound connection, or a VPN if you accept the inbound path knowingly.

Treating a VPN as if it were an outbound connection. Both give you remote access, but only one of them leaves the firewall closed. Say out loud which of the two you are installing, because the answer decides who else can reach the site if a credential leaks.

Hanging field equipment on the office network. A meter or an inverter runs a small network stack that was never meant to sit next to laptops, printers and guest wifi. A separate VLAN costs an afternoon and saves years of arguing about whose device caused what.

Reading an exception as proof that you are protected. Exception 02 is an address error, exception 01 an unsupported function. Neither is a refusal on grounds of identity, because plain Modbus has no identity to refuse on. For the anatomy of these responses, see Modbus TCP explained.

Get hands-on

Inventory your own exposure and close the first gap.

1. 1

   List everything that speaks Modbus TCP

   One line per device: IP address, port, and what it is. Include the gateways, not just the meters and inverters.

2. 2

   Check who can reach each one

   Is it in the same network as office laptops, guest wifi or cameras? Note the answer per device, because that is your actual attack surface.

3. 3

   Hunt for port forwards and NAT rules

   Look in the router for anything pointing at port 502. If one exists, write down why it was created and whether an outbound connection could replace it.

4. 4

   Allow only your client

   Where the firewall permits it, add a rule that lets only the IP address of your gateway or controller reach port 502, and denies the rest.

5. 5

   Test that monitoring still works

   Read one known register per device. A rule that breaks the installation is not an improvement.

6. 6

   Write down what you changed

   Rule, reason, date. The next engineer on site should not have to reverse engineer your firewall.

No installation to work on. Do the same exercise against the simulator. Start it with pymodbus.simulator --modbus_server server --modbus_device device and it listens on 0.0.0.0:5020, which means every machine on your network can read it. Confirm that from a second device, then restart it bound to 127.0.0.1 only and confirm the same read now fails. That is a firewall rule in miniature, and pymodbus is free to use, including commercially.

Expected result: a list of devices with their reachability, and at least one path closed.

Where these measures land depends on the route you pick, because a PLC, a Home Assistant and a cloud platform each expose a different part of your network. That comparison is in the lesson on Modbus integration in practice.

Summary

• Modbus has no authentication, no encryption and no logging, so whoever reaches port 502 can read and write.
• The unit id is an address, not an identity: 0xFF for a native TCP device, 1 to 247 behind a gateway, and free for anyone to set.
• Segmentation into a separate VLAN comes first, because it is the only measure that needs no cooperation from the field equipment.
• An outbound connection needs no open port, while a VPN and a port forward both create an inbound path.
• Modbus/TCP Security on port 802 adds TLS 1.2 with mutual certificates and refuses an unauthorized request with exception code 01, but it needs a PKI you will rarely find.