The IT/OT Convergence: A Survival Guide for Industrial Leaders

IT/OT convergence should create governed data exchanges, not one flat network. Information technology can provide identity, logging, analytics, and service management while operational technology retains authority over physical processes, safety constraints, and production windows. NIST SP 800-82 Rev. 3 explicitly treats performance, reliability, and safety as OT security requirements, so enterprise practices must be adapted rather than copied unchanged.

This is a vendor-neutral operating model, not a reference design for every plant. It does not promise Zero Trust, compliance, uninterrupted production, or risk elimination. Each site still needs a process hazard review, cybersecurity risk assessment, validated recovery procedures, and approval through its management-of-change process.

Begin with ownership, not equipment

Convergence stalls when everyone can request a connection but nobody owns its consequences. Use a small RACI for every cross-boundary service:

Decision	Accountable	Responsible	Consulted
Process and safety impact	Plant manager	Control engineer	Safety, operations
Zone and conduit design	OT security owner	Network engineer	IT security, integrator
Data purpose and retention	Business data owner	Application owner	OT owner, privacy/legal
Change window and rollback	OT asset owner	Maintenance lead	Vendor, production

The asset owner accepts operational risk. IT security defines enterprise controls; it does not unilaterally patch or scan controllers. Vendors receive bounded tasks and time-limited access, never permanent ownership. Record escalation authority and who can terminate a session or invoke rollback.

Partition zones and conduits

ISA/IEC 62443 uses zones to group assets with common security requirements and conduits to control communication between zones. That model is more useful than labels such as “trusted OT.” Start with process function and consequence: safety systems, basic control, supervisory systems, site operations, the industrial demilitarized zone (IDMZ), and enterprise services may require distinct zones.

The IDMZ is a buffer, not a synonym for the whole OT network. Terminate or broker cross-boundary services there: replicated historians, managed file transfer, jump hosts, update repositories, and log relays. Separate firewalls on the enterprise and control sides should implement independently reviewed rules. Do not route the enterprise network directly to PLCs, engineering workstations, or safety systems, and do not flatten VLANs merely to simplify discovery.

Specify data flows before firewall rules

Inventory each flow by owner, source, destination, direction, protocol, authentication, data sensitivity, frequency, retention, and failure behavior. Default-deny is meaningful only after required flows are documented. This deterministic fixture illustrates policy intent; it is an allow/deny matrix, not deployable firewall syntax:

Source	Destination	Purpose	Verdict
OT historian	IDMZ replica	Publish approved process history	ALLOW
Enterprise analytics	IDMZ replica	Read approved history	ALLOW
OT log relay	IDMZ collector	Forward security events	ALLOW
Enterprise user	PLC	Direct programming	DENY
Internet vendor	Engineering workstation	Direct support session	DENY
IDMZ replica	Safety system	Control command	DENY

The matrix deliberately permits no control commands across the boundary. A real policy also needs ports, endpoints, certificates, rate limits, monitoring, expiry, and a named owner.

Broker remote access

Remote support should enter through an approved access service and hardened jump host in the IDMZ, with named accounts, multifactor authentication where technically feasible, authorization for a specific asset and task, an approved time window, session logging, and rapid revocation. Disable access when the task ends. Avoid shared vendor accounts, split tunneling, unattended modems, and direct inbound paths to critical assets. Operations must be able to observe and terminate the session; emergency access needs a separately tested procedure.

Make controls operable

An OT inventory should cover hardware, firmware, software, network location, function, owner, criticality, dependencies, supported versions, backup status, and remote-access paths. Maintain it through procurement, commissioning, change, and retirement. Passive discovery can supplement records, but active scanning requires OT approval and testing.

Federate identity where supportable, while keeping controlled local recovery accounts for loss of enterprise dependencies. Centralize authentication, configuration-change, firewall, jump-host, and security events with synchronized time. Do not assume every legacy device can produce useful logs; monitor its conduit and document the gap.

Patch and backup work belongs in production-approved windows. Test updates on representative systems, verify vendor constraints and recovery media, capture known-good controller logic and configurations, and define stop conditions. Backups are not evidence of recoverability: perform controlled restore tests and protect offline or immutable copies where appropriate.

Stage change and preserve rollback

Baseline: confirm owners, inventory, diagrams, flows, backups, restore results, and acceptance criteria.
Pilot: implement one low-consequence, read-only flow through the IDMZ; observe latency, load, logs, and failure behavior.
Expand: add approved flows one at a time during change windows, with rule expiry and post-change review.
Operate: reconcile inventory, review accounts and rules, exercise incident response, and measure recovery.

Every stage needs a rollback trigger, decision authority, last known-good configuration, validated restore path, communications plan, and evidence that rollback completed. If a change affects process safety or reliable control, stop and return to the approved state rather than improvising around the control system.