The IT/OT gap is not a technology problem waiting for a better technology. It is a governance and architecture problem that manufacturing leadership needs to own, with appropriate technical support, before the cost of inaction makes the decision for them.
Why Manufacturing IT and OT Still Don't Talk to Each Other — And What It's Costing Your Production Floor
Adam Peterson, Co-Founder & Chief Technology Officer, | Real IT Solutions
I've spent the better part of two decades inside manufacturing environments — on the floor, in the server room, and in the conversations that happen when a line goes down and nobody can agree whose problem it is. That last part is the one that costs manufacturers the most money, and it almost always comes back to the same structural failure: IT and OT weren't designed to coexist, and most manufacturers haven't done the hard work of making them do it anyway.
The gap between information technology and operational technology isn't a new problem. But it's becoming a more expensive one as manufacturers push toward smarter factories, real-time production visibility, and AI-driven process optimization. Every one of those initiatives depends on data flowing reliably between the production floor and the enterprise network. When IT and OT aren't integrated — when they're running on separate infrastructure, managed by separate teams, with separate security postures and separate change management processes — that data either doesn't flow at all, or it flows in ways nobody fully controls.
This article is about what that gap actually looks like in practice, why it persists despite years of Industry 4.0 conversation, and what closing it requires from an infrastructure and governance standpoint.
The structural origin of the IT/OT divide
To understand why IT and OT don't talk, you have to understand that they were never supposed to. They evolved under completely different engineering philosophies, for completely different purposes, with completely different priorities.
IT infrastructure — servers, networks, endpoints, enterprise applications — was built around the priorities of data integrity, confidentiality, and availability, roughly in that order. The security model assumes that systems will be patched regularly, that endpoints will be replaced on a 3-5 year cycle, and that downtime for maintenance is acceptable if scheduled correctly.
OT infrastructure — PLCs, SCADA systems, HMIs, industrial control systems, MES platforms — was built around one non-negotiable priority: continuous operation. A PLC controlling a stamping press or a SCADA system managing a chemical process cannot go offline for a patch window. The security model was historically simple because OT systems were air-gapped: physically isolated from corporate networks, connected to nothing outside the production environment, and therefore assumed to be inherently secure by isolation.
That assumption died a slow death starting around 2010, and it was killed definitively by Stuxnet. But the infrastructure those assumptions produced is still running in manufacturing plants everywhere. Equipment on production floors routinely runs Windows XP, Windows 7, or embedded operating systems that haven't received a security patch since the Obama administration. That equipment isn't there because manufacturers are negligent — it's there because replacing it means downtime, retooling, revalidation, and capital expenditure that competes with every other investment priority the business has.
Meanwhile, the same manufacturers have spent the last decade connecting those production environments to corporate networks, cloud platforms, and external vendor systems — because ERP integration requires it, remote monitoring requires it, and the business intelligence initiatives that leadership keeps funding require it. The air gap is gone. The security model that depended on it hasn't been replaced with anything adequate.
What the gap looks like from the inside
In practice, the IT/OT divide manifests in several distinct failure patterns that I see repeatedly across manufacturing environments:
Ownership ambiguity at the network boundary
The most common symptom is a conversation that goes something like this: the plant floor has a connectivity problem. The OT team says it's a network issue and calls IT. IT remotes in, checks the switches and firewall, finds nothing wrong on their side, and closes the ticket. The problem persists. The OT team escalates. IT re-opens the ticket, looks again, and determines the issue is with a piece of production equipment — not the network. The ticket goes back to OT, or to the equipment vendor, or to nobody in particular.
This loop happens because the demarcation between IT responsibility and OT responsibility is almost never clearly defined. Most manufacturers have an informal understanding that IT owns "the network" and OT owns "the machines," but the actual boundary — where does the managed network end and the unmanaged production environment begin? — is fuzzy, undocumented, and contested in real time whenever something breaks.
Incompatible change management processes
IT environments operate under change management frameworks — change requests, approval workflows, maintenance windows, rollback procedures. OT environments operate under production schedules. These two systems are fundamentally incompatible, and the incompatibility creates real risk.
When a vulnerability is discovered in a piece of OT software, IT wants to patch it according to standard patch management protocol. OT says patching requires a full production shutdown, scheduled weeks in advance, with revalidation afterward — and the next available window is six weeks out. So the vulnerability sits unpatched for six weeks while the production environment remains connected to the corporate network. That is not a theoretical risk. That is the actual operating condition of a significant percentage of manufacturing environments today.
Unmanaged network segments with production-critical systems
When I conduct infrastructure assessments in manufacturing environments, one of the most consistent findings is a population of devices on the production network that nobody in IT knows about. Not because IT is careless — because nobody told them. A machine vendor installed a remote access appliance during commissioning three years ago. A process engineer set up a data historian on an old workstation under their desk. A SCADA system has a cellular modem for vendor support access that was provisioned without IT's involvement.
These are not edge cases. In the infrastructure assessments I've conducted across manufacturing environments, undocumented or unmanaged devices on production network segments are almost never the exception — they consistently represent a meaningful share of the total device population, often surprising both IT and OT teams when the inventory is done properly. Each one is a potential attack vector, a potential source of unplanned downtime, and a gap in the visibility that any serious security or operational monitoring program depends on.
Data that exists but can't be used
Modern production equipment generates enormous volumes of operational data — cycle times, quality measurements, energy consumption, maintenance indicators, process parameters. Most of it goes nowhere useful. It sits in proprietary data formats inside the PLC or SCADA system, inaccessible to the ERP, invisible to the business intelligence platform, and unavailable to the predictive maintenance initiative that corporate just funded.
This is the gap that Industry 4.0 initiatives consistently underestimate. The data exists. The problem is connectivity, protocol translation, data normalization, and the integration layer that turns raw OT data into something an enterprise system can consume. Building that layer requires coordinated work between IT and OT teams that, in practice, rarely happens smoothly because the teams have different vocabularies, different toolsets, and different definitions of what "working" means.
The security dimension manufacturers can't afford to ignore
The convergence of IT and OT networks has created an attack surface that the manufacturing sector has been dangerously slow to address. The numbers are not ambiguous:
| Metric | Data Point | Source |
|---|---|---|
| Manufacturing sector ransomware attacks | #1 most targeted industry globally for 3 consecutive years | IBM X-Force Threat Intelligence Index 2024 |
| Average cost of OT-impacting cyberattack | $3M+ in production losses alone, excluding recovery costs | Claroty/Ponemon Institute 2023 |
| OT environments with known unpatched critical vulnerabilities | 83% of industrial sites | Claroty State of CPS Security 2024 |
| Manufacturers with no OT-specific security controls | Approximately 65% of SMB manufacturers | CISA Industrial Control Systems Advisory data |
| Average dwell time before OT breach detection | 200+ days | Dragos Year in Review 2023 |
The attack pattern that hits manufacturers hardest is not a direct assault on OT systems — it's lateral movement. An attacker gains initial access through IT infrastructure (phishing, a compromised vendor credential, an unpatched internet-facing system), establishes persistence, and then moves laterally across the network until they reach OT systems. Once there, they have two options: exfiltrate data, or detonate ransomware timed to cause maximum production disruption.
The defense against this pattern is network segmentation — placing IT and OT on separate network segments with controlled, monitored, and strictly limited connectivity between them. This is not a novel concept. NIST SP 800-82, the ICS security guide that has been publicly available since 2011, describes it clearly. The problem is implementation: proper network segmentation in a brownfield manufacturing environment requires mapping every device, every communication path, and every data flow across production — work that requires coordinated effort between IT and OT and typically takes weeks to months to execute correctly.
For manufacturers with Department of Defense contracts, this isn't optional. CMMC 2.0 (Cybersecurity Maturity Model Certification) requires documented network segmentation, access controls, and audit logging that span both IT and OT environments. Non-compliance means loss of contract eligibility. The assessment process will expose exactly the undocumented devices and uncontrolled network segments described above.
What closing the gap actually requires
IT/OT convergence is not a technology project. It is an organizational and governance project that also happens to involve technology. The organizations that get it right do four things consistently:
1. Conduct a unified network and asset inventory
You cannot manage, secure, or optimize what you cannot see. The starting point for any serious convergence initiative is a complete, validated inventory of every device on every network segment — IT and OT — with documentation of what each device is, what it communicates with, what protocols it uses, and who is responsible for it.
This sounds straightforward. It isn't. OT environments often span multiple facilities, legacy equipment with no documentation, devices that can't be actively scanned without disrupting operation, and vendor-managed systems with restricted access. Passive network monitoring tools (Claroty, Dragos, Nozomi Networks) can discover and classify OT assets without disrupting production — but deploying them requires IT network access that OT teams are often reluctant to grant without understanding why.
The inventory is not a one-time exercise. It requires a maintenance process — a way to ensure that when new equipment is commissioned, a remote access appliance is installed, or a vendor connects a support device, that device gets documented and assessed before it becomes part of the permanent undocumented population.
2. Define and implement network segmentation with a defendable DMZ
The architecture goal is a Purdue Model-informed segmentation: enterprise IT on Level 4/5, a demilitarized zone (DMZ) at Level 3.5 where data exchange between IT and OT occurs under controlled conditions, and OT systems on Levels 0-3 with no direct connectivity to enterprise networks or the internet.
In practice, implementing this in a brownfield environment means identifying every current connection that violates this model — and there will be many — and either eliminating them, replacing them with controlled data exchange through the DMZ, or documenting them as accepted risk with compensating controls. Each decision requires input from both IT and OT, which is why governance matters more than technology here.
The DMZ architecture requires specific technical components: data diodes or unidirectional gateways for connections where data should only flow one direction (from OT to IT, not the reverse), jump servers for any administrative access to OT systems from enterprise networks, and protocol-aware firewalls that understand industrial communication protocols (Modbus, DNP3, EtherNet/IP, PROFINET) rather than treating all traffic as generic TCP/IP.
3. Build a unified patch and vulnerability management process
The standard IT patch management process does not work in OT environments without modification. The modification isn't "patch OT systems on a slower schedule" — it's building a process that accounts for the operational constraints of production systems from the beginning.
This means coordinating with equipment vendors on patch testing and compatibility validation before deployment. It means scheduling OT patching against production calendars rather than against arbitrary IT maintenance windows. It means accepting that some systems cannot be patched — end-of-life equipment running processes that can't be interrupted — and compensating with network isolation, enhanced monitoring, and an explicit risk acceptance process that documents who owns the decision.
Where patching isn't possible, virtual patching through IDS/IPS systems positioned at the network boundary can block known exploit traffic targeting unpatched vulnerabilities without touching the system itself. This is not a permanent solution — it's a risk reduction measure that buys time for a proper remediation plan.
4. Establish a converged IT/OT governance structure
The technical work fails without organizational alignment. Someone needs to own the boundary between IT and OT — not as a territory to defend, but as a shared responsibility to manage. In larger organizations, this is typically a dedicated OT security function or a plant IT role with explicit authority across both domains. In smaller and mid-sized manufacturers, it often requires an external partner who can provide the cross-domain expertise that neither IT nor OT has internally.
The governance structure needs to address at minimum: who approves new OT network connections, who owns the asset inventory and keeps it current, how changes to production network segments are reviewed and approved, how incidents that cross the IT/OT boundary are escalated and managed, and how compliance requirements (CMMC, NIST SP 800-171, DFARS if applicable) are tracked and evidenced across both domains.
The cost of delay is not hypothetical
I've worked through more than 100 manufacturing server migrations and infrastructure projects across a range of facility sizes and production environments. The pattern I see in organizations that have deferred IT/OT convergence is consistent: the cost of addressing it reactively — after a breach, after a compliance audit failure, after a production outage traced to an undocumented network segment — is between three and ten times the cost of addressing it proactively.
The proactive work is hard. It requires organizational alignment that doesn't come naturally, investment in cross-domain expertise that most manufacturers don't have in-house, and a willingness to disrupt production environments that plant managers are understandably reluctant to touch. But the math is not complicated. An unplanned production shutdown in a mid-sized manufacturing facility typically costs $50,000 to $500,000 per day depending on the operation. A ransomware event that hits OT infrastructure — and they are hitting OT infrastructure at increasing frequency — can take days or weeks to recover from fully.
The IT/OT gap is not a technology problem waiting for a better technology. It is a governance and architecture problem that manufacturing leadership needs to own, with appropriate technical support, before the cost of inaction makes the decision for them.
Adam Peterson is Co-Founder and Chief Technology Officer at Real IT Solutions, a managed IT and technology advisory firm serving manufacturers and SMBs across West Michigan. He has led more than 100 manufacturing server migrations and infrastructure projects and specializes in IT/OT convergence, network architecture, and infrastructure modernization for production environments. Real IT Solutions is headquartered in Grand Rapids, Michigan.
The content & opinions in this article are the author’s and do not necessarily represent the views of ManufacturingTomorrow
Real IT Solutions
Real IT Solutions provides fully managed IT services that function as an outsourced IT department for growing businesses. This includes 24/7 system monitoring, help desk support, network management, and ongoing technology optimization. The company emphasizes proactive maintenance and strategic oversight to prevent issues before they disrupt operations, ensuring consistent performance and reliability across client environments.
More about Real IT Solutions
Featured Product
