OT/IT convergence: a strategy operations will accept

Convergence is happening to you either way

OT/IT convergence stopped being optional the day the business started pricing decisions on live process data. Production dashboards, energy optimization, predictive maintenance, ESG reporting — all of it pulls from the plant floor, and the pull will happen with or without an architecture. The strategic question is not whether to converge but which layers converge, and which boundary gets reinforced while they do.

I spent 2015–2019 running both sides at a Chevron Oronite petrochemical plant — the office network and the process-control network, one person with two hats. That arrangement is rarer than it should be, and it taught me the central lesson of this article: almost every convergence failure I have seen since, on accounts I lead now, is a failure of organizational design that later presents as a technical incident.

Convergence is not a network project. It is a treaty.

Treaties fail when one side writes the terms. IT arriving with enterprise policy binders fails; operations changing the locks fails. What works is negotiating, layer by layer, what is shared and what is sovereign — and writing it down before the first incident tests it.

What converges and what must not

The clean way to think about it: converge data, standards, and visibility; do not converge trust, cadence, and authority.

Layer	Converge?	The working model
Process data to business	Yes	One-way flows through the DMZ; replicated historian or publish-only gateway
Security monitoring	Yes	OT sensors feed the same SOC, with OT-literate runbooks
Network standards & tooling	Yes	Same switch vendors, same config standards, same documentation system
Identity architecture	Patterns only	Same practices (MFA, least privilege, joiner-leaver), separate OT domain, no inbound trust
Patch management	No	Vendor-qualified list, DMZ staging, outage-window installation
Change authority	No	Plant change board rules OT; enterprise CAB does not reach past the DMZ
Endpoint management	Carefully	Only OT-vendor-qualified agents; enterprise auto-remediation stays out

The identity row deserves emphasis, because it is the most common fatal shortcut. Extending the corporate domain into the plant feels like convergence — single sign-on, one admin team, tidy org chart. What it actually installs is a ransomware conduit: once enterprise credentials open OT systems, every IT-side credential theft is an OT incident waiting for a trigger. Converge on the identity-first practices — strong authentication, lifecycle discipline, privileged access management — while keeping the trust boundaries separate. The practices travel. The trust must not.

Shared services: the honest inventory

Services worth centralizing, each with the OT-specific condition that makes it safe:

• Patch distribution. A staging server in the OT DMZ replicates from enterprise patch management but publishes only the vendor-qualified list. OT pulls; IT never pushes past the DMZ. The direction of that verb is the whole design.
• Endpoint protection. Same product family as the enterprise where the control-system vendor qualifies it, managed from a console in the DMZ. Alert-and-log modes on HMIs; leave the aggressive auto-quarantine behavior on the office side, where isolating a machine inconveniences a user instead of blinding an operator.
• Backup. Shared platform and standards, separate repositories and credentials — and coverage extended to what enterprise backup teams never think of: controller programs, HMI images, license servers, the installation media for software the vendor stopped shipping years ago.
• Time, DNS, logging. OT instances of each, inside the boundary, syncing outward through defined conduits. Never OT devices pointed directly at enterprise or public infrastructure.
• Monitoring and SOC. The genuine convergence win. OT network sensors feeding the enterprise SOC buy you the correlation that catches IT-to-OT lateral movement while it is still lateral. The condition: analysts need OT-specific runbooks, starting with rule one — call the control room before touching anything — because the playbook that isolates a compromised laptop causes an outage when applied to an HMI.

The patching reality, negotiated in advance

Convergence programs stall hardest on patch policy, because enterprise security policy says “critical patches in 14 days” and the plant says “the next window is the October turnaround.” Here is the part that took me time to accept: both sides are right, in their own domain. The resolution has to be written down as policy, once, rather than re-argued monthly:

1. The OT patch baseline is the vendor-qualified list, not the CVE feed.
2. Exposure-driven exceptions exist: an actively exploited vulnerability on a DMZ-facing system justifies an emergency window, and plant leadership signs the risk either way — patch now, or accept documented compensating controls until the outage.
3. Compensating controls are legitimate: conduit tightening, virtual patching at the OT firewall, allow-listing, monitoring. NIST SP 800-82r3 says so explicitly, which is useful ammunition the day an auditor reads the enterprise policy at the plant gate.
4. Every planned outage has a security work package pre-staged. Window time is the scarcest resource in OT, and none of it should ever be spent deciding what to do.

Who owns the firewall

The IT/OT boundary firewall is where convergence politics concentrate, because it is the one object both organizations touch daily. I have now watched every pure ownership model fail somewhere. The split that works:

• Platform ownership: IT security/network engineering. They patch it, back it up, monitor it, and hold it to the same configuration hygiene as every other firewall in the fleet. An unpatched boundary firewall administered “by the plant” is how you end up with a five-year-old firmware image guarding your most important boundary.
• Policy ownership: joint, with OT veto. Every rule change goes through a change record that names the conduit, the business reason, and the OT approver. No emergency enterprise-side change may open a path into the control zones — emergency procedures work in the closing direction only.
• One register, kept current. The conduit register from the Purdue-model article is the shared source of truth. If the firewall config and the register disagree, that is a finding, not a shrug — and it is where documentation discipline pays out directly.

Earning trust with operations

The technical architecture fails without this part, so treat it as part of the architecture. Operations people are not obstacles to convergence; they are the people who will be standing at the console when your design meets its first bad night. What worked for me, and what I now coach teams to do:

Learn the process before proposing changes. Walk the unit with an operator. Learn what the plant makes, what a trip costs, and which screens the control room actually watches. The first time you say “we’ll just reboot it” about a server whose function you cannot explain, you have labeled yourself a tourist for a year.

Adopt their risk language. Operations runs on management of change, pre-startup safety reviews, and permits — a risk discipline older and, in its domain, better tested than anything in enterprise IT. Submit your firewall change to their MOC process before they ask you to. Nothing builds credibility faster than IT voluntarily accepting plant discipline.

Respect the calendar. The turnaround schedule is the plant’s heartbeat. Bring your project list to turnaround planning a year early, and never burn window time with unprepared work. Burn it once and you will hear about it for the rest of your tenure. Fairly.

Give before you take. Fix the control room’s flaky printer VLAN. Get the vendor’s diagnostics working through a proper conduit instead of the cellular dongle. Deliver visible wins that make operators’ shifts easier, and the security asks that follow will land on prepared ground.

Staff for both literacies. The durable model is not “IT runs OT” or “OT keeps IT out” — it is a small number of people fluent in both, holding the boundary honestly. If you have no such people, make them: rotate a network engineer through the plant, send a controls tech to security training. It is the single best convergence investment available, because the fundamentals of OT security are learnable — but only by people both sides will talk to.

What to write down

The convergence charter: which layers converge and which do not, on one page leadership has signed. The shared-services matrix with its OT conditions. The patch policy with its exception path. The firewall RACI and the conduit register. And the escalation path for the 2 a.m. question — who decides, together, whether the plant keeps running.

If that last name is not written down, the convergence program is not finished, whatever the architecture diagrams say. Convergence, like every integration of two engineering cultures, succeeds on the boundary terms both sides can live with at their worst moment — not on the diagram that looked clean at the kickoff.