Monitoring OT protocols such as Modbus and DNP3 for anomalies

Monitoring operational technology traffic is different from watching a normal office network. In an OT environment, the useful signals are often hidden in protocol behaviour rather than in obvious malware indicators. That is especially true for Modbus and DNP3, where a small change in function codes, command timing, or peer relationships can be more meaningful than a generic port alert.

For UK SMEs running manufacturing lines, utilities, building controls, or other industrial systems, the goal is not to inspect every packet for the sake of it. The goal is to understand what normal control traffic looks like, then detect the deviations that could indicate misuse, misconfiguration, or an unsafe change. That approach fits well with the wider thinking behind IEC 62443 and with the zone and conduit model described in zone and conduit modelling under IEC 62443.

Why protocol-aware monitoring matters in OT environments

Modbus and DNP3 are both common in industrial control systems, but they are used in different ways and have different operational assumptions. Modbus is often simple, chatty, and predictable. A master polls devices, reads registers, and occasionally writes values. DNP3 is more structured and is often used in SCADA environments where a master communicates with outstations over longer distances and may receive unsolicited events.

Generic network monitoring can tell you that traffic exists between two hosts. Protocol-aware monitoring tells you whether the traffic makes sense. That distinction matters because many OT incidents do not start with an obvious binary payload or a known malicious signature. They start with a legitimate-looking command sent at the wrong time, from the wrong host, or to the wrong device.

Binary and function-level visibility improves detection quality because it lets you reason about intent. A Modbus read of holding registers is normal in many plants. A write to a coil from an engineering workstation during production hours may be normal or may be a sign of change activity. The context is what matters. The same is true for DNP3 object requests, unsolicited responses, and control operations. If you can see the protocol semantics, you can build detections that are more precise and easier to explain to operations teams.

What normal Modbus and DNP3 traffic looks like

Before you can detect anomalies, you need a baseline of normal behaviour. In most environments, Modbus traffic has a regular polling pattern. A PLC, HMI, historian, or supervisory system will query a device at a consistent interval. The same source and destination pairs tend to repeat, the same function codes appear again and again, and the timing between requests is usually stable.

DNP3 traffic is often more varied, but it still follows a recognisable pattern. A master communicates with one or more outstations, requests specific classes or object groups, and may receive event-driven updates. In a well-run environment, the communication relationships are stable and the traffic volume is usually tied to process needs rather than user behaviour.

Useful baseline indicators include:

• Source and destination IP addresses, MAC addresses, and device roles.
• Protocol version, function code, object group, variation, and qualifier where available.
• Typical request frequency, burst size, and session duration.
• Normal read-to-write ratios.
• Expected maintenance windows and vendor support periods.
• Which assets are allowed to initiate control traffic and which should only respond.

It is also worth capturing process context. A traffic pattern that is normal during a planned line change may be suspicious during steady-state production. If you already maintain asset and network documentation, use it to enrich the baseline rather than relying on packet data alone.

Anomaly types worth detecting first

Not every unusual packet is a security event. In OT, the most useful detections are the ones that map to operationally meaningful risk. Start with anomalies that could change process state, alter device behaviour, or indicate a new communication path.

For Modbus, high-value anomalies include unexpected write operations, changes in register access patterns, and command sequences that do not match the normal polling model. A device that is usually read-only should not suddenly begin accepting writes from a new source. Likewise, a jump in function code variety can indicate a tool, script, or device talking in a way that is not part of the usual process.

For DNP3, focus on control commands, unsolicited responses from devices that do not normally send them, and abnormal object requests. A master that begins querying new object groups, or an outstation that starts behaving like a master, deserves attention. Changes in the master-to-outstation ratio can also be useful, particularly if they correlate with a new engineering workstation or remote access route.

Other useful anomaly classes are:

• New source and destination pairs in a control zone.
• Traffic appearing outside expected shift patterns or maintenance windows.
• Sudden increases in request rate or repeated retries.
• Sessions that last longer than the normal control cycle.
• Protocol downgrade, malformed frames, or parsing errors.

These are not proof of malicious activity on their own. They are indicators that something has changed and should be checked against change records, maintenance tickets, and engineering activity.

Building a practical detection baseline

A good baseline starts with asset inventory. You need to know which HMIs, PLCs, RTUs, historians, engineering workstations, gateways, and remote access systems are in scope. If you do not have a reliable inventory, start by identifying the most critical production paths and the devices that can issue control commands. That gives you a manageable first monitoring set.

From there, build a protocol inventory. Record which assets speak Modbus, which speak DNP3, which use both, and which are only passive observers. In many environments, the same physical network carries multiple operational roles, so peer group analysis is useful. A PLC should be compared with similar PLCs, not with a historian or a jump host.

Historical traffic is the best source of baseline data. If you have packet captures, industrial IDS logs, or flow records, use at least several weeks of data if possible. Look for stable patterns by time of day, day of week, and production state. Where the environment is small, even a shorter baseline can be useful if it is paired with engineering knowledge of the process.

When defining acceptable variance, be careful not to overfit. OT environments do change. Firmware updates, seasonal production shifts, and vendor maintenance can all alter traffic patterns. The aim is to detect meaningful deviation, not to freeze the network in time. This is similar in spirit to the way you would approach observability in other security domains, as discussed in logging and monitoring basics for small teams, but with tighter operational constraints and a stronger need for protocol context.

Detection logic for Modbus traffic

Modbus is often the easier protocol to start with because the traffic model is simple. Most environments rely on a small number of function codes, and many devices are expected to behave consistently. That makes deviations easier to spot if you have a clean baseline.

Useful detections include:

• Write operations from hosts that normally only read.
• Writes to unexpected registers, coils, or discrete inputs.
• Function codes that are rare in your environment, especially if they appear from a new source.
• Changes in scan behaviour, such as a polling interval that becomes much shorter or much more erratic.
• Repeated exception responses, which can indicate malformed requests or device stress.

In practice, a lot of false positives come from maintenance tools, vendor software, and engineering workstations. A commissioning laptop may legitimately perform writes during a change window. A historian may query a wider set of registers after a configuration update. The answer is not to ignore these events. The answer is to tag them with context, tie them to approved maintenance activity, and make sure they are visible in the alert workflow.

If you are using a network security monitoring platform, create rules that combine protocol fields with asset identity. For example, alert on Modbus write functions from any host outside the engineering workstation group, or on writes to a PLC that is normally read-only. This is more robust than alerting on the function code alone.

Detection logic for DNP3 traffic

DNP3 requires a slightly different approach because the protocol is more expressive and often used in distributed SCADA environments. The most useful detections usually come from changes in command direction, object requests, and response behaviour.

Start by identifying which systems are masters and which are outstations. Then monitor for:

• Control commands issued from a host that is not an approved master.
• Unsolicited responses from devices that normally only answer polls.
• Requests for object groups or variations that are not part of the normal operational profile.
• Unexpected changes in class scans or event polling frequency.
• Communication from a new remote access path into the control network.

One practical detection pattern is to watch for changes in the master-outstation relationship. If a new host begins to query multiple outstations, or if an existing master starts talking to devices outside its normal scope, that is worth investigating. In small environments, even a single new peer can be significant.

Another useful signal is timing. DNP3 traffic often follows a predictable cadence. If a master begins sending bursts of requests at unusual times, or if an outstation starts responding outside its normal event pattern, that may indicate a configuration issue, a failed polling cycle, or a more serious control problem.

Tooling and telemetry sources

To monitor OT protocols properly, you need visibility at the network layer and enough context to interpret what you see. Passive network sensors are usually the safest starting point. They can be deployed on SPAN ports, network taps, or mirrored segments without introducing active risk to control traffic.

Industrial intrusion detection systems can parse Modbus and DNP3 directly and often provide protocol-aware metadata out of the box. That metadata is useful for alerting, but it should not be your only source. Raw packet capture, even if sampled or short-retention, is valuable for validation and investigation. Flow data can also help with trend analysis and peer grouping, especially where full packet capture is too expensive to retain for long.

A SIEM is useful for correlation, enrichment, and case management. It can combine protocol alerts with asset data, maintenance tickets, remote access logs, and identity events. An NDR platform can help with behavioural baselining and anomaly scoring, particularly if it understands industrial protocols. For investigation, packet capture tools such as tcpdump or Wireshark remain valuable because they let analysts confirm whether an alert is a genuine control event or a benign process change.

When choosing where to collect telemetry, focus on choke points that see the most important traffic without creating blind spots. In a segmented OT design, that often means monitoring at the boundary between zones and at the conduits that carry control traffic between supervisory systems and field devices.

Tuning for false positives in OT

False positives are a real issue in industrial monitoring because OT environments are full of exceptions. Planned maintenance, vendor support, emergency changes, and process recovery can all look unusual from a network perspective. If you do not tune for these realities, operators will stop trusting the alerts.

The best way to reduce noise is to separate known exceptions from unknown ones. Maintenance windows should be recorded in advance where possible. Vendor access should come through controlled paths and be tied to named systems or accounts. Engineering workstations should be grouped separately from general-purpose IT devices so that their behaviour can be compared against the right baseline.

Allowlisting can help, but it should be used carefully. If you allowlist a source, destination, and function code combination too broadly, you may hide genuine risk. A better pattern is to allowlist specific combinations for a limited time or within a defined change window, then review them afterwards. That keeps the detection logic honest while still supporting operations.

It also helps to score alerts by confidence and impact. A single unusual read from a maintenance host may be low priority. An unexpected write to a safety-related controller from a new source during production hours is much higher priority. This kind of triage logic is more useful than a flat severity model.

How this maps to IEC 62443 and broader detection practice

IEC 62443 is useful here because it encourages you to think about assets, trust boundaries, and security requirements in a structured way. Monitoring should follow the architecture. If you have defined zones and conduits, your detection points should sit where those boundaries matter most. That gives you better coverage and makes it easier to explain why a particular alert is relevant.

In practical terms, a zone-based approach helps you decide what normal looks like. A control zone containing PLCs and local HMIs will have different traffic patterns from a supervisory zone or a remote maintenance conduit. If you monitor each zone according to its purpose, your detections become more precise and easier to maintain.

This also aligns well with NIST CSF Detect and Respond activities. Detect is about identifying anomalies quickly enough to matter. Respond is about making sure the alert leads to a sensible operational decision. In OT, that decision often involves both security and engineering staff, because the impact of a change can be physical as well as digital.

Operationalising alerts and response

Once you have detections, you need a response process that fits the plant. The first step in triage is usually to confirm the asset, the protocol, the command type, and the business context. Ask whether the activity matches a change ticket, a maintenance window, or a known engineering task. If it does not, check whether the source host is approved for that zone and whether the destination device should accept that command at all.

Security teams should avoid making assumptions about process impact. A network anomaly may be harmless, but it may also be the first sign that a controller has been reconfigured or that a remote support session is active. Engineering teams can usually tell you whether a command is expected, but they need the right evidence. That means preserving packet metadata, timestamps, source and destination details, and any related authentication or remote access logs.

Escalation criteria should be simple and agreed in advance. Examples include unexpected write operations, control commands from unauthorised hosts, new communication paths into critical zones, or repeated protocol errors that coincide with process instability. If an alert suggests a live change to a production device, the response path should be clear and rehearsed.

Where appropriate, use containment carefully. In OT, blocking traffic can have operational consequences, so response actions should be proportionate. Sometimes the right first step is to isolate a management workstation, disable a remote access session, or increase monitoring on a specific conduit rather than shutting down a process link outright.

A phased implementation approach for UK SMEs

For most UK SMEs, the right way to start is small and focused. Begin with the most critical assets and the highest-risk protocol paths. That usually means the supervisory systems, engineering workstations, and the few conduits that can issue control commands to production devices.

Phase one should aim to answer three questions: who talks to whom, what functions are used, and when do those conversations happen? Once you can answer those questions reliably, you can build detections around writes, unusual peers, and timing changes. Do not try to cover every device on day one if that means you cannot tune the alerts properly.

Phase two should expand coverage to adjacent zones and add more context. Bring in maintenance records, remote access logs, and asset ownership data. Use that to refine baselines and reduce noise. If you have a SIEM or NDR platform, this is the point where correlation starts to pay off.

Phase three is about operational maturity. Test your detections against real maintenance scenarios, review false positives regularly, and update the baseline when the process changes. If you already have an incident response process, make sure OT protocol alerts are included in it rather than handled as an exception.

That phased approach is usually more sustainable than a large-scale monitoring project. It gives you value early, keeps the engineering burden manageable, and makes it easier to justify further investment because the detections are tied to real operational risk.

If you are planning an OT monitoring programme and want help shaping the architecture, baselines, or alerting approach, speak to a consultant.

Frequently asked questions

What is the difference between Modbus and DNP3? Modbus is a simpler industrial protocol that is commonly used for polling and basic control, while DNP3 is more feature-rich and is often used in SCADA environments with masters, outstations, and event-driven communication.

What is the DNP3 protocol for SCADA? DNP3 is a communications protocol used by SCADA systems to exchange telemetry and control data between a master and remote devices such as outstations, RTUs, and field equipment.