What is IT/OT convergence?
IT/OT convergence is the deliberate integration of two technology domains that were built with different priorities, governed by different teams, and historically kept separate by an air gap or strict network segmentation. Information Technology manages data: it stores, processes, and communicates business information. Operational Technology manages physical processes: it controls machinery, measures process variables, and actuates equipment in real time. Convergence means those two domains share data, infrastructure, and in some cases governance.
For most of industrial history, separating IT and OT was the default security architecture. OT systems were isolated on their own networks, physically air-gapped from the business network. An engineer who needed SCADA data for a weekly production report manually exported it, emailed a spreadsheet, or walked data to an IT system on a USB drive. This worked when operational data was consumed by a small number of people and rarely crossed network boundaries.
What changed is the demand for that data. Predictive maintenance requires streaming sensor data to cloud ML platforms. ERP systems need production counts in real time to drive accurate scheduling. Executive dashboards need live OEE visibility, not yesterday's shift report. AI agents need access to every instrumented process variable to generate grounded operational insights. None of these use cases are compatible with air gaps and USB drives. IT/OT convergence is the organizational and technical response to that demand.
Convergence is a spectrum, not a switch. An organization at the early end has a historian feeding a BI dashboard over a secured DMZ. An organization at the far end has real-time OT data flowing into a cloud data lakehouse, AI agents subscribing to a Unified Namespace, and joint IT/OT governance. Most plants are somewhere in the middle, adding data flows incrementally as use cases justify them and security review approves them.
IT vs OT: the fundamental differences
Understanding why IT and OT have stayed separate for so long requires understanding how different the priorities, constraints, and design philosophies of each domain are. These are not arbitrary organizational silos; they reflect genuine differences in what each domain optimizes for.
Information technology (IT)
Manages data and business systems
| Primary priority | Confidentiality, then integrity, then availability (CIA) |
| Failure consequence | Data loss, compliance risk, revenue disruption |
| Patch tolerance | High: systems can be taken down for updates regularly |
| Asset lifespans | 3 to 5 years; hardware and software refreshed frequently |
| Security posture | Designed with network security and authentication from the ground up |
| Uptime expectation | 99.9% acceptable; planned maintenance windows normal |
| Protocol vocabulary | TCP/IP, HTTP, TLS, DNS, Active Directory, REST API |
| Operated by | IT department with cybersecurity expertise |
Operational technology (OT)
Controls physical processes
| Primary priority | Availability, then integrity, then confidentiality (AIC) |
| Failure consequence | Production halt, equipment damage, safety incident, environmental violation |
| Patch tolerance | Very low: patching may require plant shutdown, often deferred indefinitely |
| Asset lifespans | 15 to 30 years; PLCs and DCS systems outlive multiple IT refresh cycles |
| Security posture | Designed for reliability; security often added later, if at all |
| Uptime expectation | 99.99%+; unplanned downtime measured in production loss per hour |
| Protocol vocabulary | Modbus, EtherNet/IP, Profibus, DNP3, OPC DA/UA, proprietary vendor protocols |
| Operated by | Process engineers and automation specialists with deep system knowledge |
The collision at convergence: When IT security teams apply standard IT practices to OT environments without understanding these differences, they create operational risk. An IT team that patches a PLC mid-shift, scans an OT network with an active vulnerability scanner, or disables a legacy protocol without consulting the process engineer can halt production, damage equipment, or create safety hazards. IT/OT convergence requires both teams to understand each other's constraints before making changes that cross the boundary.
The Purdue Model and where convergence sits in it
The Purdue Model (formally the Purdue Enterprise Reference Architecture, or PERA) was developed in the early 1990s at Purdue University as a hierarchical framework for computer-integrated manufacturing. It defines a layered architecture for industrial systems, from physical devices at the bottom to enterprise IT at the top, with each level communicating only with adjacent levels. The model remains the dominant reference architecture for thinking about where data lives, where it should flow, and where security controls should be placed at the IT/OT boundary.
Enterprise network / corporate IT
The corporate business network: ERP, CRM, HR systems, email, internet access. Business decisions are made here using data that ultimately originates at Levels 0 through 3. The primary data consumers of convergence initiatives sit at this level.
SAP / ERPBusiness intelligenceCorporate dashboardsCloud platforms
Site business / operations management IT
Site-level IT systems: MES, scheduling, production management, quality systems, local databases. The data aggregated here drives site-level operational decisions and feeds upward to Level 5.
MESQuality systemsSchedulingEnterprise historian
Industrial DMZ (iDMZ): the IT/OT convergence layer
The Demilitarized Zone sits between IT and OT networks as a controlled buffer. Data that needs to cross the IT/OT boundary lives here: historians that aggregate plant data for enterprise consumption, remote access servers with enforced authentication, and middleware that translates between OT and IT protocols. This level was created specifically as an architectural response to IT/OT convergence. Firewalls control exactly what can enter and exit from both sides.
HistoriansCogent DataHubOPC tunnelingMQTT brokerN3uron
Operations / site control
Plant-level operations: the historian that archives plant data, analytics servers, batch management, OPC servers that aggregate device data. The top of the OT domain. Systems here connect to Level 2 below and pass data upward to the DMZ and Level 4.
TOP ServerPlant historianOPC ServerBatch management
Control systems
HMI and SCADA systems that supervise and control the physical process. Operators interact with these systems to monitor process status, respond to alarms, and issue control commands.
SCADAHMIDCS supervisory
Basic control
PLCs, DCS controllers, RTUs, and safety systems. These devices execute the control logic that manages physical processes: opening valves, adjusting pump speeds, controlling temperature loops. They communicate with field instruments below and SCADA systems above.
PLCDCSRTUSafety systems
Physical process
The actual physical equipment and field instruments: sensors, actuators, valves, motors, analyzers, flow meters. These generate the raw process data that the entire architecture above is built to collect, transmit, contextualize, and use. Everything starts here.
SensorsActuatorsValvesMotorsAnalyzers
Is the Purdue Model still relevant? Some practitioners argue the model is obsolete because IIoT devices now connect directly to cloud platforms, bypassing the traditional hierarchy. Others argue its core principle, that systems at different security levels should communicate only through controlled interfaces, remains essential regardless of physical network topology. The iDMZ at Level 3.5 is more important than ever as the number of IT/OT crossing points increases, not less.
Why convergence is happening now
IT/OT convergence is not new, but the pace has accelerated significantly in the last decade. Several converging pressures are making the previously isolated OT domain impossible to keep offline.
🤖
AI and machine learning applications
Predictive maintenance, process optimization, anomaly detection, and soft sensors all require continuous access to large volumes of OT sensor data. These ML workloads run on IT infrastructure and consume data that lives in OT systems. There is no industrial AI strategy that does not require IT/OT convergence as a prerequisite.
📊
Real-time enterprise visibility
Executives and supply chain teams need real-time production data to make scheduling, procurement, and logistics decisions. Waiting for a morning shift report is not compatible with just-in-time manufacturing. ERP and MES systems need live production counts, quality data, and downtime events as they happen.
☁️
Cloud and IIoT platform adoption
Cloud platforms provide scalable analytics, historian, and ML infrastructure that plants increasingly want to use. Accessing those platforms from OT systems requires connectivity that crosses the traditional air gap. MQTT and OPC UA provide the protocols; the Purdue Model provides the framework for crossing the boundary securely.
🔧
Remote monitoring and maintenance
Remote operations centers, centralized condition monitoring across multiple plants, and vendor remote support all require network access to OT systems that once required physical presence. The operational cost savings from centralized monitoring have become significant enough to justify the security investment required.
🔗
Supply chain integration
Automated purchase orders triggered by real production consumption, quality certificates from actual measurement data, and shipment notifications tied to production completion all require OT data to flow into IT systems without manual intervention.
📋
Regulatory and compliance requirements
Environmental reporting, pharmaceutical batch records, energy reporting, and safety regulations increasingly require automated, auditable data pipelines from OT systems. Manual data extraction is no longer sufficient for high-frequency reporting requirements.
The cultural and organizational challenge
The technology problems of IT/OT convergence are largely solved. The middleware, protocols, security tools, and connectivity platforms to move data securely between OT and IT networks exist and are mature. The harder problem is organizational: IT and OT teams have different training, different priorities, different vocabulary, and sometimes actively conflicting objectives that must be reconciled before any technical integration can be sustained.
| Dimension | IT team perspective | OT team perspective |
|---|
| Patching | "This system is two years behind on patches and is a critical vulnerability." | "That patch has never been tested against our control logic and we're not taking a reactor offline to find out what happens." |
| Network scanning | "We need to scan the OT network to identify assets and vulnerabilities." | "Active scanning can cause some PLCs and legacy devices to lock up or behave unpredictably. Passive monitoring only." |
| Password policies | "All accounts must have 90-day password rotation and MFA." | "The HMI operator account has had the same shared password for 15 years. Locking someone out during a process upset can cause a safety incident." |
| Change management | "We can push this configuration change tonight in the maintenance window." | "There is no maintenance window. This process runs 24/7/365. Any change requires weeks of testing and MOC approval." |
| Uptime priority | "Availability is one of three equal security pillars." | "Availability is not negotiable. A 30-minute unplanned outage on this line costs more than our annual IT security budget." |
| Risk framing | "The risk is data breach, regulatory fine, and reputational damage." | "The risk is a production accident, equipment destruction, environmental release, or injury. The stakes are categorically different." |
Both perspectives are operationally valid. The cultural work of IT/OT convergence is creating governance structures where both teams have a voice, shared ownership of the IT/OT boundary, and a common framework for evaluating changes that affect both domains. Successful convergence projects almost always have a joint IT/OT steering group with clear escalation paths, not just a technology architecture.
Securing the convergence boundary
The security implications of IT/OT convergence are real and serious. OT systems were designed for reliability, not network security. Connecting them to IT networks exposes devices that may be running unpatched operating systems, using unauthenticated protocols, and lacking the ability to run endpoint security agents, to threat actors who previously could not reach them. The Colonial Pipeline attack in 2021, where a ransomware infection on the IT network triggered a precautionary shutdown of OT operations, illustrated the operational consequences that a flat or poorly segmented converged network can produce.
The security architecture for a converged environment should reflect the following principles:
- Segment, do not flatten. The iDMZ at Level 3.5 is the controlled crossing point. No direct connections should exist between IT and OT networks that bypass it. Every data flow that crosses the IT/OT boundary should be explicitly approved, documented, and monitored.
- Outbound-only from OT where possible. OT systems initiating outbound connections to the DMZ (as Cogent DataHub tunneling enables) keep inbound ports on the OT firewall closed, which is a fundamentally stronger security posture than allowing IT-initiated connections into OT.
- Use industrial-aware monitoring. Standard IT security tools that rely on active scanning are not safe in OT environments. Passive network monitoring tools that understand OT protocols and detect anomalous patterns without generating traffic are the appropriate tool.
- Data diodes for one-way flows. For the most sensitive OT environments, unidirectional security gateways physically enforce one-way data flow from OT to IT, making reverse connections physically impossible. Cogent DataHub supports software data diode mode and works with hardware data diodes.
- Separate OT identity management. OT systems should not authenticate against the corporate Active Directory. A compromise of corporate credentials should not grant access to OT systems. A dedicated OT identity structure limits lateral movement from IT to OT.
Convergence and the attack surface: IT/OT convergence does not just enable data to flow from OT to IT; it also opens pathways for threats to move from IT to OT. Every crossing point is a potential attack vector. The governance principle is that every new data flow across the IT/OT boundary should be explicitly justified by a business case, evaluated for security implications, approved by both IT and OT representatives, and monitored continuously after implementation.
How Software Toolbox enables IT/OT convergence
Software Toolbox's role in IT/OT convergence is the technical layer: the connectivity, protocol translation, data modeling, and secure transport that moves OT data to where IT systems can use it, without compromising OT availability, without opening inbound ports on the plant network, and without requiring changes to the OT systems that are already working.
Connect
TOP Server
Connects to 140+ device types at Levels 0 through 3 using their native protocols (Modbus, EtherNet/IP, OPC DA, OPC UA, DNP3, and more). Exposes collected data as an OPC server for consumption by historians, middleware, and data platforms in the iDMZ and above. The foundational connectivity layer that gives the convergence architecture access to OT data without touching the devices themselves.
Model
N3uron
Collects OT data from edge devices and OPC servers, applies ISA-95 data modeling to contextualize raw tag values into business-meaningful data, and publishes to an MQTT broker using Sparkplug B. N3uron is the contextualization layer: it transforms a PLC register value into a named, structured data point that IT systems and AI agents can understand without expertise in the underlying OT configuration.
Secure transit
Cogent DataHub
The secure crossing point at the IT/OT boundary. DataHub tunnels OPC DA, OPC UA, and MQTT data across firewalls and DMZs without opening inbound ports on the OT network, using outbound connections from the plant side. Supports data diode mode for one-way flows, SSL/TLS encryption, store-and-forward across network interruptions, and OPC HDA-to-UA bridging for historian connectivity.
Route and integrate
OPC Router
Visual workflow middleware for routing OT data into IT destinations: SQL databases, REST APIs, cloud platforms, SAP/ERP systems, MES, and reporting tools. Handles the mapping, transformation, and conditional logic required to deliver OT data in the format and at the frequency that IT systems expect, without custom code. Commonly used for PLC-to-ERP integrations and OPC-to-database pipelines.
Full stack
IT/OT data contextualization service
Software Toolbox's end-to-end IT/OT integration service: architecture design, connectivity implementation, data modeling against ISA-95, UNS build-out, historian-to-lakehouse pipeline setup, and ongoing support. For organizations building the data infrastructure that industrial AI requires, this service covers the full stack from OT device connectivity to cloud data platform delivery.
Frequently asked questions
What does IT/OT convergence actually look like in a plant?+−
The most common starting points are historian connectivity and remote monitoring. A plant that previously emailed a daily production report now has a live OEE dashboard fed directly from OPC data. A plant that previously required on-site presence for troubleshooting now has secure remote access for engineers at a central operations center. A plant historian now replicates to a cloud data platform where ML engineers can build predictive maintenance models.
More advanced convergence looks like a Unified Namespace: all OT data published to a shared MQTT broker in the iDMZ, from which MES, ERP, analytics platforms, AI agents, and reporting tools all subscribe directly. Adding a new IT application means subscribing to the namespace, not building another custom integration. This architecture is what SWTB helps customers build incrementally, starting with one data flow and expanding as the pattern is proven and governance is established.
What is the difference between IT/OT convergence and IIoT?+−
IIoT (Industrial Internet of Things) refers to the deployment of connected sensors, devices, and edge computing in industrial environments, often with cloud connectivity built in. IT/OT convergence is the broader integration initiative that IIoT is one driver of. A smart sensor that publishes data directly to a cloud platform over cellular is an IIoT device; deciding what happens to that data, how it is contextualized, who can access it, and how it interacts with existing SCADA and ERP systems is the IT/OT convergence challenge.
IIoT devices can actually complicate convergence because they introduce new entry points into the OT network that may bypass traditional network segmentation. Governance of IIoT device connectivity is one of the most actively discussed areas in OT security.
Does IT/OT convergence require replacing OT systems?+−
No. The most practical convergence architectures preserve existing OT infrastructure and add a connectivity and translation layer above it. PLCs, DCS systems, and SCADA platforms that are working reliably remain in place. An OPC server (like TOP Server) collects their data using existing protocols, an edge platform (like N3uron) models and publishes that data, and a middleware layer (like Cogent DataHub) moves it securely across the IT/OT boundary.
This non-invasive approach is essential for OT environments where equipment replacement requires validation, regulatory approval, or significant downtime. The convergence layer is additive: it adds data visibility without touching the control layer. Software Toolbox's explicit position is that convergence should be achievable without ripping out what is already working.
How do you handle OT data quality when moving it to IT systems?+−
OPC-based data carries a quality field with every value (Good, Bad, Uncertain) that indicates whether the value can be trusted. Any convergence architecture that moves OPC data through to IT systems should preserve and propagate this quality field so that IT applications, analytics platforms, and AI models can distinguish between reliable values and values that should be excluded from calculations.
Beyond quality stamps, data contextualization adds a further layer of assurance. A raw PLC register value that means nothing to an IT system becomes a named, structured data point with engineering units, a defined range, and a position in the ISA-95 hierarchy. This contextualization, applied by platforms like N3uron, is what makes OT data actually useful to IT applications rather than simply accessible to them.
How should IT and OT teams share responsibility at the convergence boundary?+−
The most successful structures create a joint IT/OT working group that owns the convergence architecture, with clear responsibility assignment at the iDMZ. OT teams retain full authority over Levels 0 through 3, including what data is exposed and at what rate. IT teams retain full authority over Levels 4 and 5, including security policies for the business network. The iDMZ is jointly owned: any data flow added to or removed from the crossing point requires approval from both sides.
Practical governance elements include a data flow registry documenting every approved crossing point, joint change control for anything that affects the DMZ, and a joint incident response playbook. These organizational structures, not technology products, determine whether a convergence architecture remains secure over time.
What is the relationship between IT/OT convergence and a Unified Namespace?+−
A Unified Namespace is an architectural pattern that represents a mature form of IT/OT convergence at the data layer. Rather than building individual point-to-point integrations between specific OT and IT systems, a UNS places an MQTT broker in the iDMZ where OT systems publish data and IT systems subscribe to what they need. Every system connects to one shared namespace rather than to each other.
IT/OT convergence is the broader initiative; a UNS is one way to implement the data-sharing dimension of it. A UNS is the more architecturally clean and scalable version of that goal, particularly when the number of OT data sources and IT consumers grows beyond what point-to-point integrations can maintain.
