BLOG

Passive OT IDS: What It Detects, What It Misses, and Where the Sensors Go

Passive intrusion detection is the default first monitoring control in operational technology, and for good reason. It does not scan, probe or inject traffic, so it cannot knock over a PLC that has not been rebooted since 2014. That safety is the whole argument for it, and it is a strong one.

What gets undersold is the limits. A passive sensor sees exactly the traffic that crosses the link it is attached to, and nothing else. Teams that deploy one and then treat the plant as monitored have bought visibility into part of their network and confidence about all of it, which is a worse position than knowing you are blind. This post covers what passive detection does well, where it genuinely cannot help, and how to place sensors so the gaps are deliberate rather than accidental. For the surrounding program, see building an OT monitoring program.

What passive actually means

A passive sensor receives a copy of network traffic and analyzes it out of band, never originating a packet onto the monitored network. That distinguishes it from active discovery, which queries devices directly and is banned outright on Level 1 and 2 equipment in most plants. Our guide to non-disruptive OT asset discovery covers that trade-off.

Being out of band, a passive IDS cannot block anything. It detects and alerts, which is usually the right choice in OT: an inline device that blocks the wrong packet can stop a process, and a false positive in a plant costs production rather than a help desk ticket.

What it detects reliably

Assets you did not know you had. Often the first and largest win. A passive sensor builds an inventory from observed traffic and routinely finds devices absent from every drawing.
New or changed communication patterns. An engineering workstation that suddenly talks to a controller it has never addressed before. This is the single most valuable detection class in OT.
Protocol anomalies and malformed traffic. Function codes outside the normal set, unexpected write operations, malformed requests.
Known threat signatures. Where the platform carries industrial signature coverage and the subscription is current.
Cleartext credentials and insecure services. Abundant in OT and useful evidence for a hardening program.
Lateral movement across the monitored segments. Which is precisely what internal monitoring mandates are aimed at.

What it cannot see, and no configuration fixes

Traffic that never crosses a monitored link. That includes serial and fieldbus communication below the Ethernet layer, point-to-point links without a sensor, wireless paths, and any zone where you did not install one. It also includes activity that produces no network traffic at all: a configuration change made at the console, firmware loaded from a USB stick at the panel, or a local logic edit by someone standing in front of the cabinet. Encrypted traffic without an inspection path is a growing blind spot as newer OT protocols add transport security. None of these are product weaknesses. They are consequences of monitoring the network rather than the device.

SPAN or TAP

How you deliver traffic to the sensor matters more than most procurement conversations allow for.

	SPAN or mirror port	Network TAP
What it is	A switch feature that copies traffic to a monitor port.	Passive hardware inserted into the link that copies traffic to a monitor port.
Install	Configuration change, no cabling work, can be done remotely.	Requires breaking the link to install, so it needs an outage window.
Fidelity	Can drop packets when the switch is under load, because mirroring is a lower priority than forwarding.	Full fidelity. It does not drop traffic under load.
Failure behavior	A switch problem affects both production and monitoring.	A passive TAP keeps the production link up if the monitoring side fails.
Use it when	You need coverage now, or the segment is low utilization.	The segment is critical or busy and you have an outage window.

A pragmatic sequence: start with SPAN to get visibility quickly, then convert critical conduits to TAPs at the next outage. Waiting for a turnaround to start monitoring at all is how programs stall for a year.

Where the sensors go

Sensor placement follows your zone structure, not your rack space. Working from the Purdue model and the IEC 62443 conduit concept, the priority order we use:

1. The IT and OT boundary at Level 3 or 3.5. Highest value per sensor. Everything entering or leaving the control environment crosses here.
2. Each major conduit between zones. This is what internal monitoring expectations are really asking for. East-west traffic between control zones, not just north-south at the perimeter.
3. The control network at Level 2. Where HMI, engineering workstation and controller traffic lives, and where unauthorized logic changes would appear.
4. Remote and vendor access paths. Including jump hosts. Disproportionately valuable because this is a common initial access route.
5. Safety system conduits, with care. A TAP on a safety instrumented system path needs safety review, not just a network change request.

What we do not recommend is one perimeter sensor and a claim of coverage. That design detects arrival and misses everything after it, which is the exact failure internal monitoring requirements exist to close. Our OT/IT segmentation audit guide covers mapping conduits first.

Baseline before you alert

A passive IDS in a plant it has not learned generates noise, and noise trains people to ignore alerts. Run it in observation mode across a full operating cycle, including startup, shutdown and maintenance, before tuning detections. Many plants have traffic that appears only during a turnaround, and a two week baseline taken in steady state will flag all of it as anomalous when it finally shows up.

Why Choose Arista Cyber

We deploy and tune passive monitoring on running plants: sensor installs planned around outage windows, safety review on anything touching a protective system, and a baseline before alerts go live. Our consultants hold functional safety credentials alongside OT security certification. See our OT intrusion detection systems and our case studies.

Next Steps

Map your conduits before you buy a sensor. The question is not which IDS, it is how many monitoring points your zone structure requires and which of them you can reach without an outage. That answer usually changes the budget in both directions.

Common Questions

Can a passive IDS stop an attack?

No. It detects and alerts. Blocking requires an inline device, which carries the risk of stopping production on a false positive. In OT, detection is normally the right trade, with enforcement handled at the boundary by a firewall or by one-way hardware.

Will a passive sensor affect my control network?

A correctly installed passive sensor originates no traffic, so it does not. The risk is in installation: inserting a TAP requires breaking the link, which needs an outage window and change control.

Do I need a sensor in every zone?

Ideally one per major conduit rather than per zone. A single perimeter sensor detects arrival and misses lateral movement, which is the gap internal monitoring requirements are written to close.

Does a passive IDS see serial or fieldbus traffic?

Not unless that traffic is carried over the monitored Ethernet segment. Native serial, fieldbus and point-to-point links below the monitored layer are invisible to it.

How long should the baseline period be?

Long enough to cover a full operating cycle including startup, shutdown and maintenance. Steady-state baselines of a week or two will misread turnaround traffic as anomalous months later.

How many of your conduits are actually monitored?

Arista Cyber maps your zone and conduit structure, specifies sensor placement against it, and deploys passive OT intrusion detection with a baseline period that covers a real operating cycle.

Discuss OT intrusion detection