Press Enter to search or Esc to close

Secure Control Layer Series · Industrial / OT

Modbus Command Protection

Command-level monitoring, detection, prevention, notification, and audit evidence for PLCs, RTUs, drives, and other Modbus-managed field devices across water, power, manufacturing, and industrial control networks.

A firewall sees port 502. PacketViper sees the command.

From open command path to controlled command path

Observe → Understand → Decide → Enforce → Notify

PacketViper sits inline between the network and Modbus field devices, and evaluates every command before it reaches a PLC, RTU, or controller. Read traffic stays visible and permitted; unauthorized write commands can be blocked surgically.

Observe

See every Modbus operation on the wire: source, target device, function code, unit ID, register, value, and time.

Understand

Decode the command and place it in context: which device, which function code, which register, what value, which source, what asset role.

Decide

Evaluate the command against policy: authorized source, read versus write, register range, allowed value, time window.

Enforce

Permit reads, and block unauthorized write commands inline at wire speed, scoped to the command and device.

Notify

Update dashboards, raise alerts, and record audit evidence for every relevant event as it happens.

Why This Matters Now

When a command can move a pump, open a breaker, or change a setpoint, the command becomes a control point.

PLCs, RTUs, drives, and controllers behind water, power, manufacturing, and transportation are networked operational assets. They influence physical processes, safety margins, and service continuity.

Modbus was built for trusted, isolated networks. It has no authentication, no authorization, and no encryption. A compromised credential, a contractor laptop, an infected workstation, an unauthorized integration, or a misused automation tool can issue commands that look completely normal at the port level. The security layer has to understand the command, not just the connection.

The Modbus Control Gap

A read function code polls a register. A write function code changes it. To a firewall, both look the same.

Modbus rides over TCP port 502. PacketViper treats write commands as the primary security event.

Firewalls can limit who reaches TCP 502. Monitoring tools can alert after activity occurs. Asset platforms can identify devices. Those layers are useful, but they do not answer the command-level question fast enough:

Should this specific write, from this source, to this register, carrying this value, be allowed right now?

What It Does

Four integrated functions at command level

Monitoring

Full visibility into every Modbus operation: source, target device, function code, unit ID, register, value, time, and action taken.

Detection

Real-time identification of suspicious or policy-violating commands: unauthorized writes, protected register changes, and out-of-range values.

Prevention

Inline blocking of unauthorized write commands at wire speed, scoped to the specific command and device rather than a blunt network shutdown.

Notification

Immediate dashboard updates, alerts, audit records, and operational evidence for every relevant event.

Deployed inline and agentless. No agents on PLCs, RTUs, or controllers, no changes to existing SCADA or control applications. Reads remain untouched; enforcement focuses on policy-violating write commands.

The Controls, Per Device

Policy dimensions, evaluated together

A risky command may be suspicious because of the source, the register, the value, or the timing. These are not separate products – they are policy dimensions inside one Secure Control Layer, set per device.

Read versus write

Allow polling, deny writes, or permit only the functions a device actually needs.

Allowed sources

Only approved systems may speak Modbus to the device. Everything else is unauthorized by definition.

Register and address ranges

Constrain access to the exact blocks a system should touch, turning a fully exposed register map into least-privilege windows.

Value limits

Keep setpoints inside safe operating ranges so a bad command or bad script cannot drive equipment out of tolerance.

Write-rate limits

Detect and stop write floods and register enumeration at the source.

Change windows

Make writes outside a maintenance window stand out immediately.

Alert or block

Observe and surface a violation, or enforce it. Your choice, per device.

Use Cases

A write that should only happen from the right source, at the right time, for the right reason

PLC write protection

Protect PLCs controlling pumps, valves, and dosing from unauthorized writes in water and wastewater environments.

Relay and meter read-only enforcement

Enforce read-only access to relays and meters; stop diagnostics abuse that silently removes a device from service.

Setpoint and register bounding

Bound setpoints and constrain each system to the registers it needs in manufacturing and process environments.

Compromised credential defense

Evaluate source, function code, register, value, and policy before allowing a write. Valid-looking traffic is not automatically trusted.

Vendor and integrator access control

Allow writes from approved sources during approved windows, log every change, and alert or block commands outside policy.

National and multi-site consistency

Apply the same command-level discipline across a national or metropolitan footprint. Configure a device’s policy once at the Federation Manager and it applies identically everywhere that device is seen.

PacketViper does not replace safety instrumented systems, process safety controls, or protocol security upgrades. It provides a compensating inline control layer for Modbus command visibility, policy enforcement, and evidence.

Part of the Secure Control Layer

Not a standalone bolt-on. A command-aware capability inside the platform.

A point solution might parse Modbus traffic. PacketViper places the command inside operational context and enforces business policy at the moment a command becomes action.

  • Asset Intelligence – associates Modbus activity with known industrial devices, roles, and zones
  • Living Topology – shows where protected devices sit and where enforcement points exist
  • Federation – distributes policy and visibility across sites, plants, and regional operations centers
  • AMTD & Deception – deny reconnaissance and create high-confidence triggers near protected assets
  • Threat Reach – shows how far a suspicious source or pattern propagated across nodes
  • Analytics & Compliance – turns commands, advisories, and blocks into reporting and audit evidence

See the Secure Control Layer

Part of OT Protocol Command Control

Rollout

Observe → Detect → Prevent

Step 01 · Observe

Enable monitoring and detection on selected devices. Immediate visibility, no blocking.

Step 02 · Baseline

Review the operations feed, read/write ratios, top senders, and advisories. Normal behavior becomes clear.

Step 03 · Policy build

Define authorized sources, protected registers, value limits, device groups, and change windows.

Step 04 · Advisory tuning

Run would-block reporting before enforcement. Catch policy mistakes safely.

Step 05 · Enforce

Activate prevention on high-value devices and critical processes first.

Step 06 · Expand

Federate policies to additional sites, plants, and device classes.

Market Differentiation

Not “we see traffic.” We understand the command.

Based on public market-facing research, PacketViper appears uniquely differentiated by integrating Modbus command-level monitoring, detection, prevention, notification, and audit evidence directly into a broader inline Secure Control Layer.

Beyond asset visibility

Adds command visibility: who attempted what read or write, against which register, with what value.

Beyond threat detection

Adds command prevention: unauthorized writes can be blocked inline, before the physical process changes.

Beyond firewall / segmentation

Port 502 is not the policy. The command, source, asset, and value are the policy.

Beyond secure remote access

Adds field-device action governance after access has been granted.

Beyond SIEM alerting

Adds pre-impact enforcement and sends cleaner evidence downstream.

Beyond standalone Modbus monitoring

Adds the broader platform: AMTD, deception, federation, Threat Reach, asset intelligence, analytics, and compliance.

FAQ

Modbus Command Protection – common questions

Does PacketViper replace existing SCADA or HMI systems?

No. PacketViper sits inline as a transparent control layer. It protects the command path while allowing existing SCADA, HMI, and control applications to continue operating.

Does it block read (polling) traffic?

No. Read function codes are permitted and logged for context. Enforcement focuses on policy-violating write commands that attempt to change device state.

Can it be deployed gradually?

Yes. Policies can be applied per device, device group, or device class. Start in alert mode, then move high-value devices into block mode.

What if inspection is unavailable?

The design supports fail-open behavior so control traffic continues. This matches the operational reality of industrial environments, where control continuity must not be interrupted by a security failure.

Does it require agents on PLCs or RTUs?

No. PacketViper is agentless and transparent to the control network. Nothing is installed on PLCs, RTUs, or controllers, and there are no IP changes or re-architecting.

What about serial Modbus (RTU) or non-standard implementations?

Best results occur when commands are visible on the wire. Where serial links or non-standard implementations are present, PacketViper still supports trust relationships, source policy, zone enforcement, and broader platform controls, and can recommend the right control placement.

Does this replace zone and conduit segmentation under IEC 62443?

No. Zone and conduit segmentation is valuable. PacketViper provides a compensating inline control layer at the command level, especially where legacy devices, vendor constraints, or operational realities make protocol upgrades or full segmentation difficult or incomplete.

Why is this part of the Secure Control Layer?

Because the feature observes a command, understands its context, decides whether it matches policy, enforces the decision inline, notifies operators, and produces evidence. That is the Secure Control Layer in action.

Continue Exploring

Explore the platform

OT Protocol Command Control

Inspect and enforce industrial commands inline. Modbus, DNP3, Siemens S7, NTCIP, BACnet, and SECS/GEM, governed per device, agentless.

Learn more

NTCIP Traffic Protection

Command-level monitoring, detection, and enforcement for NTCIP-managed traffic signals, message signs, and roadside field devices.

Learn more

SECS/GEM Command Protection

Command-level monitoring, detection, and enforcement for the SECS/GEM traffic that runs semiconductor fab equipment.

Learn more

OT / ICS / SCADA Security

Protocol-native protection for operational technology. No agents, no active scanning, fail-safe operation.

Learn more
Get Started

Protect the commands that control your industrial devices.

Start in Monitor mode for immediate visibility, then enforce on your highest-risk devices. Book a demo and we’ll show command-level control against real Modbus traffic.