By design
Four things Modbus simply doesn't have
None of these are bugs, and no firmware update fixes them — they are absent from the protocol itself. Every mitigation that follows works around these four gaps rather than closing them.
NO AUTHENTICATION
Any device that can reach TCP port 502 can issue any request — read values, write coils, change registers. The protocol has no concept of who is asking.
NO ENCRYPTION
Every value, setpoint, and command travels in cleartext. Anyone positioned on the network path can read the state of your process in real time.
NO INTEGRITY PROTECTION
The CRC in Modbus RTU detects transmission noise, not tampering — a deliberate attacker simply recalculates it. Modbus TCP relies on the TCP checksum, which offers no security either.
NO SESSIONS
Each request stands alone with nothing tying it to an authorised conversation. Spoofing and replaying valid-looking requests requires no protocol trickery at all.
Attack vectors
What an attacker actually does with it
Everything below uses the protocol exactly as documented — standard function codes, no exploits required. The tooling is public and mature.
Unauthorised writes
FC 05 · 06 · 15 · 16
The headline risk. Write Single Coil or Write Multiple Registers straight to outputs and setpoints — from any host with network reach. Turning things on and off, changing alarm limits, and forcing states are all one packet each.
Reconnaissance
FC 43 · FC 17
Read Device Identification returns vendor, product code, and firmware version — a shopping list for matching known CVEs to your exact devices. Register scanning maps your process without touching anything.
Diagnostic abuse
FC 08
The diagnostics function includes sub-functions like Force Listen Only Mode, which silences a device until restart — a one-packet denial of service on serial devices. Restart Communications and counter clears are equally available to anyone.
Man-in-the-middle & replay
Any traffic
With no integrity or session protection, captured traffic can be modified in transit or replayed later. An HMI can be shown a healthy process while the real one is being manipulated — the classic pattern from real ICS attacks.
Malformed packet DoS
Implementation bugs
Many Modbus stacks in field devices handle malformed requests poorly — hangs, crashes, and watchdog resets from a single bad packet appear regularly in ICS advisories. Even a badly configured network scanner has knocked PLCs over this way.
Mitigations
Securing what can't secure itself
Since the protocol can't authenticate anything, the controls live around it: who can reach it, what they're allowed to say, and whether anyone notices when something unusual happens. In priority order:
01
Get it off any path to the internet — and check with fresh eyes
Internet-exposed Modbus is still found by the thousand on Shodan. Verify that port 502 cannot be reached from outside your OT boundary — including via forgotten dual-homed hosts, vendor remote access, and cellular gateways added for convenience. This is the single highest-value hour you can spend on Modbus security.
02
Segment so only known talkers can reach port 502
Firewall rules between zones should allow Modbus only between the specific masters and slaves that need it — source, destination, port. A flat network where every workstation can reach every PLC turns any single compromised host into a process control problem.
03
Add protocol-aware filtering where it matters most
Industrial DPI firewalls understand Modbus and can enforce which function codes, unit IDs, and register ranges each source may use — for example, historian reads allowed, writes only from the engineering station, FC 08 blocked entirely. Deploy them at high-consequence conduits first: safety systems, custody metering, critical utilities.
04
Make read-only genuinely read-only
Most Modbus connections exist to feed historians, dashboards, and reporting — none of which need write access. Enforce read-only at the firewall (block write function codes from those sources) or via a gateway that only exposes reads. Some devices also allow writes to be disabled per connection or via a physical keyswitch — use it where it exists.
05
Harden the masters — they are the real attack path
In practice, attackers rarely craft raw Modbus from outside; they compromise the SCADA server, HMI, or engineering workstation and use its legitimate access. Patching, application allow-listing, and access control on those Windows hosts protect Modbus more than anything you can do to the protocol itself.
06
Monitor for writes and scans you don't expect
Modbus is trivially parseable, which makes it easy to monitor. A passive sensor on a SPAN port can alert on write function codes from unexpected sources, FC 08 diagnostics, register scanning, and new talkers appearing. In a stable plant network, Modbus traffic patterns barely change — deviations are worth a look almost by definition.
Common questions
Modbus security — frequently asked
Should I just replace Modbus with something secure?
Rarely practical, and not the first move. Modbus is embedded in decades of installed devices, and even brand-new equipment ships with it because integrators expect it. The realistic posture is to treat Modbus as untrusted by design and build the controls around it — segmentation, filtering, monitoring — while preferring secure protocols where genuine replacement opportunities arise.
What about Modbus/TCP Security — the TLS version?
Modbus.org published a TLS-wrapped variant (port 802) with certificate-based, role-based access control in 2018. It solves the protocol's problems on paper, but device support remains rare — almost no installed base speaks it. Worth specifying when procuring new equipment; not something to plan a brownfield remediation around today.
Is serial Modbus (RTU) safe since it's not on the network?
Safer from remote attack, but not immune: serial lines are usually bridged onto TCP through gateways — which inherit every problem above and add their own (many popular serial-to-Ethernet gateways have shipped with serious vulnerabilities). And anyone with physical access to the RS-485 trunk can inject traffic. Treat gateways as network devices: inventory, patch, and firewall them.
Does putting Modbus inside a VPN fix it?
A VPN protects the transit path — useful across untrusted networks and far better than raw exposure. But it authenticates the tunnel, not the Modbus requests inside it: every host on either end of the tunnel can still issue any command. Combine tunnelling with the function-code and source restrictions above rather than treating it as complete.
Stay current
Get the daily OT brief — free
Protocol vulnerabilities, vendor advisories, and standards changes — curated daily for controls engineers. Under 5 minutes to read.
Get tomorrow's brief free