How Switch Mirroring Decisions Create Blind Spots in OT Network Monitoring

Your OT sensor is licensed. It's healthy. The dashboard is full of assets, and the alerts are tuned. And the controller that runs your most critical line may still be invisible to it.

Passive platforms learn only from the packets delivered to them. In most plants, those packets arrive through a switch port mirror (SPAN) or a network TAP, placed by someone who had to decide which links mattered. The switch doesn't care about that decision. It forwards frames according to its MAC address table, and a sensor cannot analyze traffic that never crosses a mirrored link.

From the field. At a discrete manufacturing site, I compared our monitoring platform's inventory against the PLC projects and the switch MAC tables. Under a quarter of the assets were missing, which sounds tolerable until you ask why. Part of the answer was a vendor's cellular remote-access path: a working connection into the line that never touched the plant network, so no sensor could have seen it. The sensor wasn't broken. It had simply never been shown that traffic.

The example below is a lab-style scenario with fictional addresses, built from documented switching behavior and common plant-floor designs. Later sections cover redundant topologies, devices hidden behind NAT and gateways, encrypted industrial protocols, and who is allowed to change mirror configuration.

1. How a switch decides what your sensor sees

A switch learns which MAC address lives on which port and forwards each unicast frame only to that port. When two devices hang off the same switch, the frame between them never leaves that switch. A SPAN session copies frames from the source ports or VLANs you define to a destination port. Anything not sourced is not copied.

Most OT monitoring deployments start the same way: the sensor goes in at the distribution layer, near the Level 3 boundary, mirroring the uplinks to each cell or area zone. That position sees north-south traffic well. It sees very little of what happens inside the cell.

Suppose a sensor mirrors only the uplink from a line's access switch:

Conversation	Path	Reaches a sensor on the uplink?
Engineering workstation (Level 3) to line PLC	Crosses the uplink	Yes
Historian collector to line PLC	Crosses the uplink	Yes
HMI to line PLC, same access switch	Switched locally	No
PLC to remote I/O adapters, same access switch	Switched locally	No, unless multicast floods (Section 2)
Laptop plugged into the line cabinet to PLC	Switched locally	No

The last row is the one that matters most. The most consequential activity in a cell, a program download or a forced output from someone standing at the cabinet, is exactly the traffic an uplink mirror cannot see.

The sensor's configuration tells you almost nothing about its coverage. The switch's forwarding path, and where the copy is taken, decides what the sensor will ever receive.

2. A hypothetical blind spot: Packaging Line 4

The lab has two switches. Distribution switch DS-01 sits at the Level 3 boundary. Access switch AS-L4 sits in the Line 4 control cabinet, connected to DS-01 through port Gi1/0/24. The sensor is connected to DS-01 port Gi1/0/48, and a SPAN session copies both directions of Gi1/0/24 to it.

More on Figure 1: The sensor copies only the uplink. Program downloads, HMI writes, and cyclic I/O are switched locally on AS-L4 and never reach it.

The engineering ground truth for Line 4 is 15 assets: one PLC, four remote I/O adapters, one HMI, one Modbus TCP-to-RTU gateway with six serial VFDs behind it, and two controllers inside an OEM filler skid that sits behind 1:1 NAT.

After two weeks of collection, Figure 2 compares the sensor's view with that ground truth (illustrative values, not captured from a live environment). Only the PLC is fully visible, because engineering and historian sessions cross the uplink. Everything else is missed for one of four reasons:

Asset	What the sensor has	Why it misses the rest
HMI 10.30.4.50	IP and MAC only	Learned from ARP broadcasts; its sessions to the PLC stay on AS-L4
Remote I/O adapters .21 to .24	Nothing	IGMP snooping keeps cyclic multicast I/O on AS-L4
Modbus gateway 10.30.4.60	Partial	Seen only when Level 3 polls it
Serial VFDs (unit IDs 1 to 6)	Nothing	Never on Ethernet; at best implied by unit IDs in gateway traffic
Skid controllers	10.30.4.100 and .101	Translated addresses only; the skid network stays behind NAT

The dashboard reports five assets on Line 4. One of fifteen has full protocol visibility. And a laptop plugged into AS-L4 that downloads new logic to the PLC would generate no detection, because none of that traffic reaches DS-01.

More on Figure 2: Graded against engineering ground truth, Line 4 has full protocol visibility on 1 of 15 assets.

A note on the I/O row: if IGMP snooping or the querier is missing, EtherNet/IP multicast I/O may flood every port, including the uplink, and the sensor will see it. That is not good news. It means cyclic control traffic is flooding links it should not touch, which is its own reliability problem.

Step 1: read the mirror configuration

On Cisco IOS-based industrial switches (including Cisco IE and Rockwell Stratix families), the session is visible with:

show monitor session all

Confirm the source ports or VLANs, the direction (both, rx, or tx), and the destination. Then list what is not sourced. Syntax differs on Siemens SCALANCE, Hirschmann, and Moxa platforms, but the question is the same: which conversations physically pass through a sourced port?

Step 2: check the destination port for drops

Mirroring both directions of a 1 Gbps uplink can generate up to 2 Gbps of copies toward a 1 Gbps destination port. The switch drops the excess at the destination port, and the sensor is never told. Cisco's SPAN documentation is explicit that an oversubscribed destination can lose packets, and that a frame can be forwarded normally on the production network yet never appear on the monitoring port. Check the destination port's output drops:

show interfaces Gi1/0/48 | include drops

Compare that with the sensor's own ingest and drop counters. Cyclic I/O at short requested packet intervals produces constant packet rates, so oversubscription in OT is often steady, not bursty.

Step 3: compare against engineering ground truth

The sensor inventory is not ground truth. The controller project's I/O configuration lists every adapter and module with its address. The access switch's MAC address table lists every device that is physically present:

show mac address-table interface Gi1/0/5

Any MAC in AS-L4's table that is missing from the sensor inventory is a confirmed blind spot. Any adapter in the PLC project that is missing from both is a different problem worth a walkdown.

Step 4: run a controlled observation test

In an approved maintenance window, connect an engineering laptop to a known port on AS-L4 and perform a read-only action, such as going online with the controller without making changes. Then check whether the sensor logged the session. If it logged nothing, the line has no detection coverage for engineering activity that starts inside the cell. Coordinate with operations first, keep the test strictly read-only, and do not run it against safety instrumented systems without the owner's explicit approval.

Step 5: correct the coverage design

Option	What it fixes	Cost and risk
Local SPAN on AS-L4 (access ports or the cell VLAN)	Captures intra-cell conversations	Needs a destination port and a path back to the sensor
RSPAN or ERSPAN to a central sensor	Carries cell copies across the network	Adds load to production links; size it, and keep it off control-critical trunks where possible
Passive TAP on the PLC's link	Full-fidelity copy, no switch CPU involved	Insertion needs an outage; confirm fail-open behavior with the vendor
Sensor per cell or area zone	Local visibility without transport	Hardware and licensing cost

Prioritize by consequence, not convenience. The links carrying write-capable protocols to controllers that can hurt people, product, or equipment come first, even if they are the hardest to reach. Whatever you choose, validate it with Steps 1 through 4 before calling the line monitored.

3. Redundancy can quietly take your sensor offline

Plants build redundancy so the process keeps running when a link fails. Ring protocols such as MRP and DLR, parallel networks under PRP, and redundant uplinks all do that job well. None of them consider your sensor.

In a ring, one port is held in a blocking state. When a link breaks, that port opens and traffic takes the other direction around the ring. If your mirror sources the port that used to carry the traffic, the copy stops while the process carries on normally:

More on Figure 3: A single link failure opens the blocked port. Control traffic now bypasses SW-B, and the sensor attached to it receives nothing.

The same pattern appears with PRP. Duplicate frames travel over independent LAN A and LAN B. A sensor on LAN A alone works until LAN A fails, and then it goes blind exactly when something unusual is happening.

Partial capture also degrades analysis. Passive platforms reconstruct sessions to decode industrial protocols. If a sensor sees a Modbus write request but not the response, or sees only one leg of an EtherNet/IP connection, it may misclassify the activity or drop it from protocol analysis.

The practical fixes are modest. Mirror at a point every path converges on, such as the controller's own link, or source the ring ports in both directions on more than one switch. Then test a planned ring break during commissioning and confirm the sensor keeps receiving the same conversations. Alert on a sudden drop in packets from a mirrored source, not only on the sensor's own health status.

4. The devices that sit behind something

Some of the most important assets on a plant floor are hidden by design, and no amount of SPAN tuning on the plant network will reveal them.

More on Figure 4: NAT'd skids, serial segments, and cellular remote access sit outside what any plant-network mirror can copy.

OEM skids behind NAT. Machine builders often ship skids with a fixed internal address scheme and a 1:1 NAT device, so ten identical machines can coexist on one plant network. The sensor sees the translated addresses. The skid's internal controllers, drives, and safety devices, and every conversation between them, stay inside.

Serial and fieldbus segments. Modbus RTU, PROFIBUS, and similar networks reach Ethernet only through gateways. At best the sensor infers devices from unit IDs or gateway mappings when someone polls through the gateway from above. Wireless field networks such as WirelessHART and ISA100 behave the same way behind their gateways.

OEM cellular remote access. A vendor router with an LTE modem, installed for remote support, can carry traffic from the skid straight to the vendor without ever touching the plant network. No sensor anywhere in the facility will see it. In IEC 62443 terms, it is an undocumented conduit.

These require a different method, not a better sensor:

• Ask for the skid's internal network drawings and NAT tables at purchase, and make them a contract deliverable.
• Inventory serial devices from the controller and gateway configurations, not from network traffic.
• Walk the line cabinets and skids looking for cellular antennas and unmanaged switches.
• Where the platform supports it, use carefully scoped active queries through gateways, approved by the asset owner, as a supplement to passive data.

5. Mirror configuration is security configuration

Detection rules get reviewed, tuned, and change-controlled. The SPAN session that feeds them usually does not. It lives in the switch config, owned by whoever maintains the network, and it changes whenever the network changes.

A typical failure looks like this. During a planned outage, a technician replaces AS-L4 and moves the uplink from Gi1/0/24 to Gi1/0/23 on DS-01. The process restarts cleanly. The SPAN session still sources Gi1/0/24, which is now empty. The sensor keeps showing every Line 4 asset it learned before, because inventories retain devices for days or weeks. The dashboard looks normal while live coverage of the line is zero.

My position: treat SPAN sessions, TAPs, and the switch ports that feed sensors as part of the security monitoring control, under the same change control as detection rules. In practice that means three things:

• Add a coverage check to the plant's management of change (MOC) process for any network work touching a monitored zone.
• Baseline packet volume per mirrored source and alert when it drops sharply, independent of sensor health.
• Restrict and log who can modify monitor sessions on industrial switches.

This maps directly to the continuous monitoring requirement in IEC 62443-3-3 (SR 6.2) and the monitoring guidance in NIST SP 800-82 Rev. 3. A control that silently stops observing the system it monitors does not meet either.

Correctly mirrored traffic may still be unreadable

Getting the packets to the sensor is necessary, not sufficient. Industrial protocols are slowly adopting encryption: CIP Security wraps EtherNet/IP in TLS or DTLS, OPC UA supports Sign and SignAndEncrypt modes, and newer vendor engineering protocols increasingly run over TLS.

That is good for integrity. It also means a passive sensor sees endpoints, timing, and volume, but may not see function codes. It can no longer tell a tag read from a program download.

This is a trade-off security teams create themselves, so document it. Record which flows are encrypted, what the sensor can and cannot decode for each, and what compensates. Useful compensating sources include controller-side change and audit logs, syslog from controllers that support it, engineering workstation logs, and monitoring of controller mode or key-switch position.

6. Validate coverage before claiming visibility

I would not accept an OT monitoring deployment on the strength of an asset count or a sensor health page. The deployment should demonstrate that representative conversations with critical controllers reach the sensor and are decoded. These are the sources for that work:

Source	What it tells you
Switch monitor session config	Which ports or VLANs are copied, and in which direction
Destination port counters	Whether mirrored copies are being dropped before the sensor
Switch MAC address tables	Which devices are physically present on each port
Controller project and I/O configuration	Ground truth for controllers, adapters, modules, and drives
Sensor ingest and drop statistics	What the sensor actually received and processed
Controlled read-only test	Whether engineering activity inside the cell is detected
MOC and change records	When the network changed underneath the sensor

Replace the asset count with a coverage measure. For each zone, divide the assets observed with full role and protocol visibility by the assets in engineering ground truth, and weight the result by consequence. Line 4 in this example scores 1 of 15, under 7 percent, while its dashboard showed five healthy assets.

Repeat the validation after any network change in a monitored zone, after a ring failover test, and at least once a year.

More on Figure 5. Coverage validation is a loop, not a commissioning task. Any change under the sensor restarts it.

Conclusion

A passive sensor is only as good as the copy it receives. That copy has to include the right conversations, in both directions, through failover, and in a form the sensor can decode. Miss any one of those and the dashboard stays green while the line goes dark.

So make coverage verification a standing part of design reviews and management of change. Pick a critical controller. List everything that talks to it. Then prove the sensor sees each of those conversations. It's a half-day exercise, and it will find the blind spot before an incident does.

References

• CISA et al. Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators. August 2025.
• NIST. SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security. September 2023.
• ISA. ISA/IEC 62443 Series of Standards, including IEC 62443-3-3, SR 6.2 Continuous monitoring.
• Cisco. Switched Port Analyzer, Management Configuration Guide (Cisco IOS XE 17).
• Cisco. Configure Catalyst Switched Port Analyzer (SPAN): Example.

---