TECHNICAL NOTE / INDUSTRIAL NETWORKS

IT/OT convergence: a practical starting point

Connecting production data to business systems can improve visibility and coordination, but every new interface also changes the system boundary. A responsible plan begins with assets, data flows, operating consequences and ownership—not with a product.

Information technology manages business information and computing services. Operational technology observes or changes physical processes through systems such as PLCs, HMIs, drives, instrumentation, industrial networks and SCADA. Convergence occurs when these environments exchange data, share infrastructure or depend on coordinated services.

The central engineering question

What information must cross the boundary, in which direction, at what frequency, under whose authority, and what happens to the physical process when that connection is unavailable or incorrect?

Why an industrial connection is different

In an office environment, delayed data may interrupt a workflow. In an industrial environment, a poorly understood dependency can affect equipment behavior, recovery time, product quality or safety. Availability, deterministic behavior, maintenance windows and safe fallback states therefore belong in the same conversation as confidentiality and access control.

NIST’s OT security guidance emphasizes that safeguards must account for the performance, reliability and safety requirements of systems that interact with the physical environment. That is why simply extending normal enterprise practices into a control network is not a complete design method.

Six foundations for a responsible starting point

1. Establish an asset and software baseline

Record controllers, HMIs, engineering workstations, switches, gateways, historians, remote-access systems and supporting services. Include manufacturer, model, firmware or software version, network location, owner, criticality and available backups. An inventory is useful only when it supports decisions and is maintained as the system changes.

2. Map required communication flows

Document which device initiates each connection, its destination, protocol, port, direction, purpose and operational consequence. Separate required traffic from traffic that merely exists today. This map becomes a basis for interface requirements, firewall rules, troubleshooting and acceptance testing.

3. Organize the network by function and consequence

Segmentation limits unnecessary paths between enterprise services, industrial supervisory systems, machine or process cells and field devices. The design may use zones, VLANs, firewalls and an industrial DMZ, but the correct arrangement depends on the process and risk assessment. Segmentation is not just drawing boundaries; allowed flows must be explicitly defined, monitored and tested.

4. Treat remote access as a controlled service

Remote support should have named ownership, approved users, strong authentication, limited destinations, time or approval controls where appropriate, and useful logging. Direct exposure of control equipment to the public internet is not an acceptable shortcut. Vendor and integrator access should be provisioned deliberately rather than inheriting broad internal privileges.

5. Plan changes around operations

Firmware, security controls and network changes can affect legacy devices or communications in unexpected ways. Record the existing state, identify dependencies, test away from production when practical, define rollback steps and coordinate the maintenance window with operations. A secure change that prevents safe operation is not a successful change.

6. Prepare backup and recovery evidence

Confirm that source files, configurations, licenses, credentials-handling procedures and restoration instructions exist. A file is not a recovery plan until the organization knows what it restores, where it belongs, which version is authoritative and how restoration will be validated.

Information to gather before discovery

  • A simple network diagram and list of affected assets.
  • The business or operating information that must move between systems.
  • Known PLC, HMI, drive, SCADA, historian and network platforms.
  • Existing remote-access methods and responsible owners.
  • Permitted outage windows, safety constraints and recovery expectations.
  • Available source files, configurations, backups and change records.
  • IT, operations, controls, maintenance and vendor stakeholders who must approve interfaces.

Where INOVAX can contribute

Subject to an agreed scope, INOVAX can help document controls assets and interfaces, map required data paths, define PLC/HMI and industrial-network requirements, identify operational dependencies, prepare change and test plans, and coordinate technical questions across operations, controls and IT. Specialized cybersecurity assessments, penetration testing, regulatory determinations and security certifications require separately qualified scope and personnel; this article does not claim those services.

Frequently asked questions

Does convergence require replacing existing PLCs?

Not automatically. The decision depends on supported protocols, lifecycle status, available source files, performance, security constraints and the role of gateways or intermediate systems. Compatibility must be verified at the exact model, firmware and software-version level.

Is a VLAN enough to secure an industrial network?

A VLAN can support logical separation, but it does not by itself define trustworthy communication. Architecture, routing, rule enforcement, identity, monitoring, physical access, change control and recovery still need to be considered.

Should production data go directly to the cloud?

There is no universal answer. Begin with the required data, direction, latency, consequence of loss, buffering, ownership and exposure. An edge gateway, historian, DMZ service or other intermediate architecture may be appropriate after the requirements and risks are defined.

What are typical deliverables?

Depending on scope: an asset and interface register, current-state diagram, communication-flow matrix, requirements, dependency and risk notes, proposed architecture, change record, rollback plan, test plan and updated handoff documentation.

Primary references

Educational information only. Site-specific architecture and cybersecurity decisions require authorized review of the actual system, operating risks and applicable requirements.