Operational technology networks were not designed to be secured with IT security tools. The devices that run industrial control systems, building automation, energy infrastructure, and manufacturing equipment share one defining characteristic: you cannot put an agent on them. They run proprietary firmware, operate on fixed maintenance cycles, and in many environments cannot be patched or rebooted without taking a production process offline.
That constraint eliminates most of the security stack that IT teams take for granted. No EDR. No host-based logging. No vulnerability scanners that touch the device. For security engineers handed responsibility for OT/ICS visibility, the question is not which agent to deploy. It is what passive, non-intrusive telemetry is available from the surrounding infrastructure.
The answer, in most OT environments, is the network. Routers, switches, and firewalls sitting at the boundary between IT and OT segments export NetFlow and IPFIX continuously. That flow telemetry, properly collected, enriched, and delivered to a SIEM, gives security teams the traffic visibility they need without touching a single OT device.
This blog explains how NetFlow Optimizer (NFO) fits into OT/ICS security architecture, what it provides, and where its boundaries are.
Why Standard Security Tools Fail in OT Environments
The Purdue Model, still the dominant architectural reference for OT/ICS network design, separates industrial control systems from enterprise IT networks through a series of zones and a DMZ. Level 0 through Level 2 contain the physical process, PLCs, DCS, and SCADA systems. Level 3 is the manufacturing operations zone. The IT/OT DMZ, added in later implementations of the model and codified in IEC 62443, sits between Level 3 and the enterprise network at Level 4.
Security tools designed for IT environments assume IP reachability, open ports, and cooperative endpoints. OT devices provide none of these. A PLC running a water treatment process, a historian server in a power substation, or an HMI controlling a production line does not accept agent installations. Many run operating systems that have not received patches in years, not from negligence but because the vendor’s support terms or the operational risk of downtime make patching impractical.
Active scanning is equally problematic. Sending probe packets into an OT network can cause unexpected behavior in devices that were never designed to receive unsolicited network traffic. Some industrial protocols respond to unexpected queries by faulting out or entering a safe-stop state. The tools IT security teams use routinely, vulnerability scanners, network mappers, and SNMP walkers sent directly at OT devices, carry real operational risk in industrial environments.
What remains is passive observation. And the richest source of passive observation data in any network is flow telemetry from the infrastructure devices that carry the traffic.
What NetFlow Telemetry Can and Cannot See in OT Networks
NFO collects flow telemetry exported by routers, switches, and firewalls: the infrastructure devices at the IT/OT boundary, within the DMZ, and at the perimeter of OT network segments. This is an important boundary to understand clearly.
NFO collects from infrastructure devices that export NetFlow or IPFIX: routers, switches, and firewalls. It does not collect from OT endpoints directly, and it does not perform packet capture or deep packet inspection of industrial protocols such as Modbus, DNP3, or EtherNet/IP.
What flow telemetry from boundary devices does give you:
- Traffic crossing zone boundaries: every connection between the enterprise network and OT segments passes through a boundary device. Flow records capture source, destination, protocol, port, bytes, and duration for every conversation.
- New or unexpected endpoints: a device that has never communicated outside its segment appearing in flow records is immediately visible. NFO delivers the IP, the destination, the port, and the volume. The SIEM or analyst determines whether it is expected.
- Protocol and port deviations: OT networks are operationally stable. The same devices talk to the same destinations on the same ports, day after day. Deviations in that pattern, a historian server initiating outbound HTTPS to an external IP, or a PLC-adjacent device communicating on an unexpected port, are visible in flow data.
- Volume anomalies: a sudden spike in data leaving an OT segment toward the enterprise network, or toward an external destination, is detectable through flow volume data even without knowing the content of the traffic.
- East-west traffic within visible segments: switches that export flow data (not all do at the OT layer) provide east-west visibility within the segments they serve.
What flow telemetry does not provide:
- Content of industrial protocol conversations: Modbus function codes, DNP3 commands, or EtherNet/IP payloads are not visible in flow records. Packet-level OT protocol inspection requires a dedicated OT security platform with SPAN or TAP access to the OT segment.
- Device inventory from OT endpoints: NFO’s SNMP polling covers network infrastructure devices, not OT endpoints. OT device discovery and inventory require purpose-built OT asset management tools.
- Visibility into airgapped segments with no flow-exporting infrastructure: if the switches serving a given OT segment do not export NetFlow or IPFIX, that segment is not visible to NFO. This is a common constraint at Levels 0-1 of the Purdue model.
Where NFO Fits in the OT Security Architecture
The IT/OT DMZ is the highest-value deployment point. Traffic crossing between enterprise and OT environments passes through these boundary devices, and they almost always run enterprise-grade networking equipment that exports standard NetFlow or IPFIX. Deploying NFO to collect from firewalls, layer 3 switches, and routers at this boundary gives security teams visibility into every cross-zone conversation without any contact with OT endpoints.
NFO enriches that flow data with context that makes it actionable in a SIEM:
| Enrichment | What Raw NetFlow Shows | What NFO Adds |
| User identity | Source IP: 10.4.1.15 | User: ops-engineer@company.com (resolved from AD/Entra ID) |
| Threat intelligence | Destination IP: 185.220.101.1 | Threat score: malicious / Category: known C2 infrastructure |
| Application context | Port: 502 | Application: Modbus (via NFO application catalog) |
| Bidirectional flow | Separate ingress/egress records | Single stitched record with full conversation context |
That enriched, CIM-compliant telemetry lands in Splunk ES, Sentinel, Exabeam, or any other downstream SIEM where security teams have built detection logic. The detection, alerting, and investigation happen in the SIEM. NFO delivers the data layer those workflows depend on.
Air-Gap and Zero-Egress Deployment
OT environments in critical infrastructure, defense, and regulated industries often prohibit data leaving the network perimeter entirely. NFO is software-only and deploys entirely on-premises, with zero data egress. User identity resolution runs against on-premises Active Directory or Entra ID. Custom application catalogs are maintained locally. Threat intelligence feeds and GeoIP databases are updated from external sources on a configured schedule, with NFO caching that data on-premises so enrichment runs locally against the cached copy at processing time.
This matters in OT environments where even a management-plane connection to a cloud service is a compliance concern. NFO has been in production in air-gapped federal and DoD environments since 2016. The same architecture that satisfies those requirements deploys directly into air-gapped industrial control system networks without modification.
For organizations pursuing CMMC compliance or operating under FISMA frameworks, NFO supports evidence collection for network flow logging requirements without introducing any external data dependencies. As covered in The Unsung Hero of CMMC Compliance and OMB M-21-31 and Network Flow Logging, network flow telemetry is a specific evidence requirement in both frameworks, and NFO provides the collection, enrichment, and delivery pipeline to meet it.
The Practical Starting Point
Most organizations adding OT network visibility do not start with a full OT security platform deployment. They start with what they have: network infrastructure at the IT/OT boundary that already exports flow data and a SIEM that security operations already uses. NFO collects that existing flow data, enriches it, and delivers it to the SIEM in a format that works with existing detection content.
That is a meaningful improvement in visibility without touching a single OT device, without deploying agents, without adding sensors to the OT network, and without requiring a separate OT-specific platform or console for the security operations team to manage.
For environments with stricter requirements and budget for dedicated OT tooling, NFO provides the network-layer data foundation that OT security platforms do not cover: multi-vendor flow telemetry from the broader infrastructure, enriched and delivered to the SIEM, covering the enterprise and cloud-connected segments that OT-focused tools are not designed to address.
The Bottom Line
OT/ICS security starts with accepting the constraint: you cannot put agents on these devices. What you can do is collect, enrich, and deliver flow telemetry from the infrastructure that surrounds them. NFO makes that telemetry actionable, without touching OT endpoints, without cloud egress, and without adding a separate console to the security operations workflow.
The network boundary is visible. The conversations crossing it are recorded. The enrichment that makes those records useful is what NFO provides.
Ready to add network visibility to your OT/ICS security architecture? Start a free 60-day trial of NetFlow Optimizer or schedule a technical demo with a NetFlow Logic engineer.
Start Free Trial | Schedule a Demo | Government Solution Brief | NFO Documentation