Investigation of Secure Communication of Modbus TCP/IP Protocol: Siemens S7 PLC Series Case Study

Abstract

Industrial Control Systems (ICS) have become increasingly vulnerable to cyber threats due to the growing interconnectivity with enterprise networks and the Industrial Internet of Things (IIoT). Among these threats, Address Resolution Protocol (ARP) spoofing presents a critical risk to the integrity and reliability of Modbus TCP/IP communications, particularly in environments utilizing Siemens S7 programmable logic controllers (PLCs). Traditional defense methods often rely on host-based software solutions or cryptographic techniques that may not be practical for legacy or resource-constrained industrial environments. This paper proposes a novel, lightweight hardware device designed to detect and mitigate ARP spoofing attacks in Modbus TCP/IP networks without relying on conventional computer-based infrastructure. An experimental testbed using Siemens S7-1500 and S7-1200 PLCs (Siemens, Munich, Germany) was established to validate the proposed approach. The results demonstrate that the toolkit can effectively detect malicious activity and maintain stable industrial communication under normal and adversarial conditions.

1. Introduction

Industrial Control Systems (ICS) are integral to most modern factories and are increasingly intertwined with essential aspects of daily life. Historically, these systems operated in isolated environments with limited external connectivity. However, with the advancement of digital transformation and smart manufacturing, factories now require seamless integration between industrial devices and broader IT infrastructures. This evolution has introduced the Industrial Internet of Things (IIoT), which is revolutionizing how factories, power grids, and intelligent infrastructures operate while simultaneously creating new business opportunities for manufacturers, software developers, and network providers [1,2].

Despite the transformative potential of IIoT, its adoption has exposed ICS environments to a broad array of cyber threats. ICS protocols were traditionally designed for efficiency, simplicity, and compatibility, not security. One such protocol, Modbus Transmission Control Protocol/Internet Protocol (TCP/IP), remains widely used due to its lightweight structure and interoperability across devices from different vendors [3]. However, Modbus lacks basic security features such as encryption, authentication, and integrity checks, making it highly vulnerable to interception, spoofing, and manipulation.

The consequences of these vulnerabilities have been demonstrated through several high-impact cyberattacks. Notably, the Stuxnet worm (2010) exploited four zero-day vulnerabilities to target Supervisory Control And Data Acquisition (SCADA) systems, particularly Siemens Simatic WinCC V7.0/STEP 7 V5.3 software. This malware enabled unauthorized control over Programmable Logic Controllers (PLCs), resulting in the destruction of nearly 1000 centrifuges and reducing uranium enrichment by 30% [4,5]. Similarly, the BlackEnergy malware (2015) evolved from a DDoS tool into a sophisticated threat used to compromise Ukraine’s power grid via phishing and remote command execution on SCADA systems [6]. More recently, the Colonial Pipeline ransomware attack in 2021 disrupted fuel distribution across the U.S. East Coast, causing supply shortages, price hikes, and service interruptions [7].

These events emphasize the urgent need for robust cybersecurity in ICS. Yet, current statistics indicate growing challenges: according to Kaspersky ICS CERT, 31.8% of ICS computers encountered malicious objects in the first half of 2022 alone [8]. Additionally, Dragos reported an 87% increase in ransomware attacks targeting ICS networks, along with a 35% rise in ransomware groups focused on operational technology (OT) systems [8].

To address these challenges, researchers have proposed various enhancements to the Modbus TCP/IP protocol. For instance, cryptographic approaches using SHA2, RSA, and timestamping have been employed to enforce integrity and authentication [9]. Another notable solution is ModbusSec, which utilizes the Stream Control Transmission Protocol in conjunction with Hash-based Message Authentication Codes to secure message transmission [10]. However, these approaches typically overlook the need for confidentiality, and when cryptographic techniques are applied, they can impose performance overhead that is incompatible with real-time industrial operations [9,10].

Recent advances in hardware-based encryption, such as Trusted Platform Modules, have mitigated some of these limitations. For example, ref. [11] demonstrated that integrating TLS into Modbus communications introduces a negligible impact on power grid operations. Moreover, ref. [12] proposed the Modbus-S protocol, which incorporates symmetric encryption, hash-based synchronization, digital signatures, and function-code whitelisting into a secure gateway. The Modbus organization has since acknowledged these developments, updating its official specification to include TLS-based secure communication under the variant known as Modbus/TCP Security. This protocol supports Public Key Infrastructure for authentication and confidentiality, and introduces Role-Based Access Control through X.509v3 certificates [13,14].

While these developments represent important strides, many proposed solutions depend heavily on computing platforms. This assumption is problematic for certain ICS environments where traditional computers are absent or restricted due to legacy constraints, air-gapping, or minimal compute resources. Recognizing this, several recent studies have proposed lightweight alternatives. Katulić et al. introduced Message Authentication Code-based integrity verification natively in Siemens S7-1500 PLCs, showing how authenticity can be preserved without external systems [15]. de Brito and Sousa Jr. demonstrated the practical use of TLS on S7-1200 PLCs within an open-source nuclear ICS testbed, emphasizing its low-latency overhead [16]. Alsabbagh and Langendörfer argued for embedded, protocol-aware security models that integrate directly within the control layer [17], while Mughaid et al. emphasized hardware-aware protection schemes suitable for edge environments [18].

Despite these advances, there remains a critical gap in Modbus security research: the need for a self-contained, hardware-based mitigation solution that can operate in computer-less ICS environments. While ARP spoofing has been studied extensively [19,20], and several IDS-based defenses have been proposed, these approaches often require either compute-intensive analysis or centralized monitoring, making them unsuitable for deployment in low-complexity environments or legacy Siemens S7 setups.

This paper aims to fill that gap. Our research presents a lightweight, standalone device capable of detecting and blocking ARP spoofing attacks in ICS networks without the need for host computers. The device can be seamlessly integrated into operational networks, including setups using Siemens S7-1200 PLCs, and is applicable to both air-gapped and enterprise-integrated OT systems. The contributions of this research can be summarized as follows.

• A novel hardware device that passively detects ARP spoofing activity in Modbus TCP/IP networks and prevents traffic redirection without relying on computer-based security tools.
• An experimental demonstration of a real-world infiltration scenario involving Siemens S7-1200 PLCs, highlighting the ease of exploiting ARP spoofing to compromise Modbus communication.
• The proposed mitigation toolkit, compatible with both legacy ICS setups and modern, monitored environments.

In comparison to existing research, the proposed solution advances the vision of embedded ICS protection by enabling deployable, hardware-based defenses that do not compromise system determinism or real-time operation. As emphasized in [21,22], securing ICS at the protocol layer requires fine-grained, low-latency countermeasures. Our contribution directly supports this trajectory by providing an approach that blends practicality with security assurance.

The remainder of this paper is organized as follows: Section 2 discusses background on Modbus TCP/IP, ARP spoofing, and the MITRE ATT&CK framework, placing our scenario in context. Section 3 describes the hardware attack model and experimental design. Section 4 evaluates the interference capability of the proposed toolkit. Section 5 introduces our mitigation strategy and implementation. Finally, Section 6 concludes the paper and outlines future work focused on zero-trust OT architectures and lightweight security integration.

2. Background on Modbus TCP/IP Communication and ARP Spoofing Attacks

2.1. Modbus TCP/IP Protocol

The Modbus TCP/IP protocol establishes standards for client/server communication between devices on Ethernet TCP/IP networks or other bus systems [15]. The protocol employs a simple application data unit (ADU) format to ensure compatibility among various devices, regardless of the devices in use. The entire Modbus packet is embedded within the data section of the TCP packet and transmitted over the network, as shown in Figure 1. Modbus TCP/IP uses two types of ADUs: request and response frames, both containing the Modbus application protocol (MBAP) header, function code, and data segment. Figure 1 displays the ADU format and standard function codes, with detailed descriptions of ADU fields available in the document [23].

Modbus TCP/IP is designed to meet the communication needs of industrial environments. However, vulnerabilities within the protocol can expose systems to various attack scenarios [24], including the following:

• Plain text data transmission: Modbus TCP/IP transmits data packets without encryption, leaving sensitive information exposed and easily accessible to attackers. This allows them to gather crucial information, potentially aiding in the preparation for system attacks.
• Lack of authentication: the absence of robust authentication mechanisms between the client and server enables attackers to impersonate legitimate users and send control commands to devices.
• Abuse of function codes: unrestricted function codes allow any client user to issue commands, potentially leading to unintended actions like device restarts or shutdowns without adequate server safeguards.
• Data tampering: the Modbus TCP/IP protocol lacks a data integrity check, allowing attackers to modify transmitted data undetected.

2.2. Address Resolution Protocol

The Address Resolution Protocol (ARP) is a data link layer protocol that translates IP addresses to Media Access Control (MAC) addresses. For a host to communicate with another host, it needs both the IP and MAC addresses of the destination. If a sending node knows the IP address but not the MAC address, it uses ARP to find it. The node broadcasts an ARP request packet, which all nodes on the network receive. Each node compares the requested IP address with its own and sends a unicast ARP reply packet containing the MAC address if there is a match. Once the sending node receives this response, it can communicate with the destination node. The <IP, MAC> pairing enables packet delivery within the network. ARP functions through a broadcast ARP request followed by a unicast ARP reply, as illustrated in Figure 2 [25]. However, this protocol has a vulnerability that attackers may exploit; one of the methods used is ARP spoofing [26,27].

2.3. ARP Spoofing

ARP is designed to work efficiently under normal conditions but is not equipped to handle malicious hosts. Typically, when a master PLC needs to communicate with a slave PLC on the same network but does not know the slave’s MAC address, it sends an ARP broadcast request to all devices on the network. The slave PLC then responds with a unicast ARP reply containing its MAC address. Each device maintains a cache table that stores IP and MAC pairs from previous interactions. However, the ARP protocol has security limitations; one is its susceptibility to ARP spoofing, a common and easily executed attack. ARP spoofing-based man-in-the-middle attacks (MITM) exploit this weakness by allowing an unauthorized third party to intercept communication between two hosts on the same network secretly. The ARP protocol requires operating systems to maintain a cache table of ARP replies to minimize ARP broadcast requests. When a host receives any ARP packet, it automatically updates its ARP cache with the new <IP, MAC> association, even if the IP address is already in the table [25,28].

In an ARP spoofing attack, consider a LAN network with the following devices: an attacker (IP = 192.168.0.197, MAC = 00:00:20:07:19:98), a victim master PLC (IP = 192.168.0.102, MAC = E0:DC:A0:B0:E9:BE), and a victim slave PLC (IP = 192.168.0.202, MAC = E0:DC:A0:B0:8D:CE). When the master PLC needs to communicate with the slave PLC, it first sends an ARP broadcast request to all hosts in the LAN to discover the slave’s MAC address. Hosts update their cache tables with the master’s address, and if a host matches the request, it sends an ARP unicast reply with its address to the master PLC [29]. Nevertheless, this update will occur even when receiving spoofed ARP packets. Figure 3 illustrates the cache table of the two PLCs after receiving the fake request.

2.4. Threat Landscape and Related Work

To better contextualize our ARP spoofing-based scenario within the broader cybersecurity framework, we refer to the MITRE ATT&CK for ICS knowledge base [30], where each technique is categorized and assigned a specific ID (e.g., T0830, T0842, etc.). Specifically, our approach aligns with the Adversary-in-the-Middle (T0830) technique, where ARP spoofing is employed to intercept and potentially manipulate communications between devices. Following this, we utilize network sniffing (T0842) to passively monitor and analyze Modbus TCP/IP traffic.

By first gaining network access through ARP spoofing (T0830), an attacker can observe communication patterns and identify active connections (T0840). This access may also open the door to sending unauthorized messages to Modbus TCP/IP devices (T0855). Our research focuses on this early-stage foothold, which, although limited in itself, can pave the way for deeper intrusions into the ICS environment, such as further reconnaissance or lateral movement.

To counter such threats, several security mechanisms can be applied, such as network segmentation, secure authentication layers (e.g., MAC-based integrity checks), or proposed intrusion detection systems.

3. Design and Implementation

3.1. Hardware Devices

Figure 4 shows the principal diagram of the attack device. The microcontroller manages the system’s operation, communicating with the Ethernet IC via the Serial Peripheral Interface (SPI) serial communication standard to send and receive packets. The Ethernet IC connects the attack device to the industrial network through the Ethernet port.

Based on this principle diagram, the following hardware components are selected:

• Microcontroller STM32F103C8T6: Compact size, maximum clock speed of 72 MHz.
• Ethernet shield ENC28J60: Standalone Ethernet controller utilizing the SPI.
• Ethernet port: Module RJ45.
• Source: Lithium battery, DC low-voltage circuit LM2596.
• Buttons, LEDs.

The complete circuit of the attack device is depicted in Figure 5, where Subfigure (a) illustrates the printed circuit board (PCB) layout, and Subfigure (b) shows the fully assembled device, which is designed to resemble a digital clock. The design files for the toolkit, along with the corresponding program code, are provided in the Supplementary Materials.

3.2. Software Flowchart

The program designed to interfere with the Modbus TCP/IP communication system follows these execution steps, as illustrated in Figure 6.

Step 1:

The attack toolkit sends an ARP_probe packet with the IP address of the destination device in the full address range [31]. The PLCs will send reply packets containing their own MAC addresses. The attacking toolkit then stores the corresponding MAC and IP addresses of the PLCs. The indicator light will be turned on once the addresses of the PLCs are collected. Since the system consists of only two devices currently communicating via Modbus TCP/IP, it is relatively easy to infer that they are engaged in Modbus communication once both devices are detected. However, in systems with multiple devices, additional steps are required to identify a Modbus communication link. The method for doing so is presented in the following sections. It will wait for the trigger signal to proceed to the next step.

Step 2:

The attack toolkit sends ARP_fake packets to both PLCs as shown in Figure 7. In this step, data transmission between the two PLCs will be redirected to the attack toolkit. The attack toolkit will receive the data and print the received packets, a process known as eavesdropping. To ensure that the eavesdropping process does not disrupt the system by causing data loss, packet forwarding should be performed immediately upon reception. The forwarding of the packets is done as follows: Upon receiving a packet from the PLC, the attack toolkit modifies the packet addresses and replaces the source MAC with its own MAC and the destination MAC with the MAC of the other PLC.

Step 3:

This step involves the process of modifying packets received from the master PLC and then forwarding them to the slave PLCs, which causes system discrepancies at the field site. The system utilizes Modbus TCP/IP communication, comprising four types of packets [32]:

• Query Write: the master PLC transmitted data to the slave PLC, including the starting register address, the number of registers utilized, and the corresponding data for each register.
• Response Write: the slave PLC responded with data to the master PLC, including the starting register address and the number of registers utilized.
• Query Read: the master PLC sent a request to the slave PLC, specifying the starting register address and the number of registers to be retrieved.
• Response Read: data were sent from the slave PLC to the master PLC, including the starting register address, the number of registers used, and the data for each register.

For the Query Write packet, the attack toolkit stores the incoming data and, upon receiving a Query Read packet, sends back a Response Read packet with these data. The master PLC receives the correct data it originally sent (to the attack toolkit instead of the slave PLC) whenever it requests data reading. The attack toolkit then alters the data in the registers and sends a Query Write packet to the slave PLC, causing system discrepancies.

Step 4:

Finally, when it is time to conclude the attack process, the attack toolkit will send ARP_regenerative packets to all PLCs. The system will then be restored and usually operated, making it challenging to diagnose system issues, allowing attackers to hide, and enabling them to potentially re-attack in the future.

In the consequence section, the proposed attack toolkit will be used to interfere with the typical Modbus TCP/IP communication system.

4. Experimental Evaluation

4.1. Experimental Setup

In this research, a typical industrial control system environment, as shown in Figure 8, is established using Siemens S7 series PLCs (Siemens, Munich, Germany) to evaluate the effectiveness of the proposed security toolkit. A Siemens S7-1500 CPU 1512C-1PN is configured as the master PLC—representing a device located in the control room—which transmits control commands to, and receives status updates from, slave PLCs in the field. The system includes three Siemens S7-1200 CPU 1215C units acting as slave PLCs, responsible for data acquisition and response transmission. Communication between the PLCs is facilitated via the Modbus TCP/IP protocol, which serves as the basis for validating the proposed attack and detection mechanisms. This experimental setup enables controlled injection and monitoring of malicious traffic and supports the assessment of data integrity throughout the communication process.

Two experimental scenarios are conducted to evaluate not only the inference capabilities of the proposed toolkit but also its limitations in terms of traffic handling under attack conditions. In the first scenario, the master PLC transmits the status of three input signals, specifically $I10.0$, $I10.1$, and $I10.2$, to the first slave PLC. The slave PLC then maps the received data to its corresponding output channels, $Q0.0$, $Q0.1$, and $Q0.2$. Given the minimal data volume and the small number of participating PLCs, this configuration ensures rapid communication and exhibits limited vulnerability to cyberattacks.

In the second scenario, the toolkit attempts to interfere with all devices across the network simultaneously, aiming to assess its impact on communication latency and overall network performance. This stress-testing setup evaluates whether the toolkit introduces significant delays or disruptions in a fully loaded operational environment.

Throughout both scenarios, Wireshark, a network packet capture and analysis tool, is employed in conjunction with mirror port configuration to monitor all traffic transmitted over the network. This approach enables real-time observation of normal communication patterns as well as any malicious activities introduced by the toolkit.

4.2. Experimental Results of the First Scenario

All PLCs are set to normal communication first, and after that, the Attack toolkit is used to interfere with the procedure as shown in Figure 6. In Step 1, when inserted into the system, the toolkit will read and store all the MACs together with the IP addresses of all PLCs and wait for the command signal to interfere.

When attacking in Step 2, the toolkit sends an ARP_fake message to both the master PLC and the slave PLC first, as shown in Figure 7. After that, the attack toolkit intercepts the data and forwards it to the intended recipient.

Step 3, Subfigure (a) of Figure 9 illustrates the Query Write packet from the master PLC. In the packet with Frame 1581, the input status is as follows: $I10.0=1$, $I10.1=0$, $I10.2=0$. This means that the transmitted data has a value of 001, corresponding to the hexadecimal code 00:01, and is stored in Register 1 of the Modbus TCP/IP packet frame. However, this packet was sent to the MAC address 00:00:20:07:19:98, which belongs to the attack toolkit. The data from the registers in the Query Write packet sent by the master PLC is intercepted and stored by the attack toolkit. When the attack toolkit receives the Query Read packet from the master PLC, it responds with a modified Response Read packet. This manipulation ensures that the data sent and read by the master PLC remain consistent, even though the Write Request packets intended for the slave PLC have been altered. Meanwhile, Figure 9b illustrates a write data request sent from the attack toolkit to the slave PLC. In Frame 1582, the data of register number 1 has been modified to 00:07, corresponding to the data value of 111, and transmitted to the status variables on the PLC slave side: $Q0.0=1$, $Q0.1=1$, $Q0.2=1$.

In Figure 10, the packet with Frame 1587 in Subfigure (a) is sent by the slave PLC in response to the Query Read request from the attack toolkit. The data in Register 1 is 00:07, reflecting the previously received data from the attack toolkit. Meanwhile, the packet with Frame 1588 in Subfigure (b) is sent by the attack toolkit in response to the Query Read request from the master PLC. The data in Register 1 is 00:01, corresponding to the data value 001, and is transmitted to the status variables on the master PLC side: $Q4.0=1$, $Q4.1=0$, $Q4.2=0$.

After modifying the packet’s data, the attack toolkit sends the ARP_regenerative packets to the PLCs as shown in Figure 11. Figure 12 shows the packets exchanged between two PLCs before and after the attack on the system, demonstrating that the system continues to operate normally after the attack. As shown in

Table 1. The system’s response time.

Parameters	First Scenario		Second Scenario
	Attacking	Normal Working	Attacking	Normal Working
Time Interval	6 ms	2 ms	9 ms	5 ms
Toolkit processing time	2 ms	-	2 ms	-

, the total time from when the master sends a request to when the master receives a response during interference is within 6 ms, which is less than the master’s response timeout of 2 s. This value is configured by the RCV_TIMEOUT parameter in the MB_CLIENT block, with a range of 0.5–55 s, and a default value of 2 s. Therefore, such a packet latency still ensures normal operation for the initial system.

Figure 13 shows that the previously written data from the master PLC matches the current response data. However, the output of the PLC slave contains incorrect data, demonstrating that the master is still operational despite being under attack. For more information, please refer to the Supplemental Files for the experimental videos.

4.3. Experimental Results of the Second Scenario

In this scenario, the toolkit attempts to interfere with all devices across the system simultaneously. The scan cycles of all PLCs are recorded to assess the toolkit’s impact on network bandwidth and communication performance within the system. The toolkit interferes with each master–slave communication by the procedure presented in Section 3.2. However, due to the presence of multiple devices in the network, Step 2 requires the attack toolkit to first perform ARP spoofing on all devices and initiate a MITM attack by forwarding intercepted packets to their intended destinations. Subsequently, by analyzing the captured packets and comparing them against the characteristics outlined in Figure 1—including packet length, function code, and default port usage—the toolkit can accurately identify the Modbus TCP connections.

Figure 14 illustrates the moment when the attacking device intervenes in all connections within the network. The packets are modified, causing incorrect operations on the slave side, while on the master side, the sent and received data appear completely consistent. The observed results are presented in Table 1. The time interval between the moment the master PLC sends a query and receives a response increased to 5 ms under normal operating conditions and 9 ms during the attack by the toolkit. In comparison, the corresponding time intervals in the first scenario were 2 ms and 6 ms under the same respective conditions. This increase is primarily attributed to the expansion of the network size. Nevertheless, no significant changes in the processing latency were introduced by the toolkit itself. These results indicate that the toolkit continues to effectively interfere with communication even as the network scale increases.

5. Proposed Security Solution

In this section, we present a security solution to protect against ARP spoofing attacks. The same toolkit is used to monitor and counter ARP spoofing attacks in the network. The operation of the protective device is outlined in the flowchart in Figure 15 and can be implemented through the following steps.

Step 1:

The security device initiates by scanning the network to identify all connected devices. It then establishes a man-in-the-middle (MITM) position to observe active communications between devices. After this discovery phase, the security device obtains comprehensive knowledge of all ongoing connections within the network.

Step 2:

The device transitions to a passive monitoring mode, continuously listening to network traffic. If it detects a packet containing a MAC address that does not match any entry in its previously recorded list, it proceeds to Step 3 to handle the potential threat.

Step 3:

Upon identifying a suspicious device, the security device immediately sends an alert to the monitoring department via a Subscriber Identity Module (SIM) module or alternative IoT communication modules. Simultaneously, it begins broadcasting regenerative ARP packets to reinforce and protect the legitimate connections identified during Step 1. The frequency of these regenerative ARP transmissions is adjusted based on network bandwidth, communication speed, and current data load.

Step 4:

Once the monitoring personnel resolve the security incident, they transmit a signal indicating that normal operations can resume. Upon receiving this signal, the security device deactivates its alerts, stops broadcasting regenerative ARP packets, and returns to its passive traffic monitoring function.

In our experimental setup, the value of $T_{\mathrm{set}}$ was configured to 2 s, providing sufficient time for the system to detect and map all active connections within the network. Additionally, the frequency of regenerative ARP packet transmission was set at 1 Hz. Since attackers typically perform ARP spoofing only once, this setting ensures continuous restoration of legitimate connections without overwhelming network resources.

It should be noted that some devices communicate using Unicast or Multicast MAC addresses. Therefore, a network monitoring function, such as a mirror port, can be configured on the switch or router to capture all packets exchanged between devices. This configuration ensures that the security device can observe all transmitted traffic. However, in high-traffic networks, mirroring all packets—including non-ARP traffic—may exceed the capacity of the mirror port, potentially resulting in packet loss. This issue becomes more pronounced when multiple master–slave pairs communicate simultaneously. Future improvements could involve implementing selective traffic capture strategies or distributed monitoring architectures to address this limitation more effectively.

6. Conclusions and Future Work

This research introduced a novel, lightweight hardware-based security device designed to detect and mitigate ARP spoofing attacks in industrial control system networks, specifically focusing on Siemens S7 PLC environments communicating via Modbus TCP/IP. Unlike conventional solutions that rely on host-based detection or enterprise-grade monitoring, the proposed approach operates independently of computer systems, providing a deployable security layer suitable for both legacy and modern ICS infrastructures.

Experimental evaluations demonstrated that the proposed toolkit effectively interferes with malicious ARP activities while maintaining acceptable communication performance. Tested with Siemens S7-1500 and S7-1200 PLCs, the device consistently preserved network stability and demonstrated minimal additional latency, even as the network size increased. The toolkit reliably handled traffic rates up to approximately 5 Mbps without introducing significant delays (under 2–3 ms). It was further estimated to support up to 10–15 master–slave communication pairs concurrently under typical Modbus TCP/IP traffic conditions.

However, some technical limitations were identified. When operating in extremely high-throughput environments exceeding 10 Mbps, the device may experience increased packet queuing and processing delays, which could affect real-time communication. Additionally, while the proposed system effectively defends against ARP spoofing attacks, it does not address confidentiality concerns, as Modbus payload data remains unencrypted and susceptible to passive interception. These limitations should be considered when deploying the device in high-demand or highly sensitive ICS environments.

Future work will aim to address these limitations and enhance the capabilities of the proposed system. Planned developments include the following:

• Integration of lightweight encryption mechanisms or secure tunneling methods to provide confidentiality for Modbus communications without compromising real-time requirements.
• Expansion of detection capabilities to cover additional network-layer threats such as TCP session hijacking, replay attacks, or Modbus function code manipulation.
• Field testing in larger-scale, real-world industrial environments to evaluate scalability, robustness, and long-term operational impacts.

Through these improvements, the proposed toolkit aims to become a comprehensive, low-overhead solution for enhancing the security resilience of ICS networks against evolving cyber threats.