ModbusTCP: Ethernet Protocol for OT

Updated 3 July 2026

ModbusTCP is an Ethernet-based variant of the Modbus protocol that enables communication between PLCs, RTUs, sensors, and SCADA systems in OT environments.
The protocol employs a master/slave (client/server) architecture using a 7-byte MBAP header and a PDU structure to support over 40 function codes and flexible register mapping.
Implementations demonstrate low latency (from 1.3 ms to ~13 ms) with critical security challenges, prompting strategies like eBPF filtering and encrypted tunnels for protection.

ModbusTCP is the Ethernet-based member of the Modbus protocol family, widely adopted for communication between Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs), industrial sensors, and SCADA/HMI software within operational technology (OT) environments. Originally developed in 1979 for serial bus architectures, ModbusTCP transposes the master/slave (client/server) request-response schema to TCP/IP networks, consolidating its status as a de facto interoperability protocol in both legacy and Industry 4.0 installations across energy, manufacturing, and infrastructure sectors (Wendt et al., 2021, Nikolajew et al., 2024, Rodda et al., 4 Aug 2025).

1. Protocol Architecture and Framing

ModbusTCP encapsulates requests and responses as Application Data Units (ADUs) on TCP port 502. Each ADU consists of two main components: a 7-byte Modbus Application Protocol (MBAP) header and a Protocol Data Unit (PDU) (Banik et al., 2023, Nikolajew et al., 2024, Wendt et al., 2021, Jhan et al., 2023):

MBAP header (7 bytes):
- Transaction Identifier (2 bytes): Used for request/response correlation.
- Protocol Identifier (2 bytes): Always 0x0000 for Modbus.
- Length (2 bytes): Number of remaining bytes after this field (Unit ID + PDU).
- Unit Identifier (1 byte): Slave address, supporting multi-drop or gateway scenarios.
PDU:
- Function Code (1 byte): Specifies the command (e.g., 0x01 = Read Coils, 0x03 = Read Holding Registers).
- Data Field (N bytes): Operational parameters such as address, quantity, or value.

The protocol omits application-layer cryptographic checksums, relying instead on TCP’s integrity guarantees for channel correctness. CRC16 is only present in Modbus/RTU serial variants (Wendt et al., 2021, Banik et al., 2023).

2. Function Codes, Addressing, and Register Mapping

ModbusTCP supports more than 40 function codes, with the most widely implemented relating to bit and register access (Nikolajew et al., 2024, Banik et al., 2023, Wendt et al., 2021):

Function Code	Description	Access
0x01 (Read Coils)	Discrete outputs (bits)	R/W
0x02 (Read Discrete Inputs)	Discrete inputs (bits)	R/O
0x03 (Read Holding Registers)	16-bit words	R/W
0x04 (Read Input Registers)	16-bit words	R/O
0x05 (Write Single Coil)	Set/reset 1 bit	W
0x06 (Write Single Register)	Set 1 word	W
0x10 (Write Multiple Registers)	Set multiple words	W

Addressing is 0-based within the function’s domain. Human conventions—such as 40001 for holding registers—map to offset 0 in the Modbus PDU (Wendt et al., 2021, Xavier et al., 25 Mar 2026). Device-specific configuration determines type and mapping; for example, DAQ systems may map analog inputs as a vector of contiguous registers with custom scaling equations (Banerji, 2013).

3. Implementation Patterns and Integration

Implementations span low-level device drivers, high-level frameworks, and model-driven code generators (Wendt et al., 2021, Nikolajew et al., 2024, Xavier et al., 25 Mar 2026):

ROS Device Driver Architecture: The generic Modbus/TCP device driver for ROS uses YAML configuration to map coils, discrete inputs, input and holding registers directly to ROS message topics, supporting polling, bulk read aggregation, automatic reconnection, and error recovery (Wendt et al., 2021).
Model-Driven Connector Generation: Platforms such as oktoflow distinguish protocol connector types from connector instances, enabling the automatic generation of Java (Jamod-backed) or Python clients based on model declarations of field types and register offsets. Empirical results show generated connectors can match handcrafted ones in both LAN and device-attached settings, with average request-response latency dominated by hardware and network factors (typ. 1.3 ms on localhost, up to ~13 ms on real devices) (Nikolajew et al., 2024).
AI and Automation Interfaces: Middleware such as IndustriConnect adopts a schema-first, mock-driven adapter paradigm, exposing Modbus operations over JSON-RPC as discoverable tools with formal input/output schemas, strict range checking (e.g., uint16 enforcement on register writes), structured error envelopes, and mock-based pre-deployment validation (Xavier et al., 25 Mar 2026).

4. Operational Technology Footprint and Exposed Risks

Large-scale Internet scanning (e.g., via Shodan) has revealed a vast public ModbusTCP attack surface: ModbusTCP is the most prevalent OT protocol, with >68,000 publicly accessible devices identified, and ~20% exposing device model information via unprotected “Read Device Identification” queries (Rodda et al., 4 Aug 2025). Geographic concentration is observed in North America and Europe, with vendor and model diversity spanning Schneider Electric Modicon, Siemens S7, and a spectrum of solar controllers and industrial PLCs.

Key vulnerabilities arise from the original protocol’s absence of any cryptographic authentication, payload integrity, or confidentiality mechanisms (Rodda et al., 4 Aug 2025, Jhan et al., 2023):

Any host with network access can read or write to memory/register space.
Banner leakage reveals device model signatures, supporting fingerprinting and targeted attacks.
Observed exposures include widely unpatched firmware with critical CVEs (e.g., remote code execution, buffer overflows).

Attack vectors typically leverage one of three patterns (Rodda et al., 4 Aug 2025):

Reconnaissance/sniffing (reverse engineering process layouts from cleartext frames).
Command injection (unauthenticated register and coil manipulation).
Denial of Service (overload via valid or malformed requests).

5. Security Assessment and Countermeasure Strategies

The ModbusTCP protocol, both in lab settings and real-world deployments, is highly susceptible to Man-in-the-Middle (MITM) and replay attacks (Banik et al., 2023, Marsden et al., 2017, Jhan et al., 2023). Key findings and countermeasure classes include:

MITM and ARP Spoofing: Attackers can easily intercept and alter legitimate ModbusTCP traffic using ARP poisoning and tools such as Ettercap or Metasploit, resulting in register corruption, duplicate ACKs, anomalous MAC addresses, and connection resets (Banik et al., 2023).
Replay Detection: Probability Risk Identification-based IDS (PRI-IDS) computes moving-average risk scores tied to function-code criticality. Empirical results show PRI-IDS achieves 83.7% replay detection rate with a 15.3% false positive rate, outperforming k-NN and Random Forest on identical datasets (Marsden et al., 2017).
Neural and Binary-Image Approaches: SPHBI single-packet classifiers using TCP/IP, MBAP, and function code bytes reach up to 98.6% binary accuracy for per-packet anomaly detection, with best multiclass performance at 94.4% (nine classes). However, such methods are structurally unable to detect replay or timing-only attacks, requiring layered analysis (Omar, 5 May 2026).
Protocol Hardening and eBPF Security Layering: Recent proposals leverage Linux eBPF/XDP to transparently enforce HMAC authentication, optional AES-CTR encryption, and inline anomaly filtering at kernel level. Overhead is typically <50 μs/packet and <25% CPU at high packet rates, and the approach does not require changes to device firmware or industrial application stacks (Jhan et al., 2023). Additional architectural controls include network segmentation, ACL enforcement, and migration to Modbus/TCP over TLS (Banik et al., 2023, Rodda et al., 4 Aug 2025).

6. Application Scenarios: DAQ, AI-Orchestration, and Industrial Automation

ModbusTCP remains central in diverse industrial and research applications:

Supervisory DAQ Systems: Multi-tier architectures poll sensor banks via Ethernet I/O stations, map physical signals to Modbus registers, and apply protocol-specific scaling (e.g., raw ADC reading X scaled to U = 20((X/65536)-0.5); P = 10^{{1.667·U-11.33})} (Banerji, 2013).
ROS-Based Robotics Integration: Solution templates formalize YAML-to-topic mapping, support robust polling (with sub-millisecond message latency), and unify registers/coils as typed ROS topics, dramatically reducing driver development effort (Wendt et al., 2021).
AI-Driven Plant Orchestration: Schema-discoverable adapter toolsets standardize Modbus interactions for LLMs and AI agents, facilitating mock-first workflow verification, structured adapter error handling, and safe live switching. Empirical benchmarks indicate robust 1–3 ms per-call latencies in local test environments (Xavier et al., 25 Mar 2026).

7. Performance Experimentation and Best Practices

Benchmarking across implementations and deployment contexts shows (Nikolajew et al., 2024, Xavier et al., 25 Mar 2026):

Local (loopback) request-response latencies for both handcrafted and generated Java/Python clients average ≈1.3 ms.
LAN introduction increases mean latency by ≈3.7×; real device testing reveals substantial hardware/firmware-dependent variance (e.g., Phoenix Contact EEM ~7.9 ms, Siemens Sentron ~6.8 ms).
Python clients (pyModbusTCP) can outperform Java-based counterparts on some industrial hardware.
Performance is strongly bounded by device processing time and network topology.
Best practices stress grouping adjacent addresses, tuning polling rates, explicit error and reconnect handling, and regular benchmarking on deployed hardware.

Prudent exposure mitigation, disciplined patching aligned with CVE advisories, use of encrypted and authenticated tunnels, and configuration of minimal register/model banners are essential to limit public attack surfaces and ensure integrity in critical operational technology networks (Rodda et al., 4 Aug 2025, Jhan et al., 2023, Banik et al., 2023).