Modbus has been moving process data since 1979, and its TCP variant has been doing the same on Ethernet since the late 1990s. It sits in plants, substations, water works, building plant rooms and an enormous number of skid-mounted packages that nobody has opened in a decade. It was also designed for a world where the cable was the security boundary. There is no login, no encryption and no idea of a user. A device will accept a command to write a setpoint just as readily as a command to read a temperature, from anyone who can open a TCP connection to port 502.

That is why Modbus TCP security is, in practice, a firewall problem first. You rarely get to fix the protocol, and often you cannot touch the device, so you control the path to it. This guide covers how to do that properly: the rules to write and the order to write them in, how far function code inspection can take you, where TLS-secured Modbus on port 802 fits, how to detect abuse, and how to roll all of it out without disturbing a process that has run unchanged for fifteen years. It is written for security leaders and OT engineers who already know why Modbus is risky and want a rule base they can defend.

Why Modbus TCP security starts at the firewall

What the protocol does not give you

Read the Modbus application protocol specification and you will not find a security section, because the original deployment model assumed a closed network. Five gaps matter for firewall design:

• No authentication. The server does not know or care who the client is. Source IP is the only identity you have, and it can be spoofed or borrowed.

• No authorization. Any client can use any function code against any register the device exposes. Read-only is not a state a Modbus server can enforce on its own.

• No encryption or integrity. Everything crosses the wire in cleartext, so commands can be observed and replayed. CISA's advisory ICSA-17-101-01 on the Modicon Modbus protocol describes exactly this: cleartext transmission that lets an attacker replay run, stop, upload and download commands.

• No session meaning. The unit identifier in the header is a routing field for gateways, not a user or a role.

• Fragile parsing. Embedded stacks are not always robust against malformed input. CISA's April 2025 advisory ICSA-25-114-01 covers several Schneider Electric Modicon controller flaws reachable over Modbus that can cause denial of service.

The weakness also keeps showing up in new products. In June 2026 a missing-authentication flaw was published for the Modbus TCP service on the Delta DVP-12SE PLC (CVE-2026-12819), which lets an unauthenticated network attacker interact with security-sensitive PLC functions. Forescout's analysis of CISA data counts 3,637 ICS advisories covering 12,174 vulnerabilities across 689 vendors between March 2010 and January 2026. The vendor will not always fix this for you, and your patch window is measured in years. The network has to carry the load.

This is not theoretical: FrostyGoop

On 22 and 23 January 2024, attackers disrupted a municipal district energy company in Lviv, Ukraine. Heating to more than 600 apartment buildings was cut for roughly two days in sub-zero temperatures. Dragos later identified the tool used, FrostyGoop, which it describes as the ninth ICS-specific malware and the first to use Modbus TCP over port 502 directly against controllers.

The mechanics are worth studying because they are so plain. FrostyGoop is written in Go, reads a JSON configuration file naming a target IP and the holding registers to write, and sends ordinary Modbus TCP commands. It needs no exploit. Dragos reported that antivirus products did not detect it when it was found, and that because many targets sit directly on the internet, no prior compromise of the victim network was needed. The Ukrainian CSSC and Dragos tied it to ENCO controllers in this incident, but the same approach works against any Modbus device that answers.

Not everyone agrees on how sophisticated or how state-linked the tool was. An independent comparative analysis from Trout argues that it lacks the hallmarks of advanced state ICS malware. For a defender the debate matters less than the common thread: reachable devices, flat networks and an unauthenticated protocol. A well-built firewall policy removes all three of those enablers.

Exposure is still growing

• Around the time of the FrostyGoop report, Dragos found tens of thousands of Modbus devices reachable from the internet (about 46,000, as reported by Cybersecurity Dive).

• Bitsight's 2025 sweep counted roughly 180,000 internet-exposed ICS/OT devices, a 12 percent year-over-year rise, with Modbus among the usual suspects.

• A Comparitech scan reported in April 2026 found 179 suspected industrial devices answering on port 502, including models linked to energy and infrastructure environments. Its authors noted that attackers with limited skills could read and modify data on them.

If someone in your organization says "our PLCs aren't on the internet," the cheapest useful action this quarter is to prove it (see the self-audit steps later in this guide).

Know the traffic before you write the rule: Modbus TCP anatomy for firewall engineers

You can write a decent port 502 rule without understanding the packet. You cannot write a good function code or register rule without it. Every Modbus TCP message is an MBAP header followed by a protocol data unit (PDU):

The header is seven bytes and the PDU is capped at 253 bytes, so a full frame stays within 260 bytes. That small, regular structure is why Modbus is one of the easiest industrial protocols to inspect deeply, and why packet-filter-only policies waste the opportunity.

Function codes and how to treat them

Function 43 is a good example of why this table matters. Legitimate asset inventory tools use it to read vendor and model strings, and so do attackers building a target list. The same packet, two different intents. The only way to tell them apart is by source, which is exactly what a role-based rule does.

Where the firewall goes: placing Modbus conduits in a zoned architecture

IEC 62443 and NIST SP 800-82 Rev. 3 both describe the same idea: split the control environment into zones of similar trust and allow traffic between them only through defined conduits. The firewall rule base is how a conduit gets enforced. For Modbus, the useful questions are where the flows actually run and which of them should exist at all.

Inline firewall, tap or both

Enforcement needs an inline device. Visibility can come from a passive tap or SPAN port feeding a sensor. Most mature sites use both: the firewall at the zone boundary enforces policy, and a sensor watching the same traffic gives independent detection and a second opinion on what the firewall let through. Put the enforcement point as close to the devices as is practical, usually at the area or cell boundary rather than only at the site edge, so that one compromised supervisory host cannot talk to every controller on the plant.

Decide fail-open or fail-closed on purpose

Inline appliances can fail. Hardware bypass will keep the process talking while you lose enforcement. Failing closed protects the policy but stops control traffic. There is no universal answer. Decide per zone with operations and safety engineering, document it, and test it. Safety instrumented systems should sit on their own segment with their own rules, and a firewall change should never be able to affect their communications.

Modbus TCP firewall rules: a practical rule base

This is the part most guides compress into a bullet. Below is an ordered policy for one conduit between a supervisory zone and a control zone. Adapt the groups and names, keep the logic.

Layer 3 and 4 baseline

Three habits make this rule base survivable over time. Use named groups instead of raw IPs so a replaced HMI means one object change. Give every rule an owner and a review date. And log the final deny rules so you find out about the traffic nobody documented.

A minimal example on Linux nftables

The sketch below shows the L3/L4 logic on a Linux bridge or router. It does not inspect function codes, so treat it as the baseline layer only, and validate the syntax on your own distribution in a lab before using it.

Linux has a history here. The open-source Modbusfw project, started by Cisco researchers, patched Netfilter to make accept and drop decisions from Modbus header values, including function code, unit ID and reference number. That earlier work reached the same conclusion most industrial firewalls now act on: blocking port 502 is not enough, because allowing it passes every command.

Function code allowlisting by role

This is the control that turns "reachable" into "reachable and still safe." Define it per role, not per site.

Go beyond function codes: addresses, quantities and unit IDs

Function code filtering cuts the attack surface a lot. A write to the wrong register is still a write, though. Where your firewall supports it (capabilities differ widely between vendors, so check before you rely on it), add these checks:

• Register range allowlists. Permit writes only to the setpoint block you actually use. Deny writes to registers that hold mode, configuration, or interlock bypass values.

• Quantity limits. A Write Multiple Registers request that touches 100 registers when your SCADA writes two is not your SCADA.

• Unit ID restrictions. Behind a TCP-to-serial gateway the unit ID chooses which serial device receives the command. Permit only the IDs in your communication matrix. Unit ID 0 is the broadcast address on serial lines, so unrestricted broadcast through a gateway can reach many devices from one packet.

• Protocol sanity. Drop frames where the protocol ID is not zero, the length field does not match the payload, or the PDU exceeds 253 bytes. This also catches fuzzing and some scanning tools.

Connection handling: timeouts, caps and rate limits

A commonly repeated tip is to set short firewall connection timeouts, around 30 to 60 seconds. Be careful with it. Many Modbus masters hold a TCP connection open and poll it on a fixed cadence. If the firewall's idle timeout is shorter than the slowest poll interval, it will tear down a healthy session and the master will reconnect, producing data gaps and log noise. Too long, and you hold state for dead sessions. A better method:

1. Measure the slowest poll interval for each master and device pair during baselining.

2. Set the idle timeout to a multiple of that interval (for instance three to five times) and enable TCP keepalive where the master supports it.

3. Look up each device's maximum simultaneous TCP connections. Many small PLCs and meters support only a handful. Cap connections per source and per destination well below that limit so a misbehaving client or a scan cannot exhaust it.

4. Rate-limit new connections from each source, as in the nftables example, to blunt scanning and connection floods.

Logging that you will actually use

• Log denies on the Modbus port and on the final default-deny rule.

• Log allowed writes with source, destination, function code, address and quantity. These are the events you reconstruct an incident from.

• Forward to the SIEM or OT monitoring platform in near real time, and keep devices on synchronized time. Logs from three systems with three clocks are close to useless in an investigation.

• Alert on the change in behavior, not just on the event: a master that has never written before and now writes, or a write outside the usual window.

Deploy without breaking the process: learn, alert, enforce

The fastest way to lose operations' trust is a firewall that drops a legitimate poll at 2 a.m. Industrial firewall vendors generally support a learning or monitor-only profile for exactly this reason: a temporary permit rule that logs every function code it sees, placed at the top of the policy, so you discover what is really on the wire before you block anything. Use it.

1. Discover passively. Capture Modbus traffic from a tap or SPAN for long enough to include shift changes, batch cycles, maintenance and reporting jobs. Two to four weeks is a sensible starting point for most sites; some processes need longer.

2. Build the communication matrix. For each flow record master, server, unit ID, function codes, register ranges, poll rate, owner and business purpose. This single table is the real asset. The firewall rules are just its output.

3. Run in alert-only mode. Write the target rule base, but set the action on the not-yet-trusted rules to permit-and-log. Review what would have been denied.

4. Resolve exceptions with the people who run the plant. Every flow that does not fit the matrix is either undocumented but legitimate (add it) or a finding (fix it).

5. Test in a lab or at a non-critical cell. Include failure modes: firewall reboot, bypass mode, failover, and a rule rollback.

6. Enforce in stages. Start with the edge denies (internet and IT-origin traffic to port 502), then the L3/L4 allowlist, then function code filtering for write codes, then register-level controls. Each stage gets its own change window and rollback.

7. Operate it. Review rules quarterly, expire temporary access automatically, and treat any new Modbus flow as a change that needs an update to the matrix.

Detection behind the firewall: what to alert on

Firewalls can only enforce what you have written down. Passive monitoring tells you what is happening that you have not. Zeek's Modbus analyzer writes a modbus.log with source, destination, function and exception for every transaction, and Suricata has native Modbus parsing and rule keywords. Dragos published a set of IDS rules alongside its FrostyGoop research that is a good starting point for any team. These are the use cases that give the best signal for the effort:

Two illustrative Suricata rules follow. Enable the Modbus app-layer parser first, define the host groups, and run them against a captured baseline before alerting in production.

Detection and enforcement reinforce each other. The rules your sensor fires most often point to flows you should either document and allow, or block.

Modbus/TCP Security on port 802: TLS, roles and what they mean for your firewall

The Modbus Organization published the Modbus/TCP Security specification in 2018 and has revised it since. It wraps the unchanged Modbus application PDU in TLS and runs on its own registered port, 802. It also adds two things that plain Modbus never had:

• Mutual authentication. Server and client each present an X.509v3 certificate. The firewall no longer has to guess identity from an IP address.

• Role-based authorization. The client's role travels in a certificate extension (OID 1.3.6.1.4.1.50316.802.1), so a server can allow a certificate with an "operator" role to write and one with a "viewer" role only to read.

Specifications require TLS 1.2 or later, and several libraries and controllers now implement it, including industrial gateways and newer PLCs. China has also adopted the approach in its national standard GB/T 41868-2022. It is a real upgrade path, but it changes how your firewall sees the world.

How to handle the visibility trade-off

• Prioritize by risk. Move the highest-risk conduits first (anything crossing zones, anything remote), and leave low-risk intra-cell links for later.

• Enforce authorization at the endpoint. Use roles in certificates so the device itself rejects a write from a read-only client. This is stronger than any firewall because it does not depend on inspecting traffic.

• Move inspection to a trusted point. Where you need function code control and TLS together, terminate the session on a Modbus-aware gateway that authenticates the client and forwards only the permitted codes to the legacy device. This pattern also works as a bump-in-the-wire for devices that will never support TLS.

• Do not leave 502 open "just in case." Some implementations can listen on both ports. Once clients have moved, disable plain Modbus on the device and deny 502 across the conduit.

• Keep monitoring. Encrypted flows still show endpoints, volumes, timing and failures. Add endpoint-side logging for operations that sensors can no longer read.

• For legacy gear, tunnel it. An IPsec or other encrypted tunnel between zone boundaries gives confidentiality and integrity, though not per-client authorization. Apply the function code policy after the tunnel terminates.

Serial Modbus (RS-485) remains a separate problem. A December 2025 IETF Internet-Draft notes that no standardized security mechanism exists for Modbus serial links, so the controls in this guide protect the TCP side and gateways, not the serial bus itself.

Remote access, vendors and the internet edge

• Never publish port 502 to the internet. That includes port forwards on cellular routers and cloud gateways, which are a common way Modbus ends up exposed. If remote data is needed, push it out through a DMZ service instead of pulling it in.

• Route vendor access through a controlled jump host. Require MFA, record sessions and grant access for a defined time. The jump host becomes the only source address permitted to reach the devices, so your Modbus rules stay simple.

• Block outbound from controllers. PLCs and RTUs rarely need to reach the internet. A deny rule here limits what a compromised device can do.

• Audit your own exposure. Search your public IP ranges for 502 and 802 on a regular schedule using a service such as Shodan or Censys, and have an authorized tester confirm from the outside. Nmap's modbus-discover script can confirm reachability. Only scan networks you are permitted to test, and be cautious with active scanning inside production OT. Fragile devices can fault on unexpected traffic, so coordinate with operations and keep scans slow and read-only.

• Harden the allowlisted hosts. Source IP restriction is only as strong as the hosts on the list. The SCADA server is exactly what an attacker wants to pivot from, so add layer 2 controls such as port security and ARP inspection, application allowlisting and strict account control on those machines.

Mapping Modbus firewall controls to IEC 62443 and NIST SP 800-82

Auditors and boards respond to standards. The good news is that a well-run Modbus firewall policy already satisfies a large part of what they ask for. NIST SP 800-82 Rev. 3, published in September 2023, provides an OT overlay of SP 800-53 Rev. 5 controls and detailed guidance on segmentation, DMZs and firewall placement. IEC 62443-3-3 lays out the system security requirements by foundational requirement and security level.

For organizations in the EU, the same controls support the risk-management measures required under NIS2 Article 21, notably network segmentation, monitoring and protection of communications. In IEC 62443 terms, the rule base is where you record and enforce the conduit policy set out in your zone and conduit risk assessment (62443-3-2). Document it that way and the audit conversation gets shorter.

Ten mistakes that undermine Modbus firewall policies

1. "It's the control network, allow 502 any to any." Flat OT is the condition FrostyGoop-style attacks rely on.

2. Writing rules from the network diagram instead of observed traffic. Diagrams show intent. Packet captures show reality.

3. Treating the SCADA server as trusted by default. It is an allowlisted source, which makes it the best pivot an attacker can compromise.

4. Copying someone else's timeout numbers. Sessions drop, polls fail, and the team learns to distrust the firewall.

5. Blocking diagnostics permanently, or leaving them open permanently. Time-box them to commissioning and maintenance instead.

6. Inspecting only at the site edge. East-west traffic inside a plant is where a compromised host moves, and where PLC-to-PLC Modbus lives.

7. No plan for the firewall's own failure. Decide fail-open or fail-closed per zone before the first outage.

8. Temporary rules that never expire. A vendor rule from a project three years ago is an open door. Give every exception an owner and an end date.

9. Assuming TLS makes network controls optional. Mutual TLS proves who connected. It does not decide whether that identity should write to every register.

10. Logging only the denies. Allowed writes tell you what an attacker, or an honest mistake, actually changed.

A maturity model for Modbus TCP security

A 30-60-90 day plan

Frequently asked questions about Modbus TCP security

1.What port does Modbus TCP use?

Modbus TCP uses TCP port 502, registered with IANA. The TLS-secured variant, Modbus/TCP Security, uses TCP port 802.

2.Is Modbus TCP secure?

No. Standard Modbus TCP has no authentication, authorization or encryption, so security has to come from the network around it: segmentation, firewall rules, function code filtering and monitoring. Modbus/TCP Security on port 802 adds TLS and certificate-based roles, but only on devices and clients that support it.

3.Can a firewall filter Modbus function codes?

Yes, if it can inspect Modbus at the application layer. Industrial firewalls and some next-generation firewalls offer Modbus DPI with function code allowlists, and some support register range and unit ID checks. A basic packet filter can only allow or block the port.

4.Should I just block port 502?

Block it everywhere it should not be used, especially across the internet and IT/OT boundary. Inside OT you usually need to allow it between specific hosts, so the right answer is a narrow allowlist with function code control, not a blanket block.

5.Does TLS on port 802 replace a firewall?

No. TLS authenticates and encrypts the session, and role certificates can limit what a client may do, but you still need segmentation, default-deny rules, monitoring and a plan for inspection, since encryption hides function codes from the firewall.

6.How do I detect attacks on Modbus TCP?

Capture traffic passively and alert on writes from unauthorized sources, device identification reads, broadcast or unit ID sweeps, new masters, out-of-window writes, malformed frames and shifts in polling cadence. Zeek and Suricata both parse Modbus.

7.What standards apply to Modbus firewall design?

IEC 62443 (notably 62443-3-3 SR 5.1, SR 5.2, SR 3.1 and SR 6.2) and NIST SP 800-82 Rev. 3 provide the main frameworks for zones, conduits, boundary protection and monitoring. The Modbus Organization's specifications define the protocol and its security variant.

How Shieldworkz helps secure Modbus and industrial protocols

Getting from an open Modbus network to an enforced, monitored one is a program rather than a purchase: discover the real traffic, design zones and conduits, deploy enforcement, add detection and keep it healthy. Shieldworkz delivers industrial OT cybersecurity as a full stack of services, platform capabilities and solutions covering SCADA, OT and IoT environments, so one team can carry a Modbus policy from assessment through monitoring and response.

• Passive discovery of Modbus flows, masters, devices and function code usage

• Segmentation design and firewall policy aligned to IEC 62443 and NIST SP 800-82

• OT-aware monitoring and detection tuned to your communication baseline

• Secure remote access and vendor access design

• Assessment against your target security levels, with a prioritized roadmap

If you would like a second set of eyes on your Modbus exposure and rule base, talk to the Shieldworkz team about an OT security assessment.