What Is IT/OT Convergence? Architecture, Security and First Steps

Quick answer

IT/OT convergence is the coming together of operational technology (OT), the systems that run a physical process, such as programmable logic controllers (PLCs), remote terminal units (RTUs), distributed control systems (DCS), supervisory control and data acquisition (SCADA) systems and historians, and information technology (IT), the systems that run the business, such as enterprise resource planning (ERP), databases, analytics and cloud. IT/OT integration is the practical work behind it: collecting operating data inside OT, moving it across a controlled boundary such as an industrial demilitarized zone (DMZ), and delivering it to IT applications without giving the business network a path into the control network. 

Most plants already do some of this. It might be a historian report emailed every Monday, a script that copies tags into a database, or a spreadsheet someone rebuilds by hand each month. These work until the person who built them leaves, the network changes, or someone asks for the same data from a second site.

This guide explains what IT/OT convergence involves in practice, why air gaps no longer hold, how the architecture is usually laid out, which protocols you will meet, where projects go wrong, how it is done with SIOTH®, and a five-step way to start. It is written for engineers who know their plant well and want to understand the IT side without the jargon.

IT vs OT: the key differences

IT (Information Technology) covers business systems: servers, networks, databases, applications, and the people who keep them secure and available.

OT (Operational Technology) covers the systems that monitor and control physical processes: PLCs, RTUs, DCS, SCADA, human-machine interfaces (HMIs), instrumentation, and the industrial networks that connect them. Site-level systems such as manufacturing execution systems (MES) sit between the two.

These differences are why integration is a design problem and not only a networking task. A step that is routine in IT, such as rebooting a server or running a network scan, can be unacceptable on a live control system. Equally, habits common in older OT environments, such as shared accounts and flat networks, become a risk as soon as the plant connects to anything else.

Why are air gaps no longer enough

For years the safest control network was one with no connection at all. Few plants still have a true air gap. Vendor laptops, USB drives, remote-support links and the weekly historian export all cross the boundary, usually without being designed, logged or reviewed. Meanwhile, maintenance, reporting and analytics teams need plant data daily. The real question is whether data leaves OT through one controlled, monitored path or through many informal ones. A designed boundary, meaning an industrial DMZ with outbound-only connections from OT and a protocol break, is what replaces the air gap.

Why plants pursue IT/OT convergence

What actually moves between the two sides

Integration is rarely “connect everything to everything”. It usually covers four kinds of data flow:

1. Real-time values (tags, states, setpoints) for monitoring and dashboards
2. Alarms and events for notification and analysis
3. Historical data for trends, reports and analytics
4. Business context in the other direction, such as production orders or schedules sent down to operations

Most of the effort goes into the first three. Writing back into OT is possible but should be limited, explicit and approved.

How IT/OT convergence works: the Purdue model and industrial DMZ

Industrial networks are commonly described with the Purdue model, which layers the plant from field devices and controllers (Levels 0 to 2) through site operations such as SCADA servers, historians and MES (Level 3) to the enterprise (Levels 4 and 5). Between Levels 3 and 4 sits an industrial DMZ, a buffer zone where data is exchanged so that the IT and OT networks never connect directly.

Figure 1 separates two things that are easy to confuse: the direction data moves, which is mainly up and out of OT, and the side that opens each connection. Level 3 systems poll or subscribe to the field devices, the OT side opens the session to the DMZ, and IT applications request data from the DMZ. No connection is ever opened from IT into OT.

A sound design does four jobs:

• Collect data inside OT using the protocols the equipment already speaks
• Model and normalize it, so tags from different vendors share names, units and structure
• Transport it across the boundary, ideally with the OT side initiating the connection
• Deliver it to IT-side databases, applications, dashboards and analytics

One useful principle here is the protocol break. The protocol spoken inside the control network ends at the boundary, and a separate session carries the data onward. No single connection runs from the business network to a PLC, so a compromised IT host has no direct path into the process.

Protocols you will meet

Most real plants run several of these at once, which is why protocol conversion sits at the center of most integration work.

How to approach IT/OT integration: five practical steps

1. Define the use case first. “We need hourly production figures in the reporting database” is a project. “We need to integrate everything” is not.
2. Inventory the data sources. List devices, protocols, vendors and the tags that matter. Expect inconsistent names and units.
3. Agree ownership. Decide who owns the network boundary, who approves changes, and who responds when data stops flowing. Many projects stall here, not on technology.
4. Design the security boundary. Define zones and conduits, prefer outbound-only paths from OT, and apply least privilege. ISA/IEC 62443 provides the framework.
5. Start small and prove it. Move one site or process area, check data quality against the source, then extend.

A worked example (illustrative)

This is a hypothetical scenario, not a customer case. A gas processing site has a SCADA system, several skid PLCs reachable over Modbus TCP, and an older OPC DA server. The reporting team wants shift production figures and an alarm summary in the enterprise SQL database every hour.

• Use case: hourly production figures and alarm counts. Nothing else in phase one.
• Collection: an OT-side component reads the OPC DA server and the Modbus devices locally, so DCOM and Modbus traffic stay inside the control network.
• Boundary: that component sends data outbound to a service in the DMZ, and the reporting system collects it from there. No firewall rule allows the corporate network to reach OT.
• Resilience: if the link drops, the OT-side component buffers data and forwards it when the link returns, so reports have no gaps.
• Result: the business gets its data, the control engineers keep their network closed, and there is one documented conduit to review.

The next section shows how the same project is set up in SIOTH®.

Common challenges and mistakes

• Direct IT-to-OT connections. Opening firewall rules from the corporate network into the control network is the most common and most risky shortcut.
• Protocol sprawl. Each new system brings another protocol and another custom connector, which becomes expensive to maintain.
• Scripts nobody owns. A script written by one engineer breaks when that person moves on.
• Ignoring data quality. Bad tag names, wrong units and gaps in history undermine every dashboard built on top.
• Treating security as the last step. Retrofitting it onto a working integration is harder than designing it in.
• Overloading the control system. Polling too many tags too fast loads PLCs and servers. Subscription-based protocols help.

How IT/OT convergence is done with SIOTH®

SIOTH® (Smart IoT Highway) is Integration Objects’ IT-OT-IIoT integration platform, connecting OT, IT and Industrial Internet of Things (IIoT) systems. Instead of scripting custom point-to-point connections, engineers configure Data Flows that move data between any source and destination across OT, IT and cloud, so plant data can be organized as a Unified Namespace (UNS) in the Data Model, that every application reads from. The platform has four official modules:

See all SIOTH® modules

The four jobs, done in SIOTH®

• Collect. A SIOTH® node at Level 3 or at the edge reads each source in its own protocol. SIOTH® supports 100+ OT protocols, including OPC UA, OPC Classic DA/AE/HDA, Modbus TCP/RTU, DNP3, IEC 60870-5-104, IEC 61850 (used by intelligent electronic devices, or IEDs, in substations), Siemens S7, EtherNet/IP and SNMP. Field traffic and DCOM stay inside the control network.
• Model. Data Model maps raw tags into an ISA-95 compatible asset hierarchy with consistent names, units and context, so every application sees the same structure.
• Transport. A Data Flow carries the data to a second SIOTH® node in the DMZ. The OT-side node opens the connection (reverse connection), traffic is encrypted with TLS/SSL, ports and flow direction are configurable, and the protocol break means no OT protocol crosses the boundary. Store-and-forward buffers data if the link drops.
• Deliver. In the DMZ, the OPC UA Universal Server and the MQTT Universal Broker, both configurable servers within Data Flow, give IT applications a single endpoint to read from. Data Flows can also deliver to Microsoft SQL Server, Oracle, MySQL, PostgreSQL, AVEVA PI and PI AF, InfluxDB, Kafka and Azure Event Hub, and Unified HMI provides web dashboards.
• Act (optional). The Rule and Workflow Engine runs expert rules, scripts and ML models on the same data for alerts and recommendations. Any write-back into OT stays explicit and approved.

The worked example in SIOTH®

In the gas processing example above, the project becomes a few configured items rather than custom code:

• OT-side node: Data Flows read the OPC DA server and the Modbus TCP skids.
• Data Model: defines the production and alarm structure for the site.
• Boundary: one outbound Data Flow, with store-and-forward enabled, sends hourly values to the DMZ node.
• Delivery: the reporting system reads the values from the DMZ node through the OPC UA Universal Server or the MQTT Universal Broker.

The existing SCADA keeps running untouched, and the conduit is one documented Data Flow that can be reviewed. Typical go-live for a single site is 2–5 weeks, depending on scope.

Security and deployment

Beyond the boundary itself, SIOTH® adds role-based access control, Active Directory and OAuth 2.0 authentication, and an audit trail. SIOTH® is aligned with IEC 62443; whether a specific installation meets the standard depends on how the whole system is designed and operated.

Because SIOTH® can feed an existing SCADA through OPC UA, it does not require replacing what already works. It can run on-premises, at the edge, in the cloud or as a hybrid, so data stays inside the customer’s network when required. For plants that currently run separate protocol converters, tunneling tools, historians, cloud bridges and visualization tools, consolidating them reduces the number of components to secure and maintain. To see it working on your own architecture, request a demo.

Related products

• SIOTH® (Smart IoT Highway): the IT-OT-IIoT integration platform. You configure Data Flows to move data between OT, IT and cloud systems.
• SIOTH® SCADA: web-based SCADA and dashboards for process and operations monitoring.
• OPC UA Universal Server: a configurable server within SIOTH® Data Flow that exposes connected sources as a single secure OPC UA endpoint.
• MQTT Universal Broker: a configurable server within SIOTH® Data Flow that supports MQTT Standard and Sparkplug B, and is Eclipse Sparkplug B certified.
• OPC UA Client: a free tool for testing, exploring and troubleshooting OPC UA servers.

Frequently asked questions

References and further reading

• ISA/IEC 62443 series, Security for industrial automation and control systems (ISA and IEC), including IEC 62443-3-2:2020, Security risk assessment for system design
• ISA-95 / IEC 62264, Enterprise-control system integration
• OPC Foundation, OPC Unified Architecture specification
• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (NIST, September 2023)
• Integration Objects blog, Bridging the OT and IT gap