A contrarian position paper arguing that the dominant narrative of OT/IT convergence commits a category error. Operational technology and information technology should share toolchains, practices, and personnel — but their architectural distinction reflects fundamental differences in physics, failure modes, and trust boundaries that no amount of tooling can dissolve. The right model is asymmetric: architectural distinction with operational unification, mediated by a deliberate demarcation layer.
Preamble
A particular phrase has acquired the status of an industrial axiom over the past decade: OT/IT convergence. It appears in vendor white papers, in strategic consulting frameworks, in industrial conference keynotes, and in the slide decks that justify multi-million-dollar transformation programs. The phrase suggests that the historical separation between operational technology — the control systems that move physical matter — and information technology — the systems that move information about matter — was a transient condition produced by accidents of organizational history, and that mature engineering practice will dissolve the distinction.
This paper argues that the convergence narrative, taken in its dominant form, is wrong. Not partially wrong, not occasionally wrong, but structurally wrong in a way that produces architectural failures when treated as a design principle.
The argument is not, however, a defense of the older narrative — the air gap doctrine, the Purdue model fundamentalism, the position that OT and IT belong to incommensurable engineering traditions that must be kept rigorously separate. That older narrative has also failed, for reasons this paper will examine. Modern industrial systems cannot operate as if the IT and OT domains were sealed from each other; the operational realities of supply chain security, observability, software lifecycle, and personnel deployment require a level of unification that the older narrative denies.
The correct position is more nuanced than either extreme. It is that OT and IT differ at the architectural level — in their optimization targets, trust models, failure semantics, time scales, and reversibility properties — and that these differences are not artifacts of organizational history but reflections of physical and operational facts that no engineering choice can dissolve. They should remain architecturally distinct. At the same time, the operational practices that surround them — version control, supply chain security, observability, deployment automation, personnel development — should be unified. The locus of this unification is the demarcation layer between the two domains: in industrial terms, the gateway.
The position can be stated compactly: architectural distinction, operational unification. This paper develops the argument over eight sections. The first characterizes the convergence narrative and identifies what is correct in it. The second establishes the architectural properties that distinguish OT from IT and argues that these properties are essential, not accidental. The third diagnoses the conceptual error in the convergence narrative as a category error. The fourth examines historical analogies — convergence narratives in other domains — and the pattern by which they have failed. The fifth confronts the strongest counter-arguments. The sixth describes the right architectural model and the role of the demarcation layer. The seventh discusses implications for engineering practice. The eighth restates and defends the thesis.
The intended audience is the architect, engineering leader, or technical strategist who is being asked to commit an industrial organization to a convergence program and who senses that the program is not quite right but cannot articulate why.
The Convergence Narrative
A clean argument requires a clean characterization of the position being opposed. The convergence narrative, in its dominant form, holds the following:
The historical separation between OT and IT was produced by organizational accidents — distinct vendor ecosystems, distinct engineering traditions, distinct procurement processes — rather than by underlying technical necessity.
As OT systems adopt standard protocols (TCP/IP, OPC UA, MQTT), standard operating systems (Linux, in various real-time and embedded variants), and standard hardware (x86 and ARM rather than proprietary controllers), the technical basis for the distinction erodes.
Cloud-native operational practices — continuous integration, observability, infrastructure-as-code, container orchestration — apply equally well to OT and IT workloads.
The mature endpoint of this trajectory is a unified architecture in which OT workloads run on the same infrastructure, are managed by the same tools, and are operated by the same personnel as IT workloads. The distinction between the two becomes a historical curiosity.
Several elements of this narrative are correct, and the position advanced in this paper concedes them explicitly.
It is correct that standard protocols have largely replaced proprietary ones at the upper layers of industrial communication. OPC UA [1] has become the de facto interoperability protocol for plant-floor data, displacing dozens of proprietary equivalents. MQTT [2] dominates north-bound telemetry. TCP/IP is universal. The protocol surface that distinguished OT from IT a generation ago has substantially dissolved.
It is correct that operational practices originally developed for cloud-native applications apply to OT workloads with productive results. Container orchestration [3], GitOps configuration management, OpenTelemetry-based observability [4], and supply chain security frameworks such as SLSA [5] and Sigstore [6] are not merely transferable to industrial deployments — they are improvements over the operational practices that preceded them.
It is correct that personnel mobility between OT and IT is increasing and that this is healthy. The historical isolation of OT engineering from broader software practice produced documented deficits in security posture, code quality, and operational maturity. The exchange of personnel and practices between the domains has reduced these deficits.
Where the convergence narrative goes wrong is in its conclusion. From the correct premises that protocols have converged, practices should converge, and personnel should mix, the narrative draws the incorrect inference that architectures should also converge. This inference does not follow. The architectural distinction between OT and IT does not reduce to the protocol distinction or to the practice distinction; it reflects properties that survive the convergence of protocols and practices because they are not protocol-level or practice-level properties.
The next section establishes what these properties are.
Convergence pressure versus architectural separability
bar chartThe Architectural Properties That Must Remain Distinct
What distinguishes OT from IT, at the level of architecture, is not a list of technologies but a set of structural properties that hold regardless of which technologies happen to implement them. Seven such properties warrant explicit examination.
2.1 Time as a First-Class Architectural Concern
In IT systems, time is, with rare exceptions, a soft constraint. A web request that takes 200 ms is acceptable; one that takes 2 s is degraded but functional; one that takes 20 s is broken but typically not catastrophic. The system is designed against statistical service-level objectives — the 99th percentile latency, the 99.9th percentile latency — and graceful degradation under load is a virtue.
In OT systems, time is a hard constraint. A motion control loop that misses its 1 ms deadline does not produce a degraded outcome; it produces a wrong outcome, possibly an unsafe outcome. The system is designed against worst-case execution time, not statistical distributions. Graceful degradation is not a virtue but a hazard, because the physical system being controlled does not gracefully degrade — it continues to operate, and the absence of correct control input does not produce a slow response but an incorrect response.
Edward A. Lee at Berkeley has argued, across two decades of papers on cyber-physical systems [7][8], that this difference is not a quantitative difference in latency requirements but a qualitative difference in how time enters the architecture. In IT systems, time is a performance property. In OT systems, time is a correctness property. The implications of this distinction reach into the design of programming languages, schedulers, communication protocols, and verification techniques. They cannot be papered over by treating an OT workload as a "low-latency IT workload."
The convergence narrative consistently treats latency as a quantitative property that more powerful hardware and better networks will solve. The PhD-level diagnosis is that latency is a symptom; the underlying property is determinism, and determinism is qualitatively different from low latency.
2.2 Failure Modes and the Asymmetry of Consequence
When an IT system fails, the failure mode is typically the loss of information availability or integrity. The consequences are economic — service downtime, transactional loss, reputational harm — and are, in the overwhelming majority of cases, reversible. Lost transactions can be replayed. Corrupted data can be restored from backup. Failed deployments can be rolled back.
When an OT system fails, the failure mode is typically the loss of physical control. The consequences include possible damage to equipment, environment, or human life, and are, in many cases, irreversible. A controller that releases the wrong chemical, opens the wrong valve, or commands the wrong motor trajectory produces a physical effect that cannot be rolled back by reverting a configuration.
This asymmetry of consequence has architectural implications that no amount of operational tooling can dissolve. The verification regime that an OT system must satisfy before deployment is qualitatively different from the verification regime that an IT system must satisfy. The change management process is different. The trust model is different. The acceptable failure modes — fail-safe, fail-secure, fail-operational — have no clean IT analogs because IT systems generally have only one fail mode, which is fail-unavailable, and unavailability is rarely a safety condition.
The convergence narrative treats this asymmetry as a tooling problem — better testing, better observability, better rollback. The PhD-level diagnosis is that the asymmetry is structural and cannot be erased by tooling. A system whose failure can release radioactive material, harm a worker, or contaminate a watershed is not a more critical version of a system whose failure can lose a transaction; it is a different category of system, requiring different architectural primitives.
2.3 Trust Models: Zone-Based versus Identity-Based
Modern IT security architectures have largely converged on identity-based trust. The Zero Trust paradigm [9] holds that no implicit trust should be granted based on network position; every request should be authenticated and authorized based on the identity of its originator. This model is appropriate for IT systems, where requests are typically generated by identifiable human users or service accounts, and where the cost of authentication overhead is bearable.
OT systems do not, in general, fit this model. The originators of OT traffic are typically processes — controllers, drives, sensors — without natural identities in the IT sense. The protocols they use were not designed for authentication. The latency budgets they operate under typically cannot accommodate the cryptographic overhead of per-message authentication. The trust model that emerged in OT, codified in the Purdue Enterprise Reference Architecture [10] and refined in IEC 62443 [11], is zone-based: trust is granted based on the network zone in which a device resides, and the boundaries between zones are enforced by conduits whose protocols and access are explicitly defined.
The convergence narrative tends to treat zone-based trust as a primitive form of identity-based trust, awaiting upgrade. The PhD-level diagnosis is that zone-based trust is not primitive; it is appropriate for the kinds of systems it governs. Identity-based trust requires identity, and the entities at the lowest levels of an industrial system — a temperature transmitter, a proximity switch, a solenoid — do not have natural identities. Forcing them into an identity-based model produces ceremony without security; the certificate provisioning, the rotation, the revocation become administrative overhead without corresponding gains in trust.
The mature architecture combines both models: identity-based trust above the demarcation layer (IT side), zone-based trust below it (OT side), and explicit gating at the boundary. This is the model that IEC 62443 already encodes, and the convergence narrative's pressure to abandon it in favor of universal identity-based trust represents an architectural regression.
2.4 Lifecycle Asymmetry
A typical IT system has a lifecycle measured in years — three to five for hardware, months to a year for major software versions, weeks to months for security patches. The lifecycle assumes continuous engagement with the system: it will be updated frequently, replaced regularly, and decommissioned within a planning horizon.
A typical OT system has a lifecycle measured in decades. An industrial controller deployed in 2005 may still be operational in 2035. The hardware, the firmware, the configuration, and the documentation must all be supportable across this horizon. The economic logic of industrial equipment depreciation, the regulatory logic of process safety, and the operational logic of plant availability all push in the direction of long service life.
This asymmetry has architectural implications that are easy to underestimate. Software dependencies that are acceptable in IT — relying on cloud services that may be deprecated, on libraries whose maintenance status may change, on protocols whose specifications may evolve — are unacceptable in OT, because the time horizon over which the OT system must function exceeds the maintenance horizon of the dependencies. The architectural response is to minimize external dependencies, prefer protocols with long-stable specifications, and design for offline operation with bounded reliance on remote services.
The convergence narrative tends to discount this asymmetry by assuming that lifecycles will themselves converge — that OT systems will adopt IT-typical lifecycles. The PhD-level diagnosis is that they cannot, because the lifecycles are not engineering choices but reflections of capital depreciation schedules, regulatory regimes, and operational continuity requirements that are not subject to engineering preference.
2.5 Reversibility
The reversibility property differs between OT and IT in a way that connects to the failure mode asymmetry but is logically distinct. In IT, most actions are reversible — a configuration change can be reverted, a deployment can be rolled back, a transaction can be voided. The architectural pattern of atomic deployment with automated rollback, central to modern cloud-native practice, depends on reversibility.
In OT, many actions are irreversible at the system level. A motor that has rotated to a new position cannot un-rotate to undo the rotation; the new position is the system state. A chemical that has been added to a process cannot be un-added. A weld that has been made cannot be un-welded. The control system can reverse its commands, but the physical effects of past commands persist.
This asymmetry has direct architectural implications. The IT-typical deployment model — deploy, observe, roll back if needed — does not map onto OT. An OT change that produces unintended physical effects cannot be remediated by reverting the change. The architectural response is to invest in verification before deployment, rather than rolling back after deployment. Hardware-in-the-loop simulation, formal verification of safety properties, and staged deployment with explicit physical validation are OT-specific practices that have no direct IT analog.
The convergence narrative imports the IT model of observe and roll back into OT contexts where it is structurally inapplicable. This is not a matter of operational maturity — it is a matter of physical reality.
2.6 Determinism versus Statistical Performance
IT systems are typically optimized against statistical performance metrics — median throughput, tail latency, error rates at percentiles. The mathematical machinery of queueing theory, the architectural patterns of load shedding and graceful degradation, and the operational practice of service-level objectives all presume that performance is best characterized statistically.
OT systems are typically optimized against deterministic performance metrics — worst-case execution time, hard real-time guarantees, bounded jitter. The mathematical machinery of schedulability analysis, the architectural patterns of fixed-priority scheduling and deadline-driven design, and the operational practice of certified worst-case behavior all presume that performance must be characterized deterministically.
This is not the same property as the time-as-correctness property of Section 2.1; it is a related but distinct architectural property. A system can have hard real-time deadlines (Section 2.1) and also be characterized statistically — the determinism property (this section) requires that the architecture itself rule out statistical variation in the relevant dimensions. The end-to-end argument applied to time — the position that time guarantees cannot be reliably synthesized from non-time-guaranteeing primitives — implies that determinism must be designed in from the bottom of the stack, not added at the top.
The convergence narrative tends to treat determinism as a special case of low latency, addressable by better hardware and tighter SLOs. The PhD-level diagnosis is that determinism is not a quantitative extension of low latency but a qualitative architectural property requiring different design primitives.
2.7 Blast Radius and Containment
The blast radius of a failure in an IT system is typically bounded by the system itself. A failure in a payment service produces failed payments; a failure in a search service produces failed searches. The physical world is unaffected; the harm is confined to the information domain.
The blast radius of a failure in an OT system extends into the physical world by design. A failure in a power grid control system produces blackouts. A failure in a water treatment control system produces contaminated water. A failure in a transportation control system produces collisions. The blast radius is determined by the physical system under control, not by the control system itself.
This asymmetry has implications for the architectural design of trust boundaries, segmentation, and containment. An OT system must be designed against the assumption that its failure will produce physical consequences, and the architecture must be structured to bound those consequences — through interlock systems, safety-instrumented functions, physical isolation, and the like. The IT-typical architecture, which does not provide for physical containment because IT failures do not require it, is structurally inadequate when imported into OT.
The Conceptual Error: A Category Mistake
The diagnosis of the convergence narrative as wrong does not yet identify what kind of error it makes. Several diagnoses are possible — the narrative could be empirically mistaken, technically misinformed, or culturally biased. The diagnosis advanced here is that it commits a category error in the sense of Gilbert Ryle [12]: it treats two things as members of the same category that, in fact, belong to different categories, and the inferences drawn from this treatment are systematically wrong.
The category error is to treat a control system as a service.
A service, in the IT sense, is a software artifact that accepts requests, produces responses, and is characterized by its functional contract, performance properties, and availability. Services compose via APIs. They scale horizontally. They are operated against service-level objectives. The architectural patterns of service-oriented design — loose coupling, statelessness, idempotency, asynchronous messaging — are appropriate for services.
A control system, in the OT sense, is a software artifact that participates in a feedback loop with a physical process. It does not accept requests in the IT sense; it observes physical state and produces control outputs. It is characterized not by a functional contract but by a control-theoretic specification: stability margins, disturbance rejection, tracking accuracy, response time. It does not scale horizontally — there is one physical process to control. It is operated not against availability SLOs but against safety and reliability requirements derived from the physical hazards of the process.
When the convergence narrative treats a control system as a service, it imports architectural patterns that are appropriate for services and applies them to systems that are not services. The patterns fail not because they are badly implemented but because they are categorically misapplied. Stateless control is incoherent — control fundamentally requires state. Idempotent commands to a physical actuator are incoherent — an actuator's state evolves with each command, regardless of the command's IT-level identity. Service composition does not capture the structure of a control system, which is determined by physics rather than by API contracts.
The category error explains why convergence-driven architectures so often produce systems that work in development and fail in production. The developer environment, where the controlled physical process is absent or simulated, does not exhibit the properties that distinguish control from service; the production environment, where the physical process is present and consequential, exhibits these properties in full force.
The error is reversible, but only by recognizing that OT and IT are different categories and designing accordingly.
Historical Analogies: When Convergence Narratives Fail
The OT/IT convergence narrative is not unique. It belongs to a family of convergence narratives that have appeared, with varying degrees of confidence, across several decades of computing history. Examining the family helps clarify both why the narratives are persistently attractive and why they persistently fail.
The "all systems become distributed" narrative, prominent in the 1990s, held that the success of distributed systems would render centralized systems obsolete. The narrative predicted that distributed databases, distributed file systems, and distributed computation would displace their centralized predecessors. The empirical record is mixed. Some workloads did distribute; others remained obstinately centralized because centralization was, for those workloads, the right architectural choice. The CAP theorem [13] provided the formal account: distribution and consistency are not freely composable, and workloads requiring strong consistency under failure remain centralized for reasons that engineering preference cannot change.
The "all software becomes web" narrative, prominent in the 2000s, held that native applications would be displaced by web applications. The narrative predicted that local computation would migrate to the browser, that operating system differences would become irrelevant, and that the desktop application would join the punch card in computing's prehistory. The empirical record again shows a more complex pattern. Web applications captured many workloads, but native applications persisted for workloads requiring tight hardware integration, offline operation, or rich UI capability. The convergence was partial, not total.
The "cloud will absorb everything" narrative, prominent in the 2010s, held that on-premises computing would dissolve into cloud computing. The narrative predicted that data centers would empty, that edge devices would become thin terminals, and that the cloud would emerge as the universal substrate. The empirical record again shows partial convergence followed by counter-movement. Cloud adoption is substantial, but the edge computing movement (see [14] for a survey) represents an explicit re-distribution of compute away from the cloud, driven by latency, sovereignty, and bandwidth economics that the convergence narrative did not adequately model.
A pattern emerges across these examples. Convergence narratives are systematically biased toward predicting homogenization, and they systematically underweight the forces that maintain architectural heterogeneity. The forces are not always the same, but they share a common structure: they reflect physical, economic, or operational realities that are not subject to engineering preference, and convergence narratives that ignore them produce architectures that fail when the realities reassert themselves.
The OT/IT convergence narrative fits this family. It underweights the architectural properties identified in Section 2 — properties that reflect physical and operational realities not subject to engineering preference. Its empirical trajectory is likely to follow the pattern: partial convergence in the areas where convergence is feasible (tooling, practice, personnel) followed by reassertion of distinction in the areas where convergence is infeasible (architecture, trust model, lifecycle).
Confronting the Counter-Arguments
A serious advocacy must engage with the strongest forms of the position it opposes. This section addresses four counter-arguments that convergence advocates routinely raise.
5.1 The Protocol Convergence Argument
OPC UA, MQTT, and TCP/IP have effectively unified OT and IT communication. The protocol distinction has dissolved, and the architectural distinction follows.
The argument is partially correct and importantly wrong. Protocols have indeed converged at the upper layers. But protocol convergence is not architectural convergence. OPC UA is a bridging protocol; it permits two distinct architectural domains to exchange data without merging them. The existence of a common language between two cultures does not imply that the cultures are the same. French and German speakers can both communicate in English without becoming the same culture; OT and IT systems can both communicate in OPC UA or MQTT without becoming the same architecture.
The deeper point is that the architectural distinctions identified in Section 2 — time semantics, failure modes, trust models, lifecycle, reversibility, determinism, blast radius — are not protocol-level properties. They are properties of the systems that use the protocols. Two systems that speak OPC UA can have entirely different architectural properties depending on what they do with the protocol.
5.2 The Linux Convergence Argument
Modern PLCs run Linux. Modern industrial gateways run Linux. The kernel that runs OT workloads is the same kernel that runs IT workloads. The OS distinction has dissolved, and the architectural distinction follows.
The argument observes a true premise — Linux has indeed become ubiquitous in industrial computing — and draws an incorrect conclusion. The shared kernel does not imply shared architecture, because the operational regime under which the kernel runs differs profoundly between OT and IT contexts.
An OT-configured Linux system typically runs with the PREEMPT_RT patch [15], with isolated CPU cores dedicated to real-time workloads, with non-real-time daemons disabled, with explicit cgroup-based resource isolation, and with kernel parameters tuned for determinism rather than throughput. An IT-configured Linux system runs with the stock scheduler, with all cores available to a general workload, with the full systemd service set, and with kernel parameters tuned for throughput rather than determinism. The two systems are running the same kernel source in the same sense that a Formula 1 race car and a city sedan are running the same internal combustion engine principle — true at one level of description, profoundly misleading at the level of description that matters for engineering decisions.
5.3 The Cloud-Native Argument
Container orchestration, service meshes, observability platforms, and GitOps have proven their value at hyperscaler scale. There is no reason these practices should not apply to OT. The operational distinction has dissolved, and the architectural distinction follows.
The argument's premise is correct, and the position advanced in this paper concedes it explicitly. Cloud-native operational practices do apply productively to OT. The diagnostic question is what conclusion follows.
The conclusion that follows is operational unification, not architectural convergence. The same toolchain that operates IT workloads can operate OT workloads, with appropriate configuration. The same observability platform can ingest telemetry from both domains. The same GitOps controller can manage configuration in both domains. This is what the position advanced here calls operational unification, and it is unambiguously beneficial.
What does not follow is that the architectural properties of OT workloads become those of IT workloads. A containerized OT workload still has hard real-time deadlines, irreversible failure modes, and a 20-year lifecycle. The container is a deployment vehicle, not an architectural transformation. The fact that the same toolchain operates both domains does not erase the differences between the workloads the toolchain is operating.
5.4 The Personnel Argument
OT engineers and IT engineers are learning each other's disciplines. Cross-functional teams are increasingly common. The cultural distinction is dissolving, and the architectural distinction follows.
The argument's premise is correct and welcome. The historical isolation of OT engineering from broader software practice was unhealthy in both directions. Its dissolution is a net gain.
The conclusion does not follow, however, because architectural distinctions are not cultural artifacts. A power engineer who learns Python and a backend developer who learns ladder logic both expand their range, but the systems they design must still respect the architectural properties of the domains they design for. A culturally unified team can build architecturally distinct systems; indeed, this is the right model. The culture-architecture relationship is not symmetric.
The Right Model: Architectural Distinction with Operational Unification
The position advanced here is not negative. Having argued that the convergence narrative fails, the paper must articulate the model it advocates in place of convergence. The model has three components.
First, explicit architectural demarcation between the OT and IT domains. The Purdue Enterprise Reference Architecture [10] and IEC 62443 [11] already provide the conceptual framework: zones with explicit trust boundaries, conduits with explicit protocols, and demarcation points where data flows are mediated. This framework should be preserved and modernized, not abandoned. The modernization consists of replacing the historical assumption of physical isolation with the contemporary assumption of explicit gating: data flows between zones, but it does so through deliberate, observable, and controllable conduits.
Second, asymmetric data flow across the demarcation. Telemetry flows from OT to IT in high volume; control flows from IT to OT in low volume and through carefully gated channels. The asymmetry reflects the asymmetry of consequence (Section 2.2) and reversibility (Section 2.5): a malformed telemetry packet can be safely dropped, while a malformed control command can produce irreversible physical effects. The two flows should not be implemented symmetrically; they should reflect their differing safety and trust requirements.
Third, operational unification above the demarcation layer. The toolchain that manages OT workloads — the configuration management, the deployment automation, the observability, the supply chain security — should be the same toolchain that manages IT workloads, with appropriate configuration for the domain-specific properties. This unification realizes the benefits of cloud-native operational practice without compromising the architectural distinctions that the practices do not themselves dissolve.
The natural locus of the demarcation layer, in industrial deployments, is the gateway. A previous paper in this series [14] argued that the gateway has emerged as the equilibrium point of the edge computing wave; the argument here is that the gateway is also the equilibrium point of the OT/IT architectural relationship. It is the point at which the two domains meet, where data flows are mediated, where trust boundaries are crossed under explicit control, and where the operational toolchain achieves visibility into both sides without dissolving the distinction between them.
This is not an accidental coincidence. The gateway sits at the architecturally significant location precisely because its location reflects the underlying structure of the problem: a point of mediation between two domains that share traffic but not architecture.
Implications for Practice
The position advanced here has direct implications for several categories of engineering practice.
For organizational design, the implication is that the convergence narrative's prescription — merge the OT and IT organizations — is partially correct and importantly wrong. The two organizations should share leadership, share tooling, share processes, and share personnel where the skills transfer. They should not be merged in their accountability for the architectural properties of their respective domains. The OT engineering function retains responsibility for the architectural properties of OT systems, even when the operational toolchain is unified.
For procurement, the implication is that vendor convergence — selecting a single vendor for both OT and IT infrastructure — is generally a poor choice. The vendors that excel at IT infrastructure are not, with rare exceptions, the vendors that excel at OT infrastructure. The architectural properties that matter on the OT side are not the architectural properties that the IT vendors optimize for, and vice versa. The right procurement model selects domain-appropriate vendors for each domain and invests in the demarcation layer that connects them.
For software design, the implication is that workloads that cross the OT/IT boundary should be designed with the asymmetry explicitly modeled. A workload that processes OT telemetry and exposes it to IT consumers is structurally different from a workload that accepts IT commands and translates them to OT actuation. The two should not be conflated, even if implemented in the same containerized framework.
For security architecture, the implication is that the Zero Trust model should be adopted on the IT side and the zone-based model retained on the OT side, with explicit policy at the demarcation layer translating between them. The pressure to extend Zero Trust universally into OT environments should be resisted where it produces ceremony without security gain.
For lifecycle management, the implication is that the long-lifecycle assumption of OT systems must be respected in the design of cross-domain integrations. An IT service that integrates with OT systems should be designed for the IT lifecycle on the IT side and for the OT lifecycle on the OT side, with the integration layer engineered to bridge the two. The temptation to impose the shorter IT lifecycle on the OT side, in the name of agility, produces systems that the OT environment cannot sustain.
Concluding Argument
The position may be stated compactly. The convergence narrative observes correct premises — that protocols, practices, and personnel are unifying across the OT/IT divide — and draws an incorrect conclusion, that architectures should also unify. The architectural distinction between OT and IT does not reduce to the protocol distinction or to the practice distinction; it reflects properties of physics, failure modes, trust, lifecycle, and reversibility that survive the convergence of protocols and practices because they operate at a different level. Treating a control system as a service is a category error in the sense of Ryle, and the architectural failures that result from this error are systematic.
The right model is asymmetric: architectural distinction at the levels where the distinctions are real, operational unification at the levels where unification is feasible and beneficial, and a deliberate demarcation layer at which the two domains meet. The locus of this demarcation, in industrial deployments, is the gateway. The investments that follow from this model — in domain-appropriate architectural primitives, in mediation infrastructure at the demarcation layer, in shared operational tooling above the demarcation — produce systems that are better than the systems either convergence orthodoxy or air-gap orthodoxy would produce.
The recommendation is direct. Resist the convergence narrative where it counsels architectural homogenization; embrace it where it counsels operational unification; invest in the demarcation layer where the two meet. The result is not a compromise but a stronger architecture than either pure position would yield.
The OT and IT worlds will not become one. They will, increasingly, share a toolchain, a culture, and a workforce. The remaining distinction — architectural, principled, and durable — is not a residue to be eliminated but a structure to be preserved.
References
[1] OPC Foundation. OPC Unified Architecture Specification, Parts 1-100. 2008–present.
[2] OASIS. MQTT Version 5.0. OASIS Standard, 2019. ISO/IEC 20922:2016 covers MQTT 3.1.1.
[3] B. Burns et al. "Borg, Omega, and Kubernetes." Communications of the ACM, 59(5), 2016.
[4] OpenTelemetry Project. OpenTelemetry Specification. CNCF, 2019–present.
[5] Google et al. Supply-chain Levels for Software Artifacts (SLSA). Open Source Security Foundation, 2021–present.
[6] Linux Foundation. Sigstore: Software Signing for Everybody. 2021–present.
[7] E. A. Lee. "Cyber-Physical Systems: Design Challenges." 11th IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing (ISORC), 2008.
[8] E. A. Lee. "Computing Needs Time." Communications of the ACM, 52(5), 2009.
[9] National Institute of Standards and Technology. Zero Trust Architecture. NIST Special Publication 800-207, 2020.
[10] T. J. Williams. The Purdue Enterprise Reference Architecture. Purdue Laboratory for Applied Industrial Control, 1992. ISA-95 (ANSI/ISA-95.00.01) provides the contemporary formalization.
[11] International Electrotechnical Commission. IEC 62443: Industrial Communication Networks — Network and System Security. 2009–present (multi-part standard).
[12] G. Ryle. The Concept of Mind. University of Chicago Press, 1949. (Chapter 1 introduces the category mistake.)
[13] S. Gilbert and N. Lynch. "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services." ACM SIGACT News, 33(2), 2002.
[14] Modibus Technical Series. "From Cloud to Edge: A Critical Examination of Why Computation Is Migrating to the Gateway Layer." 2026.
[15] T. Gleixner and I. Molnar. PREEMPT_RT: Real-Time Preemption Patches for the Linux Kernel. Linux Foundation, https://wiki.linuxfoundation.org/realtime/
[16] E. A. Lee and S. A. Seshia. Introduction to Embedded Systems: A Cyber-Physical Systems Approach. MIT Press, 2nd ed., 2017.
[17] J. H. Saltzer, D. P. Reed, and D. D. Clark. "End-to-End Arguments in System Design." ACM Transactions on Computer Systems, 2(4), 1984.
[18] J. H. Saltzer and M. D. Schroeder. "The Protection of Information in Computer Systems." Proceedings of the IEEE, 63(9), 1975.
[19] M. E. Conway. "How Do Committees Invent?" Datamation, 14(5), 1968. (Source of Conway's Law.)
[20] R. M. Lee, M. J. Assante, and T. Conway. Analysis of the Cyber Attack on the Ukrainian Power Grid. SANS ICS / E-ISAC, 2016.
[21] N. Falliere, L. O. Murchu, and E. Chien. W32.Stuxnet Dossier. Symantec Security Response, 2011.
[22] M. Krotofil and J. Larsen. "Rocking the Pocket Book: Hacking Chemical Plants." DEF CON 23, 2015.
[23] J. Slowik. Evolution of ICS Attacks and the Prospects for Future Disruptive Events. Dragos, 2019.
[24] E. Byres, A. Ginter, and J. Langill. How Stuxnet Spreads — A Study of Infection Paths in Best Practice Systems. Tofino Security / Abterra / SCADAhacker, 2011.
[25] N. G. Leveson. Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press, 2011. (Foundational treatment of safety as a control problem.)
[26] J. Reason. Human Error. Cambridge University Press, 1990. (Source of the "Swiss cheese" model of accident causation, relevant to OT failure analysis.)
[27] International Society of Automation. ANSI/ISA-95.00.01: Enterprise-Control System Integration — Part 1: Models and Terminology. 2010.
[28] R. Anderson. Security Engineering: A Guide to Building Dependable Distributed Systems. 3rd ed., Wiley, 2020. (Chapters on control systems security.)
[29] Modibus Technical Series. "The Case for Containers in Industry: Why Docker Is the Right Foundation for Modern Industrial Software." 2026.
[30] Modibus Technical Series. "MQTT vs OPC UA: Which Protocol for Which Data?" 2026.
This article is part of the Modibus technical series. Modibus engineers the gateway tier — the architectural demarcation layer at which the OT and IT domains meet under explicit control. The MB213 platform supports the asymmetric data flow patterns, mediation primitives, and operational tooling described in Section 6. For technical discussion or platform inquiries, contact [info@modibus.com](mailto:info@modibus.com).