Convergence done right is not a story about IT winning or OT losing.

Remote operations cannot afford the luxury of parallel infrastructures, disconnected teams, or unmanaged shared services. At a remote or distributed site, one expensive WAN link carries both business traffic and operational data. One lean site team supports both IT and OT systems. One outage affects everything at once.

IT and OT have to work together in these environments whether the org chart reflects it or not. The question is whether that working relationship is designed or accidental. This article is about designing it.

Why Remote Operations Force the Convergence Question

At a large, well-staffed headquarters facility, IT and OT can maintain meaningful separation — separate networks, separate teams, separate tooling. Remote and distributed sites often cannot afford that model.

The pressures are structural. One expensive satellite or terrestrial link may carry historian traffic, enterprise email, SCADA telemetry, and patch downloads simultaneously. Staffing is lean, which means the same person who troubleshoots the business network may also support the control network. Building and maintaining duplicate infrastructure is unaffordable. And unmanaged shared infrastructure — links that carry everything without priority, segmentation, or defined ownership — is indefensible.

The air gap story falls apart here too. When we look at how remote sites actually operate, we consistently find that IT and OT are already touching — through shared links, shared identity systems, historian connections, and vendor access paths that cross both domains.

Read more: Exposing Invisible Links — The 6 IT-OT Bridges That Could Compromise Your Operations

Who Should Own What

The most common governance failure in IT/OT convergence is not that the wrong team owns something. It is that no one knows who owns it.

Ownership needs to be written down before the first disagreement, not negotiated during an incident at 3 a.m. A reasonable starting model:

• OT owns the process, the control network, and change approval authority inside the operational zone. Anything that touches a PLC, an HMI, or a safety system requires OT sign-off.
• IT owns enterprise identity, the WAN connection, and shared services up to the boundary of the operational network.
• The IT/OT boundary is jointly owned, jointly documented, and jointly reviewed on a regular schedule.
• Escalation paths and decision authority are agreed in advance — who has authority to isolate a shared link during an incident? Who approves firewall changes at the boundary? That should be in writing before anyone needs to use it.
  

Data Flow: Design the Direction Before the Pipe

Not all data movement between IT and OT is equal. The direction of data flow matters as much as the existence of the connection, and in most cases the safer model is one-directional.

Operational data — process values, alarms, historian data — should flow upward and outward through a historian or DMZ pattern wherever possible. Enterprise systems should not initiate connections directly into the control zone. Reporting and analytics systems should receive a copy of the data they need, not a path back to the underlying process.

This is the zones-and-conduits model that ISA/IEC 62443 describes, and it works for remote operations just as well as it does at large facilities. Every cross-boundary data flow should have an owner, a documented purpose, and a review date. Flows that cannot meet those criteria are candidates for elimination.

Related: The Five Most Common Attack Paths in OT — including how IT-to-OT pivots work when boundaries are not designed

Sharing a Constrained Link Without Trampling Each Other

At a remote site, the WAN link is critical infrastructure for both IT and OT. It also has limits. Without deliberate traffic management, enterprise traffic can starve operational traffic.

Quality of service configuration should ensure that operational traffic — telemetry, alarms, control commands — wins when bandwidth is constrained. Patch downloads, backup jobs, video conferencing, and enterprise traffic should yield to operational traffic, not compete with it on equal footing.

The link itself should be monitored for availability and quality. Link degradation affects both teams simultaneously, and neither team should be discovering link problems through a process alarm rather than a network alert.

Continuity When the Shared Link Goes Down

Designing for convergence also means designing for the failure state. What happens to the site when the shared link goes down?

The answer needs to be that the site operates safely in isolation. Local control systems run without the WAN. The historian buffers data locally and syncs when the link returns. Authentication falls back to local credentials. The emergency out-of-band path — cellular, satellite — is brokered, logged, and terminates at the firewall.

The organization should also define what syncs first when the link returns, in order of operational priority. This is not a technical detail to leave to whoever is on call. It is a decision that belongs in the continuity plan.

Read more: The Path to OT Resiliency: Why OT Cannot Mirror IT and What to Do Instead‍

The Human Side: One Team, Two Disciplines

Convergence is not IT absorbing OT. It is not OT walling out IT. It is two disciplines operating as one team across distance, with defined handoffs and shared accountability.

That requires joint change review for anything touching the boundary — a firewall rule change at the IT/OT interface should involve both teams, every time. It requires cross-training so the on-site generalist can execute the first steps for either domain during an incident. And it requires shared metrics that both teams respect: uptime, safe operation, link availability, and recovery time.

The metrics question is often where convergence programs stall. IT measures in IT terms, OT measures in OT terms, and the shared infrastructure falls through the gap. Building a shared dashboard — even a simple one — creates accountability that neither team has alone.

Related: OT Logging That Matters: Less Noise, More Signal — on building visibility that operations teams actually trust

30-Day 'Do This Now' Checklist

1. Map every data flow crossing the IT/OT boundary at one remote site. Write down what it is, why it exists, and who owns it.
2. Get IT and OT leadership to agree in writing on ownership and decision-making authority at the boundary.
3. Configure traffic priorities so operational traffic wins when the link is constrained.
4. Define the degraded-mode operating procedure for when the shared link is down.
5. Run a tabletop exercise where the shared link is down for 48 hours. Track every assumption that fails.
   

A Designed Boundary Is Not a Divided Team

Convergence done right is not a story about IT winning or OT losing. It is a designed boundary, deliberate data flow, and two disciplines operating as one team across distance. Organizations that do this well do ’t argue about turf. They argue about link priority and recovery sequence — which are the right arguments to be having.

Find the content useful? Subscribe to The Catch, our exclusive weekly LinkedIn newsletter focused on real-life experiences doing cyber right in the most highly regulated industries.