What is passive OT monitoring?

Security monitoring that observes a copy of industrial network traffic without sending anything to the devices being monitored. The sensor receives mirrored traffic from a SPAN port, a network tap or ERSPAN, and derives asset identity, behaviour and vulnerability posture from what the network already carries.

Does passive monitoring affect production?

No. The sensor is not in the traffic path and never transmits to a control device, so it cannot introduce latency, load or unexpected input. That is why an evaluation can run against production traffic without a change window, provided a mirror port is available.

SPAN port or network tap, which should we use?

A tap is more reliable because it copies in hardware and cannot drop frames under switch load, but installing one interrupts the link and therefore needs a change window. A SPAN port requires no hardware and is the usual starting point. For links that genuinely matter, plan a tap into the next outage.

What can passive monitoring not see?

Devices that never communicate, configuration a device only reveals when queried, the payload of encrypted sessions, and anything on a segment with no sensor. Stating these plainly matters, because a monitoring programme that assumes complete coverage will draw confident conclusions from partial data.

How many sensors does a site need?

The usual pattern is one per cell or area zone, so collection boundaries align with segmentation boundaries. Prioritise the conduits between zones over traffic inside them: boundary-crossing traffic is lower volume and considerably more informative, because crossing boundaries is what lateral movement requires.

Is active scanning ever appropriate in OT?

Occasionally, and narrowly. Confirming a firmware version where a vulnerability decision depends on it is a legitimate case. Signal supports opt-in, explicitly scoped active polling for that, and never permits it against a safety controller. It remains an exception requiring justification rather than a default mode.

Passive OT Monitoring and Its Limits

Why active techniques are avoided

Industrial controllers are built for deterministic execution of a control loop, not for handling unexpected input gracefully. Devices have been knocked into fault states by port scans, by malformed protocol queries, and occasionally by nothing more than an unusual volume of well-formed requests.

In an enterprise network that outcome is an inconvenience. In a plant it can stop a line, trip a safety function, or in the worst case create a physical hazard. The asymmetry is what settles the argument: the benefit of an active scan is a more complete database, and the risk is a production incident.

So the discipline is to collect everything from traffic the network is already carrying, and to treat any packet sent towards a control device as an exception requiring specific justification.

Passive is not a limitation the industry tolerates. It is the correct default, and the burden of proof sits with anyone proposing to send a packet to a controller.

How the traffic is obtained

Passive collection depends on getting a copy of the traffic without becoming part of the path. Three mechanisms cover nearly every deployment.

A SPAN or mirror port on a managed switch copies traffic to the sensor in software. It is the most common route because it requires no new hardware, though on a heavily loaded switch mirroring competes with forwarding and frames can be dropped under load.

A network tap sits physically in the link and copies traffic in hardware. It is the more reliable option and the one to choose for a link that matters, at the cost of a brief interruption to install it, which in practice means waiting for a change window.

ERSPAN encapsulates mirrored traffic and forwards it across a routed network, which is what makes remote or dispersed sites viable without a sensor in every cabinet.

SPAN or mirror port: no new hardware, but subject to drops on a loaded switch
Network tap: hardware copy, more reliable, needs a change window to install
ERSPAN: mirrored traffic carried across a routed network for remote sites

Where sensors go

Sensor placement determines what is visible, and no amount of analysis compensates for a blind segment. The usual approach is one sensor per cell or area zone, which aligns collection boundaries with the segmentation boundaries the security model already uses.

Placement should prioritise the conduits between zones over the traffic inside them. East-west traffic within a cell is high volume and mostly routine; the traffic crossing a boundary is lower volume and far more informative, because crossing a boundary is exactly what an attacker moving through the estate has to do.

Sensors run as an appliance or as software on hardware you supply, and each buffers locally so a temporary loss of the link back to the platform does not lose events.

What passive monitoring can establish

More than most people expect, because industrial devices reveal a great deal in ordinary operation. Device identity comes from stack behaviour, TLS fingerprints, vendor prefixes, protocol banners and the identity objects industrial protocols expose routinely. Firmware and program versions appear in engineering traffic. Controller mode transitions are visible as they happen. The genuine topology is derived from observed conversations rather than from a diagram.

Vulnerability posture follows from the fingerprint, matched against the catalogue, which means a controller can be assessed for known vulnerabilities without receiving anything from the platform.

What it cannot establish, stated plainly

A device that never communicates is invisible. A cold spare sitting powered on but idle will not appear until it does something.

Detail that a device only reveals when asked will not be seen. Some configuration state is never present in normal traffic, so passive monitoring reports what the device does rather than everything it holds.

Encrypted traffic limits protocol decoding to metadata. This is a growing constraint as OPC UA and TLS-wrapped links replace cleartext protocols, and it means the fingerprint and behavioural signals carry more of the weight over time.

Anything on a segment without a sensor does not exist as far as the platform is concerned, which is why placement is a design decision rather than an installation detail.

When a scoped active query is justified

There are cases where passive data leaves a gap that genuinely matters, typically confirming a firmware version on a device that has not been engineered recently, where the vulnerability decision depends on the answer.

Signal supports optional active OT polling for that situation, with three constraints. It is opt-in rather than on by default. It is explicitly scoped to named targets rather than a range. And it is never pointed at a safety controller under any configuration.

Treating this as an exception rather than a mode keeps the default safe and puts the decision in front of the people who own the equipment, which is where it belongs.

Passive OT Monitoring: How It Works and Its Limits