More than 70% of manufacturers now connect their factory floor to corporate IT networks. That number will keep climbing as predictive maintenance, remote monitoring and MES/ERP integration become baseline expectations rather than competitive advantages. The problem is that most OT devices were never designed to sit on a connected network, and the security approaches built for IT simply do not work on a PLC or HMI.
This guide explains why IT-OT convergence is accelerating, what risks it creates, and how inline isolation lets you extend Zero Trust to the factory floor without agents, downtime or production risk.
What is IT-OT convergence?
IT-OT convergence is the process of connecting information technology networks (email, ERP, cloud applications) with operational technology networks (PLCs, HMIs, SCADA systems, sensors) into a shared or bridged infrastructure. The goal is to unlock real-time operational data for business decisions, remote access and automation. The challenge is that OT devices lack the authentication, encryption and patching capabilities that IT security depends on.
Why IT and OT networks are converging
Factory networks stayed isolated for decades. The air gap between IT and OT was both a design choice and a security blanket. Four business drivers have made that isolation unsustainable.
Remote monitoring and maintenance. Skilled technicians are scarce. Organisations need engineers to diagnose equipment remotely rather than travelling to every site. That requires OT data to flow through IT infrastructure to dashboards and alerting systems.
Predictive maintenance. Sensor data fed into analytics platforms can predict bearing failures, motor degradation and process drift before they cause unplanned stops. Industry data suggests downtime costs can reach $22,000 per minute in some manufacturing environments. The business case for connectivity writes itself.
MES and ERP integration. Manufacturing Execution Systems need real-time production data. ERP platforms need MES data for inventory, quality and scheduling. The data path between shop floor and boardroom runs straight through the IT-OT boundary.
Digital twins and AI analytics. Simulating production processes, optimising energy use and running quality predictions all require high-volume data flows from OT sensors into cloud or edge computing environments.
The IT-OT convergence market reflects this momentum. Analyst estimates put it at roughly $88 billion in 2026, growing at over 17% per year. Yet only about 30% of organisations have fully integrated their IT and OT security operations, which points to a wide gap between connectivity ambitions and security readiness.
What happens when the air gap disappears
Connecting OT to IT does not just add network traffic. It creates attack paths that did not exist before. Three scenarios illustrate the risk.
Scenario 1: compromised laptop reaches the production line. An employee clicks a phishing link. Malware lands on their IT laptop. In a flat or poorly segmented network, that laptop can communicate with devices on the OT segment. The attacker discovers a PLC running outdated firmware, sends modified commands, and production output changes without anyone noticing for hours.
Scenario 2: vendor VPN opens the factory door. A third-party integrator connects via VPN to service a specific HMI. Traditional VPNs grant broad network access once the tunnel is established. If the vendor’s own device is compromised, or if their credentials are stolen, an attacker inherits that same broad access to OT systems.
Scenario 3: ransomware crosses the IT-OT boundary. Ransomware spreads through lateral movement across east-west traffic. When IT and OT share network segments or trust relationships, encryption routines that started in the finance department can reach SCADA servers and historian databases. The 2024 attack on German electronics manufacturer Medion AG demonstrated exactly this pattern, with BlackBasta ransomware causing prolonged operational disruption.
ENISA data from 2025 shows that OT-related threats now account for 18.2% of all identified cyber threat categories in the EU. Ransomware remains the dominant method, responsible for over 81% of incidents targeting EU organisations. The average time from initial compromise to ransomware deployment is just 16 hours, which is far too short for manual detection and response in most mid-market teams.
Why firewalls and VLANs are not enough
Most organisations try to manage IT-OT boundaries with familiar tools. Each has limitations that matter in production environments.
Firewall DMZs between IT and OT add a layer of control, but configuring firewall rules for thousands of industrial protocol flows is complex and error-prone. Firewalls also cannot stop threats that are already inside the OT segment. The traditional Purdue model placed firewalls between hierarchical levels, but convergence has flattened those levels. Data now flows directly from Level 0 sensors to Level 5 cloud platforms, bypassing the layered defences the Purdue model assumed.
VLAN segmentation provides logical separation but relies on correct configuration. VLANs do not authenticate devices or users. A misconfigured switch port or a rogue device on the right VLAN bypasses the entire control. As outlined in our guide to network segmentation in 2026, VLAN-based approaches struggle with the dynamic, identity-driven access patterns that modern environments demand.
Jump servers are a common workaround for remote OT access. In practice, they become bottlenecks and targets. Staff bypass them when they slow down urgent maintenance tasks. Attackers target them because a single compromised jump server provides access to everything behind it.
| Approach | Strength | Limitation in OT |
|---|---|---|
| Firewall DMZ | Familiar, well-understood | Complex rule management, no in-segment protection |
| VLAN segmentation | Low cost, uses existing switches | No authentication, configuration drift risk |
| Jump servers | Centralised access point | Single point of failure, often bypassed |
| Traditional VPN | Encrypted tunnel | Broad access once connected, no per-app control |
Standards like IEC 62443 recommend dividing OT environments into zones and conduits, where each zone groups assets with similar security requirements and conduits control communication between zones. For mid-market organisations without dedicated OT security teams, implementing this architecture with traditional firewalls and VLANs alone is often too costly and complex to maintain.
How inline isolation bridges the IT-OT gap
The core problem is straightforward. OT devices cannot run security agents. They cannot authenticate using modern protocols. They cannot be patched on a regular schedule. Yet they need to communicate with specific IT systems to deliver business value.
Inline isolation solves this by placing enforcement at the network level, physically between the device and the rest of the network. Jimber’s Network Isolation Access Controller (NIAC) hardware sits inline with agentless devices and enforces per-device communication policies without touching the device itself.
How NIAC works in practice. The hardware appliance is deployed between an OT device (a PLC, HMI, sensor or industrial controller) and the network switch. It inspects and controls all traffic passing through it based on explicit allow rules. A PLC that needs to communicate with a specific MES server gets a policy allowing exactly that path. All other communication is blocked by default.
This approach delivers three things that traditional tools cannot.
Per-device policy enforcement. Each agentless device gets its own communication rules. A compromised sensor cannot reach anything beyond its defined path. Lateral movement hits a dead end at every device boundary.
Protocol support beyond HTTP. Many ZTNA solutions only handle TCP/HTTP traffic. OT environments rely on protocols like Modbus, BACnet, EtherNet/IP and PROFINET, which often use UDP or non-standard TCP flows. Jimber’s NIAC handles both TCP and UDP traffic, making it compatible with the protocol reality of factory networks.
Zero production disruption. No software is installed on the OT device. No firmware changes. No restarts. The NIAC operates transparently, enforcing policy without altering the device’s behaviour or availability. For environments where even a brief restart means lost production, this is not a convenience but a requirement.
Because NIAC is managed through the same Jimber console that handles ZTNA, SWG and SD-WAN policies, IT teams get a single view of both IT and OT security. There is no separate OT security tool to learn, no additional console to monitor.
Connecting factory networks step by step
Moving from an unprotected IT-OT boundary to Zero Trust enforcement does not require a multi-year project. Jimber’s platform supports a phased approach that starts delivering value in the first week.
Step 1: inventory all OT assets
You cannot protect what you do not know about. Map every device on the OT network: PLCs, HMIs, sensors, historians, engineering workstations. Record firmware versions, communication patterns and business criticality. This inventory becomes the foundation for policy decisions and also satisfies NIS2 asset management requirements.
Step 2: define communication paths
For each OT device, document exactly which systems it needs to reach. A PLC might need to talk to one MES server and one engineering workstation. A historian might need to receive data from 50 sensors and send reports to one BI platform. Strip away every communication path that is not strictly required. This is the least-privilege principle applied at the network level, aligned with the five Zero Trust principles that should guide every access decision.
Step 3: deploy inline isolation for critical devices
Start with the highest-risk devices: those controlling physical processes, handling sensitive data or facing the most exposure. Deploy NIAC hardware inline and configure the allow rules defined in step 2. Run in monitor mode first to validate that legitimate traffic flows correctly before switching to enforcement mode.
Step 4: integrate with ZTNA policies for human access
Vendor and maintenance access to OT systems should flow through Jimber’s ZTNA rather than traditional VPNs. Each technician gets identity-based, time-limited access to specific devices. Device posture checks for NIS2 ensure that only compliant endpoints can initiate connections. No more broad VPN tunnels that expose the entire OT segment.
Step 5: monitor, report and refine
With both NIAC and ZTNA active, all access to OT devices flows through policy-controlled channels. The Jimber console provides centralised logging of who accessed what, when and from which device. This audit trail directly supports NIS2 incident reporting obligations and CyberFundamentals (CyFun) documentation requirements. Review policies quarterly, add new devices as they come online, and tighten rules as you build confidence.
For a deeper look at how these principles apply to specific manufacturing environments, see our guide to SASE for manufacturing.
Frequently asked questions about IT-OT convergence
What is the difference between IT security and OT security?
IT security protects data confidentiality, integrity and availability across business systems like email, ERP and cloud applications. OT security protects the physical processes controlled by PLCs, HMIs and SCADA systems, where availability and safety take priority over confidentiality. The convergence challenge is that IT tools assume you can install agents and patch regularly, which OT environments often cannot support.
Can you apply Zero Trust to devices that do not support modern authentication?
Yes. Hardware-based inline isolation enforces Zero Trust at the network level without requiring the device itself to support authentication, encryption or agent software. The NIAC appliance acts as a policy enforcement point between the device and the network, controlling all communication based on explicit allow rules.
Does NIS2 apply to manufacturing organisations?
NIS2 covers a broad range of sectors including manufacturing of chemicals, food, medical devices, electrical equipment and other critical products. Organisations classified as “important” or “essential” entities must implement risk-based security measures, which includes network segmentation, access control and incident reporting. In Belgium, the CyberFundamentals framework provides a structured path to NIS2 compliance.
How does inline isolation differ from a traditional firewall?
A firewall typically sits at the boundary between network zones and applies rules to traffic crossing that boundary. Inline isolation operates at the individual device level, controlling exactly which communication paths each device can use. This provides microsegmentation granularity without the complexity of managing thousands of firewall rules across multiple zones.
What is the Purdue model and is it still relevant?
The Purdue model is a reference architecture that organises industrial automation into hierarchical levels, from physical processes (Level 0) through control systems (Levels 1-2), operations (Level 3) and business networks (Levels 4-5). The model remains a useful conceptual framework, but IT-OT convergence has eroded its strict layer separation. Modern approaches supplement the Purdue structure with Zero Trust architecture principles that verify every connection regardless of network level.
Can IT-OT convergence be done without production downtime?
Yes, when the security layer is applied at the network level rather than on devices themselves. Inline isolation hardware like NIAC is deployed between the device and the switch without altering the device configuration. Policies can be tested in monitor mode before enforcement. This approach protects production continuity while building security incrementally.
Ready to bridge the gap between your IT and OT networks without putting production at risk? Book a demo to see how Jimber’s NIAC hardware and unified SASE platform give you Zero Trust enforcement for every device on the factory floor, managed from one console.
