A large national manufacturer operating 14 production facilities brought us into an active OT security engagement several months ago. The initial passive discovery scan, running in SPAN mode with no impact to production, produced an asset map their security team hadn't seen before. It also found 11 always-on vendor VPN tunnels, a flat east-west architecture across three of the plants, and a Safety Instrumented System sharing a VLAN with general control traffic. None of that was a surprise to the OT engineers. All of it was a surprise to the CISO.
OT segmentation done with IT logic will break a plant floor. The firewall placement, inspection rules, and change control cadence that work in a corporate data center will trip safety interlocks, cause motion control systems to drop out of sync, and at worst create genuinely unsafe conditions.
Safety Instrumented Systems are certified to behave a specific way under specific conditions. Any network device that inspects, rewrites, or adds latency to SIS traffic can invalidate the certification and cause the safety system to fail in unexpected ways. This is not a compliance nuance: it is a physical safety risk. Firewalls belong outside the SIS network, not in the path of SIS traffic. The manufacturer we're working with had their SIS on a VLAN shared with HMI and general control traffic, a common artifact of how the plant network grew over time. That has to be resolved before any broader segmentation work touches those zones.
The second issue is real-time constraints on control traffic. PROFINET and EtherNet/IP messages between PLCs and motion controllers are often time-sensitive in ways IT traffic isn't. A 50-millisecond inspection delay in a motion control loop can cause axis desynchronization. Most enterprise firewalls aren't designed for those latency requirements. Putting an IT firewall inline on control traffic without testing the specific timing is how you discover this the hard way at 2 AM during a production run.
The segmentation sequence we're designing with the manufacturer follows a deliberate order, starting with the highest-risk, most bounded work first.
SIS isolation, before anything else. The safety system gets its own physically or logically isolated segment, with no shared VLAN, no inspection devices in-path, and boundaries drawn around it rather than through it. This is the prerequisite for everything else. Until the SIS is properly isolated, any other segmentation work carries safety risk that we're not willing to take on. Our Zero Trust architecture advisory practice handles the boundary design work: the SIS-specific constraint shapes the approach for regulated manufacturing environments.
IT-OT boundary through a defined DMZ. The interface between enterprise IT (ERP, analytics, historian replication) and the OT environment runs through a single, well-documented Level 3.5 DMZ. Explicit, logged, rate-limited connections only. This is where vendor remote access terminates, where the historian replicates to the enterprise data lake, where MES talks to ERP. A clean chokepoint with a short list of known flows is the difference between a defensible boundary and one that grows ad hoc integrations until it's no longer auditable. The Zero Trust implementation roadmap guides how we document and enforce this boundary over time.
Protocol-level allow-listing at the OT firewall. Allowing "Modbus TCP port 502" to a PLC permits every Modbus function, including write commands that can alter setpoints. OT firewalls (Palo Alto PA-Series or equivalent OT-aware platforms) support function-level policy: read commands allowed, write commands restricted to specific authenticated sources, diagnostic commands blocked by default. Port-level segmentation is a starting point: protocol-level is the destination. Our cybersecurity practice handles NGFW deployment at IT-OT boundaries with the OT-specific policy configuration this requires.
Vendor access replaced with time-bounded sessions. The 11 always-on vendor tunnels we found in discovery represent the single highest-probability attack path in the environment. Always-on VPN access for PLC vendors, HMI support contractors, and process tuning teams gets replaced with a privileged access platform that provides session-recorded, credential-rotated, time-bounded access terminating in the DMZ. The vendor connects to the DMZ jump host, not into the OT zone itself. Our cybersecurity practice handles the privileged access design as part of the broader OT security engagement.
OT-aware monitoring deployed in passive mode. Once segmentation boundaries are defined, operational visibility into what's crossing them is required. Standard NDR and SIEM tooling without OT-specific parsers will miss most of what matters in a plant network. Platforms that understand OT protocols at the command level (unauthorized PLC writes, unexpected logic changes, anomalous function codes) get deployed in passive baseline mode first, with alerting enabled after the baseline is stable. Our secure networking and NDR practice covers the OT-protocol-aware detection layer.
The passive discovery phase has already produced material changes in the manufacturer's understanding of their environment. Beyond the SIS VLAN finding and the vendor tunnel count, the scan identified 23 devices on the plant network that IT had no record of, including several legacy HMIs running unsupported operating systems. Those devices are now in a remediation queue.
The 11 always-on vendor tunnels have been reduced to 3 pending full PAM platform deployment, with the remaining 3 under active review. The SIS isolation design is finalized and is staged for implementation during the next planned production outage. Our network architecture and automation services team is handling the underlying fabric changes required to enforce the segmentation boundaries at scale across all 14 plants.
Any manufacturer with converging IT and OT networks should run a passive discovery pass before designing segmentation. The asset map you think you have is almost never the asset map you actually have. This applies regardless of industry segment: discrete manufacturing, process industries, food and beverage, pharmaceutical, and any environment where safety-rated control systems share infrastructure with general plant networking.
Where this approach doesn't apply: greenfield facilities designed from the start with IEC 62443 zone-and-conduit architecture in place. Those environments have cleaner boundaries and need ongoing governance rather than initial remediation.
You can use the same vendor platform, but the policy and placement differ significantly. OT firewalls need to understand industrial protocols at the function level, tolerate or route around real-time control traffic, and change policies on a production outage schedule rather than a standard change window. The platform capability can overlap: the operational model cannot.
Route it around the inspection point using a dedicated segment, then apply compensating controls: tight VLAN isolation, physical access controls, and OT monitoring in passive mode. Don't put an IT firewall inline on a time-critical control loop without testing the specific latency against the control system's timing requirements.
Passive discovery first, every time. SPAN or TAP a few key segments, run an OT-aware visibility platform for two to four weeks, and let the traffic map tell you what's actually communicating. Design from that baseline, not from documentation that's probably outdated.