When the Factory Floor Meets the Network: OT/IT Convergence in Manufacturing

By Stu Long, Chief Technology Officer, Orro

“OT/IT convergence” tends to get talked about as a single event: a moment where operational technology and enterprise IT either connect or don’t. In manufacturing, that framing doesn’t match what’s actually happening on the floor. The connection already exists, and has for years. Production telemetry already feeds enterprise analytics platforms. Vendors already log into PLCs for support. Engineering workstations already bridge onto corporate networks for patching and diagnostics. The useful question isn’t whether convergence is happening. It’s which specific paths data is actually taking between the plant floor and the enterprise network, and whether each of those paths is secured on its own terms.

That distinction matters because different paths carry different risk. Treating convergence as one undifferentiated problem, with one undifferentiated fix, is part of why the visibility gap between plant and enterprise persists even in organisations that consider themselves reasonably mature. This article looks at two of the most common paths in a manufacturing environment: production telemetry feeding AI-driven scheduling and predictive maintenance, and remote vendor or engineering access to plant-floor systems. Both need architecture and segmentation decisions specific to what’s actually crossing the line, not a generic convergence policy applied uniformly across the environment.

Path one: production telemetry to AI-driven optimisation

Manufacturing sites are increasingly feeding production line telemetry into systems designed to optimise scheduling, predict maintenance windows and reduce unplanned downtime. That data path runs from PLCs, sensors and historians on the plant floor, through the MES layer, and into cloud-based or enterprise analytics platforms, often with a machine learning model on the receiving end feeding decisions back into production planning.

The pressure on this path is speed and convenience. The commercial case for the data flow is genuine: better scheduling decisions, earlier warning of equipment failure and less unplanned downtime translate directly into production output. That same commercial pressure also creates a tendency to solve the connectivity problem quickly, often by extending existing IT tooling and IT network access patterns onto the OT side rather than treating the telemetry path as its own security domain with its own requirements.

The practical fix isn’t to slow the data down. It’s to apply purpose-built OT visibility to this specific path, rather than repurposed IT monitoring that was never designed to understand industrial protocols or the operational context behind an anomalous reading. Passive network monitoring, purpose-built for OT, can see what’s moving across this path without introducing the risk that comes with actively probing production control systems, and it gives security and operations teams a shared, accurate picture of what normal looks like for that specific telemetry flow. That picture is also what makes the AI-driven scheduling and predictive maintenance model trustworthy in the first place. A model trained on visibility gaps and unlabelled anomalies is only ever as reliable as the data path feeding it.

Path two: remote vendor and engineering access

The second path is less visible day to day, but it carries at least as much concentrated risk: remote access to plant-floor systems, whether that’s a vendor logging into a PLC for support, or an engineer bridging from an engineering workstation into the corporate network to push a configuration change.

This is where the data backs up something most OT and engineering teams already sense anecdotally. Claroty Team82’s research into remote access sprawl, drawn from more than 50,000 remote-access-enabled industrial devices, found that 55 percent of OT environments now carry four or more remote access tools (Claroty Team82, 2024), with a third running six or more. Each additional tool brings its own supply chain, its own patching cadence, and often its own gap in basic controls such as session recording, auditing and multi-factor authentication, because many of these tools were adopted individually, by different vendors or different site teams, without a consolidated view of what remote access actually looks like across the environment as a whole.

For manufacturing specifically, this pattern tends to concentrate around exactly the systems path one relies on: engineering workstations with privileged access to controller logic, and OEM support access to the same PLCs and historians feeding production telemetry. Securing this path on its own terms means centralising and auditing remote access rather than tolerating an accumulation of individually reasonable but collectively unmanaged tools, and applying the same purpose-built OT visibility used for the telemetry path to see what remote sessions are actually doing once they’re inside the environment.

The manufacturing-specific stakes

Generic breach cost figures don’t land the same way on a manufacturing floor as they do on a boardroom slide about data loss. What matters operationally is downtime and production impact, because that’s the currency a plant manager and a CTO both understand in the same terms.

Claroty’s global survey of cyber-physical systems security found that 49 percent of organisations experienced more than 12 hours of operational downtime (Claroty, 2024) following a cyberattack in the past year, with a third reporting a full day or more offline. The same survey found that 45 percent of organisations reported a financial impact of USD $500,000 or more (Claroty, 2024) from cyber incidents affecting cyber-physical systems, with more than a quarter reporting losses of USD $1 million or more. For a manufacturing environment where production output is directly tied to uptime, that isn’t an abstract compliance cost. It’s lost production, missed delivery windows, and, depending on the process, potential safety and quality implications that follow from an uncontrolled shutdown rather than a planned one.

Mining reference point

The same pattern shows up in mining, particularly around remote and unmanned site connectivity. A remote pit or processing site relies on much the same mix of vendor support access and engineering connectivity back to a central operations centre, often across a less densely monitored network than a metropolitan manufacturing plant. The specific systems differ, but the underlying risk pattern, unmanaged remote access accumulating across multiple vendors and tools without centralised visibility, is close to identical. The path-by-path approach set out here applies just as directly there.

What securing the path looks like in practice

None of this requires a wholesale network rebuild before any of it can start. Path-specific security is, by design, more achievable in stages than a comprehensive convergence programme. It starts with segmentation: keeping the OT environment logically separate from the enterprise network, with defined, monitored gateways for the specific data paths that need to cross that boundary, rather than a flat network where anything connected can, in practice, reach anything else. Passive monitoring, rather than active scanning, is the appropriate default for production environments, where a probe that behaves unexpectedly can itself cause disruption. And the tooling applied to each path needs to be purpose-built for OT protocols and OT operational context, not IT tooling extended into the OT environment because it happened to already be available and licensed. A firewall rule written for IT traffic patterns doesn’t know what a normal industrial polling interval looks like, and an IT-focused remote access tool doesn’t understand why a PLC change window matters.

Applied path by path, that becomes a segmentation decision for the telemetry flow into the AI-driven scheduling platform, a consolidated and audited access model for vendor and engineering connections into the plant floor, and OT-native visibility sitting across both, rather than a single blanket security line item that treats every path the same way.

A note on SOCI

This kind of architecture and segmentation work also happens to strengthen the compliance position of organisations in scope of the Security of Critical Infrastructure Act 2018 (SOCI Act), though that isn’t the focus of this article. We’ve covered the governance side of that question in more depth in The Architecture Imperative: What IT/OT Convergence Actually Requires of Technology Leaders and From Best Practice to Obligation: Why OT Asset Discovery Just Got More Urgent. If your organisation falls, or could fall, within SOCI’s scope, confirm your specific obligations with legal counsel rather than relying on general commentary, including this article, to determine applicability.

Closing

Knowing which specific data paths cross between your plant floor and your enterprise network, and whether each one is secured on its own terms, is the practical starting point for any convergence conversation. Orro’s OT/IT Convergence Readiness Playbook works through that path-by-path assessment in more detail, and is available for teams ready to take the next step.