TAP vs SPAN Port in OT Environments: How to Choose Where to Place Sensors

Why the Traffic Capture Point Is a Critical Decision

Any passive monitoring solution for OT networks needs to see traffic — without access to the data flow circulating on the network, there is nothing to analyze. The way this access is obtained is not a secondary technical detail: it affects data completeness, monitoring system reliability, the risk of impact on operational processes, and the overall infrastructure cost.

There are two main methods for providing monitoring sensors with a copy of network traffic: hardware TAPs (Test Access Points) and SPAN ports (Switched Port Analyzer, also called port mirroring). Both serve the same purpose — providing a copy of traffic to the analysis sensor — but they do so with very different technical characteristics and significant practical implications in industrial OT environments.

The choice between the two has no universal answer: it depends on network topology, the age and type of switches present, the criticality of the systems being monitored, and the available budget. Understanding the technical differences is the prerequisite for making an informed choice.

Hardware TAPs: Characteristics and Advantages in OT Environments

A TAP (Test Access Point) is a passive hardware device that physically inserts into the network cable between two devices — typically between a switch and another device — and produces an electrical or optical copy of the signal without modifying it, without introducing latency, and without having an IP address.

The technical characteristics that make TAPs particularly suited to OT environments:

No IP address: a TAP is not an addressable network device. It cannot be reached, scanned, or attacked over the network. It does not appear in any ARP table. It responds to nothing. This matters in an OT environment where the introduction of every new IP address must be justified and where you want the monitoring system to have the smallest possible footprint on the network.

Zero added latency: a TAP introduces no delay in the main traffic flow. The signal passes through the TAP as if the TAP did not exist. For real-time OT systems where PLC response times are measured in milliseconds, even minimal added latency can be problematic.

Guaranteed fail-open: most hardware TAPs are designed to guarantee traffic pass-through even if the device itself fails. If the TAP stops functioning, the network connection it was monitoring remains active. This is the correct behavior in an OT environment: the monitoring system must be completely transparent with respect to operational continuity.

Complete bidirectional visibility: full-duplex TAPs capture traffic separately in both directions of the link, ensuring no packet is lost. Some SPAN implementations have limitations in this regard.

Switch independence: a TAP functions independently of any switch configuration. It does not require access to the switch CLI, does not occupy switch ports, and does not compete with the switch processor for resources.

The main limitation of TAPs is cost and the need for physical intervention: every link to be monitored requires a dedicated TAP, and installing it requires briefly interrupting the connection during positioning (though non-interrupting TAPs exist for fiber optics). In an environment with many links to monitor, the cost can become significant.

SPAN Ports: Operation, Advantages, and Limitations

SPAN ports, or port mirroring, are a software feature of managed switches that copies traffic from one or more ports (or an entire VLAN) to a destination port where the analysis sensor is connected.

The main advantage is immediate: no additional hardware is required and no physical intervention on cabling is needed. If the OT network switches support port mirroring — and most modern managed switches do — a SPAN session can be configured in minutes by accessing the switch CLI.

The limitations, however, are real and in OT environments can be significant:

Switch processor resource consumption: port mirroring is processed by the switch processor, not the switching silicon. On industrial OT switches with limited CPUs, a high-traffic SPAN session can consume resources the switch needs for normal operation, introducing latency or packet loss on production traffic. This is not a theoretical risk — it is a documented cause of performance degradation in high-traffic OT environments.

Packet drops under load: when the traffic to be mirrored exceeds the capacity the switch can dedicate to the SPAN session, packets are discarded from the copy. Original traffic is not affected, but the monitoring sensor receives an incomplete view. In a security analysis, a missing packet can be the difference between detecting an anomaly and not seeing it.

Limitations on legacy switches: many dated industrial switches — still very common in manufacturing SMEs — either do not support port mirroring at all or support it in limited forms (only one active SPAN session, inability to mirror entire VLANs, limitations on the number of source ports).

Dependency on switch configuration: the SPAN session must be maintained in the switch configuration. A switch reboot without saving the configuration, a firmware change, or a technician who does not know about the SPAN session can silently delete it. The sensor stops receiving traffic without any alert being generated — unless there is explicit monitoring of data reception.

How to Position Sensors in Purdue Zones

The choice of capture method must be made together with sensor positioning in the OT network hierarchy. Not all network points have the same informational value for security monitoring.

The highest-value analytical points are the boundaries between zones:

IT-OT boundary (Purdue level 3.5): traffic crossing the interface between the corporate network and the OT network is the most critical to monitor for detecting attacks propagating from IT toward OT, or unauthorized communications toward the outside. This is typically the point with the highest volume of security-relevant traffic. A TAP on the main connection between the IT-OT firewall and the OT network is often the first choice.

Level 2-3 (SCADA, historian, operator stations): traffic between supervision systems and field controllers is rich in information about operational status and behavioral anomalies. A sensor positioned here sees PLC-SCADA communications and can detect unauthorized modifications, anomalous reads, or new devices starting to communicate with SCADA systems.

Level 1 (field controllers): traffic directly on fieldbuses is the most operationally specific. Positioning sensors here allows seeing Modbus, PROFINET, or EtherNet/IP communications at the individual register level. In environments where some lines are considered critical, this level of visibility can be justified.

The practical rule: start at zone boundaries, where traffic is concentrated and visibility has the greatest impact. Expand coverage toward lower levels over time, where security requirements justify it.

Legacy Systems: Specific Considerations

The reality of Italian manufacturing SMEs includes dated industrial switches (earlier generations of Siemens Scalance, Moxa, Phoenix Contact) often without SPAN support or with limited support. This is not a problem to ignore — it is data to be collected during the network infrastructure inventory phase.

For network segments with legacy switches without SPAN:

A hardware TAP is the only option that does not require replacing infrastructure. It can be inserted in the legacy switch's main uplink, capturing all traffic entering and leaving that segment without touching the switch.

Alternatively, if budget does not allow TAPs on every link, it is possible to strategically cover critical links with TAPs and accept partial coverage on other segments, prioritizing based on the criticality of the systems present.

The wrong choice — configuring a SPAN on a switch that does not support it well, or accepting packet drops on a high-traffic link — is worse than declared partial coverage. Undeclared incomplete data creates a false sense of security: you believe you are seeing everything when in reality you are seeing only part of it.

The Practical Recommendation

There is no answer valid for all environments. The choice depends on budget, existing infrastructure, and the criticality of the systems to be monitored.

A pragmatic guideline: use hardware TAPs on critical links (IT-OT boundary, uplinks of segments with the most critical control systems) where data completeness and monitoring stability are non-negotiable. Use SPAN ports on secondary segments where switches support it correctly and where traffic volume is low enough to avoid packet drops.

Before any decision, verify the specifications of switches on the network: SPAN support, maximum number of sessions, bandwidth limitations on the destination port. This network infrastructure inventory is the technical prerequisite for any passive monitoring project.

The MON5 Angle

The TAP vs. SPAN choice only makes sense if downstream there is a sensor capable of exploiting the captured traffic. MON5 works exactly on this logic: out-of-band passive NDR that decodes native OT protocols (Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP) without introducing new risks on the production network.

The DISCOVER phase includes network topology reconstruction and existing infrastructure inventory — exactly the data needed to decide where to position TAPs and where SPAN ports are sufficient. If you want to start from this map, book an OT assessment.