Closing the OT/IT Visibility Gap in Manufacturing Microsegmentation

The security tooling has not kept pace with this shift. Security Operations Centers (SOCs) built around endpoint detection and response, network detection tools, and SIEM correlation rules were designed for Windows and Linux hosts communicating over well-understood protocols. Many of the same tools have little or no visibility into Modbus, DNP3, PROFINET, or EtherNet/IP traffic, and even fewer can distinguish a legitimate firmware push to a PLC from a malicious one. The result is a network where IT-side defenses are relatively mature, but the OT segment sits largely unmonitored, unsegmented, and unhunted. Especially now during the times when we are faced with accelerated AI assisted cyber-attacks; threat actors are not slowing down their focus on OT environments. Even with tools like Dragos who are ICS/OT focused, it cannot stop threats if it does not have visibility into every asset in an OT network.

This gap is not theoretical. Incidents affecting manufacturers in recent years have repeatedly followed the same pattern: initial access through a phished IT credential or an exposed remote access tool, lateral movement across a flat network, and eventual disruption of production systems — sometimes through ransomware that simply happened to encrypt whatever it found, including engineering workstations that controlled physical equipment. The financial and safety consequences of an OT outage are substantially higher than a typical IT outage, which makes this blind spot disproportionately dangerous relative to its size.

Root Causes: Why Manufacturers Can’t See What They Can’t Segment

Three structural issues sit underneath the visibility gap.

1. Flat, Undocumented Networks.
   Many plant-floor networks were built incrementally over 15 to 20 years, often by control system integrators rather than network engineers. Asset inventories are frequently incomplete or entirely absent, and it is common for a facility to discover previously unknown devices, unmanaged switches, or forgotten remote-access modems only after an assessment is More and more organizations have outdated systems and networks that are housing some of their most critical OT assets. This is a clear vulnerability that can easily be exploited even with the most modern security systems in place. Segmentation cannot be designed for assets that are not known to exist.
2. Protocol and Tooling Mismatch.
   OT protocols were designed for determinism and reliability, not authentication or encryption. Standard IT security tools that rely on deep packet inspection of common enterprise protocols frequently misclassify or simply ignore OT traffic, leaving a gap that neither the IT security team nor the OT engineering team is positioned to close alone.
3. Organizational Silos.
   IT security and OT engineering teams typically report through different chains, use different vocabularies, and are measured against different priorities — uptime and safety for OT, confidentiality and compliance for IT. A microsegmentation project that is designed exclusively by one side, without the operating constraints understood by the other, is a common cause of failed or abandoned projects, since a change that disrupts a production line for even a few minutes can carry costs far exceeding a typical IT security How can we, as security professionals, protect what we do not understand? Why is it so common for a change on the firewall of an IT network able to directly affect a manufacturing process that could injure someone or worse? We need to fix this gap of understanding and communication.

The Solution: AI-Assisted Passive Discovery and Adaptive Microsegmentation

Addressing this gap does not require ripping out legacy control systems or halting production for a network redesign. It requires building visibility first, then applying segmentation gradually and adaptively, informed by continuous behavioral analysis rather than a static, one-time policy.

The proposed architecture has four components:

1. Passive Traffic Collection.
   Network taps or switch port mirroring (SPAN) feed a copy of OT network traffic to a dedicated collection point, with zero active probing of control system This avoids the well-documented risk of active scanning tools crashing fragile PLCs, a failure mode that has ended more than one OT security initiative before it started.
2. AI-driven Asset and Behavior Modeling.
   Machine learning models trained on OT protocol structure — rather than generic IT traffic — parse the captured data to build an asset inventory automatically: device types, firmware versions where available, and, most importantly, the normal communication patterns between devices. Because industrial processes are highly repetitive and deterministic compared to IT environments, behavioral baselines converge quickly, often within one to two weeks of continuous monitoring, and anomalies stand out with far less noise than in a comparable IT baseline.
3. Adaptive Policy Generation.
   Once a baseline is established, the system proposes microsegmentation policies grouped around observed process cells (for example, a specific production line or safety instrumented system) rather than generic IP subnets. Policies are staged in a monitor-only mode before enforcement, giving OT engineers the opportunity to validate that legitimate maintenance and vendor-access traffic will not be blocked.
4. Threat-hunting Integration.
   The same behavioral baseline that supports segmentation becomes the foundation for proactive threat Rather than waiting for a signature-based alert, hunters use the AI-generated baseline to search for statistically unusual behavior: a device communicating with a new peer, a protocol function code that has never been observed on that segment, or command sequences consistent with known ICS-targeting techniques catalogued in the MITRE ATT&CK for ICS framework, such as unauthorized modification of controller logic or manipulation of view on an HMI.

Under the Hood: Making It Work in Practice

Translating this architecture into a working deployment involves several technical decisions that determine whether the program succeeds.

Traffic collection should be deployed at the OT network’s core switches and at each identified zone boundary defined by the Purdue Model, giving the monitoring platform visibility into both intra-zone traffic (device to device within a cell) and inter-zone traffic (cell to supervisory systems). Passive collection avoids interference with real-time control loops, which is a non-negotiable requirement in safety-relevant environments.The behavioral models themselves benefit from unsupervised anomaly detection techniques — clustering and sequence modeling approaches suit OT traffic well, since labeled attack data for a specific facility’s process is rarely available. These models should be retrained on a rolling basis to account for legitimate process changes, such as a new product line or an updated PLC program, so that the system does not generate persistent false positives after routine engineering changes.

Policy enforcement is best implemented through a combination of next-generation firewalls at zone boundaries and software-defined segmentation within the IT-adjacent layers, rather than attempting to enforce policy directly on legacy OT switches that may not support modern access control lists. Enforcement should always follow a staged rollout: alert-only, then block-with-override, then full enforcement, with OT engineering sign-off required at each stage.

Finally, the threat-hunting function should be explicitly resourced, not treated as a byproduct of the monitoring tool. Hunt hypotheses should be documented against MITRE ATT&CK for ICS tactics — initial access, execution, persistence, evasion, and impact — with each hypothesis tied to a specific, testable query against the behavioral baseline. This keeps hunting activity structured and repeatable rather than ad hoc, and it produces a growing library of detections that can be handed off to the SOC as standing alerts once validated.

Integrating the Solution into General Use

This approach scales across facilities of different sizes and maturity levels because it does not assume a green-field network. A phased rollout typically begins with a single, well-understood production line as a pilot, allowing the OT and IT teams to build shared trust in the tooling and the process before expanding facility-wide. Vendor-agnostic data formats for the asset inventory and behavioral models allow the same program to extend across multiple sites with different control system vendors, which is common in manufacturers that have grown through acquisition.