Why does Modbus TCP have no authentication?

Modbus TCP listens on port 502, and nothing on that port asks who is calling. No login prompt, no password field, no session token, no signature. A device that speaks Modbus will process a read or a write from any client that completes a TCP handshake, because the protocol was never built to check. That is not a bug that shipped unnoticed. It is a design from 1979, carried onto an IP network in 1999 without anyone adding the part it never had.

A 1979 protocol wearing a TCP header

Modicon, the programmable controller maker later absorbed into Schneider Electric, published Modbus in 1979 so its own controllers could poll each other down a single serial cable, one master asking questions in turn and each device answering only when addressed (Wikipedia, Modbus). The original interface ran on RS-232, later mostly RS-485 for longer, multi-drop runs. Nothing on that wire needed to prove who it was, because the wire itself was the proof: only a device physically wired into the cabinet could answer.

Twenty years later, almost nothing about the message changed, only where it travelled. In 1999, Andy Swales at Schneider Electric wrote the Open Modbus/TCP Specification, describing how to carry the same serial protocol data unit inside a TCP socket instead of a serial line (Swales, Open Modbus/TCP Specification, 1999). The Modbus Organization later folded that work into the application protocol specification still current today (Modbus Organization, specifications index). The function codes, the register model, the master and slave roles all carried across unchanged. Only the transport changed, from a closed loop to an open one.

That is why a protocol built for a locked cabinet still runs plant floors in 2026: Ethernet and TCP/IP removed the cabinet door, and nobody ever added back what the door had been doing.

The frame: MBAP header, unit ID, function code, data

Every Modbus TCP message carries two parts, set out in Figure 1: a 7 byte MBAP header that addresses the message, and a protocol data unit, inherited straight from the 1979 serial protocol, that carries the instruction itself. The header holds a transaction identifier for matching a response to its request, a protocol identifier that is always zero for Modbus, a length field, and a unit identifier. The protocol data unit is just a function code followed by however much data that function needs.

The unit identifier routes a message through a gateway bridging several serial devices onto one IP address, the modern equivalent of a serial slave address. It is an address, not a permission: anything that reaches the gateway can put any unit identifier it likes in that byte, and the gateway forwards the request to whichever device answers.

Read the seven bytes again and notice what is missing. Wikipedia's summary of the protocol is blunt about it: Modbus "provides no security against unauthorized commands or interception of data" (Wikipedia, Modbus). That is not a missing feature bolted on somewhere else in the stack. It is the whole design.

Why any host that can route to port 502 can write to a coil

Reaching that port takes nothing more than completing a TCP handshake: there is no step where the device asks the client to prove it is the SCADA server and not a laptop plugged into the wrong switch port. Once the handshake completes, the client can send any function code the device implements, including function code 5, write single coil, and function code 6, write single register. The device does not check who is asking. It checks only whether the request is a well formed PDU addressed to a unit identifier it recognises.

This is not a theoretical reading of the spec. Researchers scanning the public internet in 2026 with Masscan catalogued 179 likely genuine Modbus devices, after filtering out honeypots and emulators, reachable on port 502 across 20 countries, and noted plainly that because Modbus requires no authentication, an attacker could write to the holding registers it exposed as easily as read them (Comparitech, Sasnauskas, 2026). Internet exposure is the rare, extreme case; the common finding on an internal assessment is the same absent gate, one hop inside the plant, on a flat VLAN where an engineering workstation, a historian, a vendor's laptop and the PLC share one broadcast domain. Whatever separates the write functions from an unauthorised sender there is not the protocol, which offers nothing, but whatever the network happens to be doing that day.

Read codes versus write codes: the complete list, and what is safe to send

Every Modbus function code sorts cleanly into one of two behaviours. A read code asks the device to return data and changes nothing about its state. A write code changes a coil or a register on a live, running controller. That distinction, not anything in the protocol itself, is what separates a safe query from an action with physical consequences.

The default during an assessment is to send only the read codes, plus function code 43 for device identification: they return what a passive tap would already show and move nothing. A write, by contrast, forces an output or overwrites a setpoint on whatever is connected right now, a pump, a valve actuator, a PID loop's target. NIST's guide to OT security recommends passive, non-disruptive monitoring over active techniques that risk crashing or disrupting a live system, and a write sent during an assessment is exactly that kind of active technique: it can affect availability and safety on equipment the assessor cannot see the far side of (NIST SP 800-82 Rev. 3; summarised in SecurityScientist, NIST SP 800-82 Explained). A write code belongs in a test plan only once the process owner has approved that register, at that time, with a rollback agreed.

What register reads alone hand an attacker

None of this makes reads harmless, only non destructive. A holding register storing a setpoint, an input register mirroring a flow sensor, a coil showing whether a pump is running: read them all, without a single write, and the picture that comes back is the process itself. Which registers move together, and how fast, shows what physical thing they represent, a tank filling, a line running, a batch stepping through a recipe. Function code 43, read device identification, hands over vendor name, product code and firmware revision by design, for an engineer troubleshooting from a laptop. It is exactly as useful for building a list of exploitable firmware.

The unit identifiers behind a gateway are a map in themselves. Walking them in sequence, reading whatever answers at each one, reconstructs which physical devices share that gateway, without the network ever publishing anything as obvious as an asset inventory. None of it trips a plaintext device's own defences, because most keep none, and none of it needs a single write.

What the Modbus specification leaves out

The Modbus Application Protocol specification is precise about the wire format and largely silent about what deploying it exposes. It documents the function codes to the byte and says nothing about a unit identifier being an address, not a boundary, so a gateway bridging ten serial devices onto one IP address gives anything that reaches that address a path to try all ten.

It documents the exception response, function code plus 0x80 with a one byte exception code, purely as error handling, and says nothing about the fact that sending function codes systematically and noting which return exceptions rather than real data fingerprints what a device supports, register by register, without writing anything.

It sets no rate limit and recommends none. A Modbus server answers requests as fast as they arrive, in whatever order its own scan cycle allows, so a badly written script, not even a malicious one, can occupy a PLC's communication stack tightly enough to slow its actual control loop. And it says nothing about the serial to TCP gateways sitting between an older RTU network and a newer IP one, translating one unauthenticated protocol into another, because from the specification's point of view that gateway does not exist. In practice it is exactly where a lot of plants keep their weakest, least visible point.

Modbus Security, and the controls that actually compensate for its absence

The 2018 specification

A fix exists, on paper, since 2018. The Modbus Organization published Modbus/TCP Security that year, wrapping Modbus inside TLS, requiring TLS 1.2 as the minimum version, and using X.509v3 certificates to authenticate both client and server (Modbus Organization, specifications index). It runs on its own port, 802, alongside the original plaintext one, so a device can keep serving legacy clients on the old port while new clients connect securely on the new one (ScadaProtocols, Modbus TCP Security explained).

Adoption has not followed, and the design is itself the reason: the spec is additive, not a replacement, so nothing stops a device continuing to speak plaintext Modbus on the old port. The devices needing retrofitting are PLCs and RTUs installed years, often decades, before 2018, on silicon never built for a TLS handshake or certificate management, and no vendor is obliged to swap that hardware out for an option nobody on their network has asked for. The installed base is still overwhelmingly on the unsecured port: the secured one is the target state for new builds and gateways, not something most fielded PLCs already speak (ScadaProtocols, Modbus TCP Security explained). A specification published on modbus.org is not one running on a plant floor.

What works instead

Every control that measurably reduces Modbus risk today lives outside Modbus, in the network path around it, because that is the only place there is anything to attach a control to.

• Segmentation. Keep the OT network unreachable from the corporate network and the internet by default, so a phished account or a compromised laptop never reaches Modbus's listening port. NIST's SP 800-82 guidance treats network segmentation as one of the most important controls in an OT environment, because so little else in these protocols holds a line (NIST SP 800-82 Rev. 3; see SecurityScientist, NIST SP 800-82 Explained).
• Unidirectional gateways. Also called data diodes, these enforce a direction physically, not in policy: a historian can pull process data out, but nothing, no write code, no exploit, no misconfigured script, travels back in through the same hardware. They suit segments where nothing legitimate ever sends a command inward.
• Allowlisting at the conduit. The conduit is the boundary between network zones. An industrial firewall that parses the Modbus PDU, not just IP and TCP headers, can permit function code 3 reads from the historian while denying function code 6 writes from anything but the engineering workstation meant to send them. That rule lives in the firewall's policy, because Modbus has nowhere to put it.

None of these controls fixes Modbus. They box it in. That is the only option, because the protocol inside the box has not changed since 1979, and the version that has, the one with TLS and certificates, is still mostly sitting on modbus.org rather than on a plant floor.

Nexich runs authorised offensive assessments inside the perimeter, air gapped by default, and stays read only on control networks, so on a live Modbus device that means only the read function codes set out above are ever sent, never the write ones. What a site does about that gap, segmentation, a diode, an allowlisted conduit, is a decision for the people who own the process, not for the assessment itself.