Any intrusion-detection sensor watching an OT network first has to be handed a copy of the traffic, because a monitoring sensor never sits in the control path where a fault could stop production. There are two ways to make that copy: tell a managed switch to mirror traffic out a spare port, called a SPAN or mirror port, or splice a small passive device into the cable itself, called a network TAP. Both feed the same sensor, but they differ in how faithfully they copy every frame, in what happens when traffic gets heavy, and in whether they can fail in a way that touches the live network. This page explains how each works, why a TAP avoids the dropped frames and oversubscription that quietly plague SPAN ports, and where each belongs on a Purdue-model network.
SPAN Port vs Network TAP in one line: A SPAN port, also called a mirror port, is a feature of a managed switch that copies traffic from one or more ports out to a spare monitoring port, where an IDS sensor can watch it. A network TAP is a small passive hardware device spliced inline into a physical link that copies every frame out to a monitor port without the switch's involvement. A SPAN port is cheap and needs no new cabling but can silently drop frames under load and deprioritizes mirrored traffic, while a TAP copies traffic faithfully and cannot drop frames it was designed to carry, at the cost of a physical install and a dedicated device.
A SPAN port lives inside a managed switch. You configure the switch to designate one or more source ports, or an entire VLAN, as traffic to be mirrored, and a spare port as the destination where a copy of that traffic is sent. Plug an IDS sensor into the destination port and it sees a copy of everything crossing the sources, without the endpoints ever knowing they are being watched. Nothing new is spliced into the network, no cables are cut, and the change is entirely in switch configuration, which is why SPAN is the fast, no-cost first choice when the switch already supports it.
A network TAP is a separate piece of hardware inserted into a physical link. You break the cable between two devices, run both ends through the TAP, and the TAP passes the traffic straight through between them while sending a copy out one or more dedicated monitor ports. A passive optical TAP simply splits the light with no powered electronics in the through path, so even if the TAP loses power the live link keeps running. A powered copper TAP is built with the same fail-to-wire philosophy, so a power loss should not break the monitored link. The sensor plugs into the monitor port and receives a faithful copy of every frame on that link.
The key structural difference is where the copy is made. A SPAN port makes the copy inside a busy switch that is also doing its real job of forwarding production traffic, so the mirror is a secondary duty the switch performs when it has spare capacity. A TAP makes the copy in dedicated hardware whose only job is to duplicate the link, so copying is never in competition with anything else. That single distinction is the root of almost every practical difference in fidelity and load behavior between the two approaches.
The weakness of a SPAN port shows up under load. A switch treats mirrored traffic as lower priority than the production traffic it must forward, so when the switch backplane or the destination port gets busy, the switch will quietly drop mirrored copies to protect real forwarding. The sensor never sees those dropped frames and, worse, never knows they went missing, so a detection engine can silently lose visibility exactly when traffic spikes, which is often the moment an attack or a fault is generating the most activity. This is why a SPAN feed can look healthy on a quiet network and then develop blind spots under stress.
Oversubscription makes it worse. A common mistake is mirroring several ports, or a whole VLAN, out to a single destination port of the same speed. If the combined source traffic exceeds what the one destination port can carry, the excess simply has nowhere to go and is discarded. Mirroring the full-duplex traffic of a link is especially prone to this, because a link carrying near-line-rate in both directions at once produces more mirrored data than a single same-speed port can output. A TAP sidesteps the whole problem because it is engineered to carry the exact traffic of the link it copies, and a full-duplex TAP presents each direction so the sensor receives both without the two streams contending for one output.
There is also a fidelity difference beyond drops. A SPAN port can reorder frames, alter timing, and normally does not forward physical-layer errors, runts, or malformed frames, because the switch drops those before they would ever reach the mirror. A TAP, sitting at the physical layer, passes traffic through more faithfully and can present error frames and corrupt packets that a switch would have discarded. For an intrusion-detection sensor that reasons about exact packet content and timing, and for forensic capture where you want to see even the malformed traffic, a TAP gives the trustworthy, complete copy that a mirror cannot always guarantee.
Placement follows the value and the risk of the link. The highest-value monitoring point in most plants is the boundary between the control network and the plant or enterprise levels, roughly Purdue Level 3 up to the DMZ and Level 3.5, where traffic crosses between IT and OT and where an intruder pivoting inward has to pass. A permanent, high-fidelity TAP is well justified on that boundary link, because losing visibility there under load is exactly when it matters most, and the link is important enough to warrant the dedicated hardware and the careful install. Below that, on Level 2 supervisory networks that aggregate several cells, a TAP or a well-provisioned SPAN both work depending on how much traffic those switches carry.
Deeper in the process, at Level 1 and the cell networks where PLCs talk to their I/O, a SPAN port on the cell switch is often the pragmatic choice. Traffic volumes there are usually modest and deterministic, the switches are already in place, and cutting into a live control link to install a TAP carries its own risk that a mirror configuration avoids entirely. The engineering trade is straightforward: use a SPAN port where the traffic is light enough that drops are unlikely and where an inline install would be more disruptive than it is worth, and reserve TAPs for the busy, high-consequence links where you cannot tolerate silent blind spots.
Both methods share the property that makes them safe for OT in the first place, which is that the sensor receives only a copy and sends nothing back into the network. That receive-only posture is what lets a security sensor watch fragile control traffic without any chance of a probe or an injected packet disturbing a PLC. When the copied feed is forwarded on to a broader monitoring platform, including a cloud SCADA or security platform such as Merobix that correlates events across many sites, the fidelity of that original copy sets the ceiling on everything downstream. A TAP that never drops a frame gives the platform a complete record to reason over, while a SPAN port that silently sheds frames under load can leave the whole chain blind to the very moment it was built to catch.
Yes, and this is its main weakness for security monitoring. A switch treats mirrored traffic as lower priority than the production traffic it must forward, so under load it will quietly discard mirrored copies to protect real forwarding. The sensor never sees those frames and gets no indication they were lost, which means a SPAN feed can develop blind spots exactly when a traffic spike, an attack, or a fault is generating the most activity.
A properly chosen TAP is designed to be safe, but the physical install is the risk. A passive optical TAP has no powered electronics in the through path, so it keeps passing traffic even if it loses power, and quality copper TAPs are built to fail to wire so a power loss should not break the monitored link. The care needed is in cutting into a live cable to insert it, which is why TAPs are usually planned for a maintenance window and reserved for links important enough to justify the work.
No, and that is the point of both. A SPAN port and a network TAP each hand the sensor a copy of the traffic while keeping the sensor out of the control path, so the monitoring device receives frames but has no ability to inject anything back onto the production link. This receive-only posture is what makes passive monitoring safe for fragile control systems, because there is no chance a security sensor sends a probe or a malformed packet that could disturb a PLC.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.