Deploying an intrusion detection system on a factory OT network starts with a question, not a product: which equipment communications must be visible, from which observation point, and who will act on a finding? A running PLC and HMI do not by themselves reveal an unexpected maintenance laptop, a changed remote access route, or a new device on a cell switch. This guide walks through a practical deployment for a Thai factory without treating the production network as a laboratory.
Define the OT intrusion detection objective
The assets include PLCs, HMIs, SCADA servers, industrial switches, engineering workstations, and gateways. The business objective is to identify unexplained changes before they affect safety, availability, quality, or lot traceability. NIST SP 800-82 Revision 3 addresses OT security with its particular performance, reliability, and safety requirements. As of 27 October 2026, Revision 3 is final; Revision 4 is an initial public draft, not a final replacement.
An alert is a prompt to investigate, not proof of an attack. An engineering workstation connecting to a PLC at night may be authorized maintenance. Check the work order, operator log, recipe change, and asset owner before assigning severity. Detection succeeds when people can explain important differences in context, not when a dashboard produces more red icons.
Passive monitoring is not automatic protection
The design here copies packets from a switch mirror port or a network TAP to a sensor. A passive monitoring interface does not normally sit in the control path or block packets. Yet a switch configuration change, an inserted TAP, and a sensor management connection are still engineering changes. Review them for production impact. Active discovery and automatic isolation are different functions and require separate authorization and tests. A sensor alone cannot replace segmentation, access control, backup, or a safe recovery procedure.
Define acceptance in terms of traffic and decisions. To observe PLC program transfers, the capture point must see engineering workstation to PLC communications. To observe IT to OT movement, it must see the boundary. To discover a laptop attached inside a cell, monitoring only the core may be insufficient. Record what each point cannot see.
Survey assets and actual communication before selecting a sensor
Walk down the network diagram with maintenance, production, and IT. Record switches, VLANs, wireless gateways, remote maintenance paths, time sources, and temporary ports. For each asset include location, owner, IP/MAC, role, firmware, support contract, permissible outage window, and escalation contact. An IP list without operational ownership cannot tell an analyst whether an alert threatens a bottleneck line.
Build a flow register with source, destination, direction, protocol, port, operational purpose, normal time window, and approving owner. Separate PLC to HMI, PLC to SCADA, engineering workstation to PLC, production to MES, historian, IT/OT boundary, and external support paths. Sample production, changeover, shutdown, and maintenance states. A flow absent on one afternoon may be normal during a night batch.
Our industrial OT firewall selection guide discusses approved boundary flows; the industrial Ethernet switch guide addresses field ports and resilience. An intrusion detection deployment checks whether observed traffic agrees with those designs. Firewall logs cannot automatically reveal east-west traffic that never crosses the firewall.
Prioritize by physical and production consequences
Rank cells by safety exposure, knock-on downtime, alternative production capacity, quality and traceability dependence, external connectivity, and unsupported equipment. A vulnerability score alone does not represent the impact of a utilities PLC compared with a standalone test fixture. The first pilot should cover an important but manageable cell and one boundary with a different visibility objective.
Choose SPAN, RSPAN, ERSPAN, or TAP against the traffic objective
Microsoft documents local SPAN, RSPAN, TAP, ERSPAN, and virtual-switch mirroring as supported methods for Defender for IoT OT sensors. That statement describes that product, not every sensor or switch. Confirm mirroring functions, Layer 2 data, bandwidth, tags, tunnel handling, and supported protocols for the equipment actually being purchased.
Local SPAN
SPAN copies selected port or VLAN traffic to another port on the same switch. It may be a low-disruption first observation point. But switch load and mirror configuration can cause missing copies or different packet timing. Validate peak mirror volume, both directions, VLAN tag retention, and the switch management impact. Broadcast or multicast frames can appear multiple times if too many send and receive ports are mirrored. Microsoft’s product guidance recommends RX-only mirroring for such traffic in its configuration; verify applicability with the switch and chosen sensor.
RSPAN and ERSPAN
RSPAN transports mirrored traffic over a dedicated VLAN; ERSPAN uses encapsulation to carry it to a remote sensor. Both can collect distributed sources, but their transport links may lose packets or consume production bandwidth. Test whether the product reconstructs the Layer 2 and industrial protocol context needed for detection. Do not assume a WAN can carry full factory packet copies without capacity, availability, and information-handling review.
TAP
A TAP duplicates traffic on the link where it is inserted. Microsoft recommends TAPs especially for forensic monitoring with its product, noting that a TAP can carry frames a switch would drop and is not dependent on switch mirror processing. A TAP still requires a physical change to the link. Plan the outage, copper or fiber medium, speed, power, bypass/failure behavior, redundant path, and rollback with OT owners. Traffic on other links remains invisible.
| Method | Benefit | Acceptance check |
|---|---|---|
| Local SPAN | Small physical change | Loss at peak, port capacity, tags |
| RSPAN / ERSPAN | Distributed capture points | Transport load, loss, parsing |
| TAP | Well-defined critical link capture | Insertion outage, redundancy, failure mode |
No method wins in every plant. Compare both captured coverage and the operational risk of installation and maintenance.
Place sensors by mapping blind spots
Switching location, VLANs, NAT, wireless segments, redundancy rings, and machine-internal networks determine visibility. A core sensor may see server-bound traffic but miss conversations between a PLC and HMI on the same access switch. A cell sensor may miss external authentication and the IT/OT boundary. Mark the observed source-destination pairs and blind segments on the same drawing.
Microsoft’s setup guide recommends reviewing diagrams, the device count, relevant VLANs and industrial protocols, then validating Layer 2 and OT traffic at the candidate location before installation. Its example uses Wireshark to check whether expected protocols are actually present. Apply the principle with approved capture handling and the plant’s data policy.
Cisco’s current Cyber Vision sensor documentation says that its sensors analyze mirrored industrial traffic with deep packet inspection and send identified assets, flows, and security events to a Center. The same document specifies that these sensors inspect TCP and UDP traffic and also describes optional Active Discovery. This is product-scoped information. Confirm the exact release, supported protocols, parser settings, and whether any active probe is enabled. Active probing is a separate production test, not passive observation.
Encrypted VPN or TLS traffic may reveal peers, time, and volume without revealing commands. Ethernet monitoring may miss serial buses, proprietary field networks, or PLC logic state. Ask bidders to list the specific flows they cannot interpret, rather than accepting a general “OT protocol support” label.
Six acceptance tests for a factory pilot
Keep the first pilot passive. Approve the switch or cable change, outage window, rollback, and data retention before installation. Test with authorized simulated events, not uncontrolled commands sent to a production PLC.
- Coverage: Which registered flows, directions, and protocols appear? Explain every important missing flow.
- Asset accuracy: Do PLCs, HMIs, maintenance laptops, and gateways match plant ownership and location? Can classifications be corrected?
- Change detection: Can an approved test show a new device, an out-of-window maintenance connection, and a changed destination?
- Capture health: Check mirror loss, sensor capacity, time synchronization, and alert delay during peak operation. Set thresholds from site requirements.
- Operations: Who triages an alert, who calls OT at night, and how are authorized changes distinguished from unexplained changes?
- Safety and recovery: What happens to control traffic if the sensor, mirror port, TAP, or aggregation switch fails?
Avoid an unsupported universal “99% detection” claim. Define plant-specific measures: flow coverage, critical-asset classification accuracy, alerts requiring human review per week, and first response time. The pilot’s purpose is to expose blind spots as well as demonstrate detections.
Convert an alert into a production decision
Attach line, asset owner, current production, maintenance schedule, recent change record, peer device, and evidence to the case. The first analyst checks for a legitimate explanation, rather than declaring an intrusion. If none exists, involve the OT and production owners before isolation or shutdown. A cybersecurity team should not disconnect a running PLC on its own authority.
MITRE ATT&CK has deprecated the former Network Traffic data source DS0029. Its current Network Traffic Flow component (DC0078) covers flow details such as endpoints, protocol, time and volume; Network Traffic Content (DC0085) covers packet content. Neither classification proves that a product detects a particular attack. Test detections against observable plant data, defined scenarios and the sensor’s actual parsing capability.
Compare the complete deployment cost and supplier responsibilities
Request separate line items for sensor licensing, switch configuration, TAPs, fiber, rack and power, storage, SIEM integration, time synchronization, tuning, training, support, and field work during upgrades. Device count alone does not size the system. Peak traffic and retention policy matter, and full-packet storage has a different capacity profile from metadata storage. This article gives no market price: site wiring and outage constraints must be measured before suppliers can quote against the same scope.
CISA’s ICS monitoring technology considerations ask buyers to assess whether the monitoring technology itself could become a path into ICS, and discuss centralized log integration, MFA, and minimizing unnecessary exposed services. These are US critical-infrastructure considerations, not a statement of Thai legal obligations. Use them as procurement questions: separate management access, account roles, update process, vendor remote support, storage location, and deletion at contract end.
Specify the exact PLC models, protocol modes, extensions, encryption, and firmware in the RFP. Require a live pilot to distinguish reads, writes, and configuration changes where that distinction matters. An unparsed flow must remain visible as an unknown, not silently count as safe.
Operate detection as part of change management
Initial visibility often reveals long-standing exceptions. Confirm each flow’s owner and purpose before marking it authorized; do not block all unknown traffic at once. Update the asset and flow registers when machines, switches, MES links, or maintenance vendors change. Share planned change times and expected flows with the monitoring team so the before-and-after difference can be reviewed.
Define responsibility for mirror configuration, production impact, rule tuning, and shutdown approval. A supplier contract to monitor alerts does not give the supplier authority to stop equipment. Write the path from detection through triage, escalation, containment, recovery, and review with primary and alternate contacts. Night and weekend coverage must be real, not a single personal phone number.
Separate retention of flow metadata, alerts, and raw packets. Raw traffic can contain process configuration or production know-how. Set scope, access, retention, overseas sharing, extraction, and deletion for each data type. Evaluate relevant law and customer contracts against the actual storage and transfer path. In a Thai plant, local IT, Japan headquarters, maintenance, and OEMs may each own part of the network; identify who may approve changes and who can confirm a legitimate service visit before the pilot.
Review alerts as confirmed security events, legitimate but unannounced changes, product misclassification, or missing observation data. Do not suppress all four as “false positives.” Time-limit exceptions by asset, purpose, and owner. Monitor the monitor: a switch port or VLAN change can silently remove visibility. After deployment, Microsoft recommends checking device counts and classes, OT protocols, and MAC addresses in its product. Sensor health should itself raise an alert when expected traffic disappears.
A 30/60/90-day example
In the first 30 days, survey assets and flows, choose a priority line, identify stoppage conditions, and approve observation objectives. The deliverables are a signed flow map, known blind spots, and acceptance tests, not a preferred product. Over the next 30 days, pilot the capture points across relevant operating states and record coverage, capture quality, alert usefulness, and response. Move a sensor if necessary. In the final 30 days, finalize contact roles, maintenance change procedures, health checks, training, and criteria for rollout. This is a planning example, not a deadline that overrides equipment safety.
When rolling out to a similar line, repeat the capture checks. Similar machines can have different switch layouts or support contracts. Accept a new line only when the asset register, observation scope, escalation contact, and recovery procedure have been handed over. When a sensor is upgraded or fails, record the visibility gap and compare representative flows before and after restoration.
Frequently asked questions on OT network intrusion detection deployment
Can we deploy without affecting a running PLC?
A passive monitoring interface normally does not query the PLC. But SPAN configuration and TAP insertion are network changes; optional active discovery can send traffic. Review each separately, define an outage window and rollback, and test before production handover.
How is an OT IDS different from an IT IDS?
An OT product may recognize industrial protocols, PLC/HMI roles, and operational flow changes. The label alone does not guarantee parsing of the plant’s models or proprietary extensions. IT flow tools and firewall logs remain useful at boundaries. Define required detections per flow and verify them with real data.
Should we use SPAN or TAP?
SPAN can be a practical first trial when cable interruption must be avoided. Compare a TAP on a critical link if mirror loss or timing matters. A TAP requires link insertion. Neither method sees traffic outside its capture point. Test under peak production and maintenance conditions.
What changes OT intrusion detection cost?
Capture point count, peak traffic, retention, available SPAN capacity, TAP and fiber work, SIEM integration, night coverage, and support scope all matter. Request comparable proposals against a defined flow and coverage requirement.
Is intrusion detection a complete OT security program?
No. Combine it with IT/OT segmentation, access control, backups, change management, incident response, and safe restoration. An alert is useful only when production and maintenance can act on it.
Conclusion
An OT intrusion detection deployment is a visibility and response design. Start with equipment and communication mapping, select capture points against operational risk, and document both observed and unobserved traffic in the pilot. Keep the system current as equipment and routes change. If you are still comparing architectures or checking whether an existing switch can support a pilot, contact TOMAS TECH to discuss the first practical observation point in your Thai factory.
Primary references
- NIST SP 800-82 Rev.3, final; Revision 4 was an initial public draft as of 27 October 2026.
- CISA, ICS Monitoring Technology Considerations.
- Microsoft, Choose a traffic mirroring method.
- Microsoft, Set up traffic mirroring.
- Cisco, Cyber Vision sensor overview.
- MITRE ATT&CK, Network Traffic DS0029 (deprecation warning shown on the page).
- MITRE ATT&CK, Network Traffic Flow DC0078 and Network Traffic Content DC0085.
