“Convergence” implies two things becoming one. In energy infrastructure, that is precisely the problem.
The assumption that keeps security architects awake
There is a sentence that appears with alarming regularity in digital transformation roadmaps, vendor pitch decks, and executive briefings across the energy sector. It usually reads something like this:
“By converging our IT and OT environments, we unlock operational efficiency, real-time analytics, and the ability to leverage enterprise tooling across the entire estate.”
It is not wrong. The efficiency gains are real. The analytics are genuinely valuable. The business case often stacks up.
What the sentence omits is that convergence, as it is typically implemented, treats the integration of Information Technology (IT) and Operational Technology (OT) as an engineering convenience problem, when it is fundamentally a security architecture problem. The decisions made in the name of convergence are among the most consequential and least reversible in the lifecycle of not just for an energy operator’s infrastructure, but also for any critical infrastructure operator across almost any industry. And the assumptions baked into those decisions are, in my experience, the single most common root cause of catastrophic exposure in critical energy systems.
The consequence scales with what the OT environment actually controls. Take mining: inadequate IT/OT separation means a compromised network can take autonomous haulage fleets offline. The driverless trucks moving ore across open-cut operations at scale go down. That is not a routine outage. At major mining operations, autonomous haulage downtime costs millions to tens of millions of dollars a day. Serious money, serious disruption. For grid operators, the equivalent compromise does not disrupt a single site’s production schedule. It threatens supply to hospitals, water treatment plants, and the households of entire regions. Different order of consequence entirely. Which is rather the point of this post.
I have spent the better part of my unorthodox career at the intersection of enterprise architecture and operational infrastructure in major energy contexts, manufacturing and mining amongst other contexts. What follows is not a survey of the academic literature or a rehash of NIST guidance. It is my personal account of where the convergence assumption goes wrong, why it goes wrong, and what a principled architectural response looks like.
What we actually mean by IT and OT
Before we can talk about convergence, we need to be precise about what we are converging.
Information Technology (IT) encompasses the systems, networks, and infrastructure that manage data: enterprise resource planning, email, document management, financial systems, corporate identity, cloud workloads. IT systems are designed around the CIA triad : Confidentiality, Integrity, and Availability , with confidentiality typically the dominant concern. A data breach is costly. Downtime is expensive but recoverable. A patching cycle measured in weeks or months is operationally inconvenient but broadly acceptable.
Operational Technology (OT) encompasses the hardware and software that monitors and controls physical processes: programmable logic controllers (PLCs), distributed control systems (DCS), supervisory control and data acquisition (SCADA) systems, remote terminal units (RTUs), safety instrumented systems (SIS), and the industrial protocols: Modbus, DNP3, PROFIBUS, OPC-UA, over which they communicate. OT systems are designed around the AIC triad: Availability first, then Integrity, then Confidentiality. A control system going offline does not mean lost productivity. It may mean uncontrolled pressure in a pipeline, failed protection logic at a substation, or loss of visibility over a refinery process. In the worst cases, it means people get hurt, which is why in OT contexts like Mining, safety is a mantra, often tied to peoples annual bonuses.
This inversion of priority is not a minor technical footnote. It is a fundamental architectural incompatibility. And yet the convergence narrative tends to treat it as a detail to be resolved through tooling rather than a constraint that should shape every design decision from the outset.
The second dimension of incompatibility is time. IT systems operate on timescales measured in milliseconds to seconds, with human interactions and business processes driving load. OT systems frequently operate on timescales measured in microseconds, with real-world physics, the rate of a chemical reaction, the angular velocity of a turbine, the frequency of an AC power system imposing hard latency constraints. A SCADA polling cycle that introduces 50ms of additional jitter because it is traversing a shared network with IT traffic is not a performance inconvenience. In some contexts, it is an operational failure.
The third dimension is lifecycle. Enterprise IT infrastructure turns over on cycles of three to seven years. OT infrastructure turns over on cycles of fifteen to thirty years, or longer. The PLCs controlling a gas compression station may have been installed before the iPhone existed. They were not designed with network connectivity in mind, and they carry no assumption that they would one day be reachable from a corporate laptop. The security models of the two domains to the extent that legacy OT had a security model at all, were not designed to coexist.
The Purdue Model and why it still matters
Any serious treatment of IT/OT architecture must grapple with the Purdue Enterprise Reference Architecture (PERA), originally developed by Theodore Williams and colleagues at Purdue University in the early 1990s and subsequently formalised through the ISA-99 (now ISA/IEC 62443) standards programme. The Purdue Model has been declared dead many times, usually by vendors selling something that replaces it. It is not dead. It has been misapplied, misunderstood, and in many organisations never properly implemented, but as a conceptual framework for thinking about the functional separation of industrial control environments, it remains the most useful mental model available.
The model defines a hierarchy of levels:
Level 0 — The physical process. Sensors, actuators, valves, motors. The physical world.
Level 1 — Basic control. PLCs, RTUs, and other field devices that read from Level 0 and apply control logic. These devices often run proprietary real-time operating systems, have no authentication, and cannot be patched without a maintenance window if they can be patched at all.
Level 2 — Supervisory control. SCADA servers, HMI workstations, engineering stations. This is where operators interact with the process. Systems at this level are typically Windows-based, which immediately raises the question of how enterprise patching and endpoint security applies to machines that cannot be rebooted without planning shutdowns weeks in advance.
Level 3 — Manufacturing operations / site operations. Historian servers, MES systems, batch management. This level is where process data begins to aggregate and where the boundary between OT and IT begins to blur in most organisations.
Level 4 — Business logistics / enterprise IT. ERP, email, corporate directory services. Classic IT territory.
Level 5 — Enterprise network / internet connectivity. The corporate WAN and internet edge.
The critical insight of the Purdue Model is not the levels themselves , it is the zones and conduits principle: traffic should flow between levels only through explicitly defined, controlled conduits, and every crossing of a level boundary should be a deliberate architectural decision with explicit security justification. The model assumes, fundamentally, that you should be able to sever the connection between Level 3 and Level 4 and continue operating the physical process. Safety and continuity of the physical process must not depend on the availability of business IT systems.
This principle, often called network segmentation in enterprise contexts, but better understood as architectural independence in OT contexts, is not a nice-to-have. It is the structural basis of operational resilience. When you compromise it in the name of convergence, you do not get a converged system. You get a system with the attack surface of IT and the resilience expectations of OT.
How convergence projects break the model
In my experience, the erosion of architectural separation between IT and OT does not usually happen because someone made a decision to remove it. It happens incrementally, driven by individually reasonable-looking engineering choices, each of which seems inconsequential in isolation.
Here is the pattern I have observed repeatedly in energy operator environments:
Step 1: The data demand. Business stakeholders want real-time operational data in the enterprise analytics platform. Finance wants production figures. Operations leadership wants dashboards. The data historians at Level 3 hold what they need.
Step 2: The connectivity shortcut. Rather than architect a proper conduit: a data diode, a one-way gateway, a carefully firewalled DMZ, the team establishes a routed connection between the Level 3 historian and an enterprise data platform. A firewall rule is opened. It is narrow, nominally justified, and nobody expects it to stay forever.
Step 3: The firewall rule accumulation. Six months later, there are fourteen firewall rules. Some are for the original data feed. Some are for remote support connections that engineering vendors required during a project. Two are for a jump host that was provisioned for a maintenance window and never decommissioned. Nobody has a complete picture of what each rule was for.
Step 4: The IT tooling creep. Enterprise IT begins managing the Level 2 and Level 3 Windows systems, because it is efficient and because the argument that “these are just Windows boxes” is superficially correct. Group Policy objects are applied. An enterprise endpoint detection and response (EDR) agent is deployed. Nobody checks whether the EDR agent’s network scanning behaviour interferes with OPC-DA polling. Nobody checks whether the Group Policy changes the boot behaviour of the SCADA server in a way that prevents it from starting the control application automatically after a power restoration.
Step 5: The identity convergence. Active Directory is extended into the OT environment. The engineering workstations are domain-joined. This means that a credential compromised in the IT environment: a phishing email, a password reuse attack, a pass-the-hash against an enterprise account, now grants authenticated access to engineering systems that can reprogram PLCs.
Step 6: The incident. This is where the scenario diverges. In the best case, a red team exercise or a penetration test reveals the exposure before an adversary does. In the more common case, it remains undetected until a ransomware operator or, in the worst case, a sophisticated nation-state actor, traverses the path that has been inadvertently constructed.
None of the individual steps in this sequence required a decision to “remove IT/OT separation.” Each step felt reasonable in context. The cumulative effect was the removal of IT/OT separation.
The threat landscape this exposes you to
The theoretical risk I have described above is not theoretical. The documented history of attacks on energy and industrial infrastructure should remove any doubt that adversaries are actively exploring and exploiting IT/OT convergence as an attack vector.
TRITON/TRISIS (2017) remains the most significant and disturbing example. The malware : attributed to a Russian state-sponsored actor, targeted the Triconex safety instrumented system (SIS) at a Middle Eastern petrochemical facility. The attackers had spent months establishing a foothold in the IT environment before pivoting to the OT network and ultimately reaching the SIS, whose purpose is to trigger emergency shutdowns when process parameters reach unsafe levels. The intent was not to steal data or encrypt files for ransom. The intent was to disable the last line of protection against a physical catastrophe, allowing a separate attack to proceed without the safety system intervening. The attack failed only because of an inadvertent programming error that triggered a safe shutdown before the attackers achieved their final objective. This is the adversary at the high end of the capability spectrum: patient, technically sophisticated, and willing to invest years in an intrusion in pursuit of physical consequences.
Colonial Pipeline (2021) sits at the opposite end of the sophistication spectrum, a ransomware infection of IT systems, not OT systems but it illustrates a different aspect of the convergence problem. The operational shutdown of the pipeline was not caused directly by the ransomware reaching SCADA systems. It was caused by the operator’s loss of confidence in the integrity of their billing and metering systems, which were IT systems that sat adjacent to the OT environment. The convergence between IT and OT was not a technical attack path in this case; it was an operational dependency that the operator had not fully modelled. The lesson is that convergence creates risk even when the attack does not cross the IT/OT boundary, because the business processes and safety processes of an energy operator are entangled in ways that are not always visible until something goes wrong.
Ukraine Power Grid Attacks (2015, 2016) demonstrated coordinated, multi-stage attacks against electricity distribution infrastructure that specifically leveraged IT/OT convergence. In both incidents, attackers used spear-phishing to establish footholds in IT systems, conducted reconnaissance over months, and then executed coordinated attacks on SCADA systems using legitimate remote access tools that existed because operators needed remote connectivity for maintenance. The 2016 Industroyer/Crashoverride malware was purpose-built to communicate with substation equipment using native industrial protocols: IEC 104, IEC 101, IEC 61850 GOOSE. It did not need to exploit a vulnerability in the OT protocol stack. It simply used the protocols as designed, having first obtained the network access to reach them.
The pattern across these incidents is consistent: IT systems provide the entry point and the lateral movement path; the objective is physical consequences delivered through OT systems; and the enabler is the absence of robust architectural separation between the two domains.
What ISA/IEC 62443 actually says — and what it demands
ISA/IEC 62443 is the international standard series for industrial cybersecurity. It is comprehensive, technically rigorous, and considerably less read than it should be by people making architecture decisions in energy environments. Understanding its key concepts is essential to moving from the vague aspiration of “IT/OT separation” to something that can be specified, built, verified, and audited.
The standard introduces two foundational concepts for network architecture: zones and conduits.
A zone is a logical grouping of assets with common security requirements. Assets in the same zone are assumed to trust each other to the same degree and are protected collectively. The definition of a zone should reflect the functional role of the assets, the consequences of their compromise, and the operational constraints on how they can be managed and protected.
A conduit is the communication channel between zones. Every conduit must be explicitly defined, and the security requirements of the conduit are determined by the highest security level required by either of the zones it connects. In practice, this means that if you run a conduit between a Level 3 OT zone and a Level 4 IT zone, the security controls on that conduit must reflect the requirements of both, including the OT side’s need for availability and latency determinism.
The standard defines four Security Levels (SL), from SL 1 (protection against casual or unintentional violation) to SL 4 (protection against state-sponsored sophisticated attack with extended resources). For energy infrastructure particularly anything that falls within the scope of national critical infrastructure: SL 2 or SL 3 is typically the appropriate target, depending on the consequence of compromise.
What this means architecturally is that you cannot simply declare zones and draw a firewall rule. The standard demands that you:
- 1 Define zones based on consequence of compromise, not organisational structure
- 2 Document the conduits between zones and the security controls applied to them
- 3 Specify the target Security Level for each zone and demonstrate that your controls are sufficient to achieve it
- 4 Conduct a risk assessment that accounts for the specific threat landscape relevant to your organisation
- 5 Define compensating controls for assets that cannot be patched or updated (a major consideration for legacy PLCs)
The Purdue Model tells you where the boundaries should be. ISA/IEC 62443 tells you how to specify, implement, and verify the security of those boundaries. Neither is optional for a serious critical infrastructure operator.
What true architectural separation looks like
So what does it actually mean to implement IT/OT separation properly? Not as a policy declaration, not as a diagram on a slide, but as a built, verifiable, operational architecture?
The starting point is the network architecture.
True separation requires that traffic between IT and OT zones cannot flow without passing through an explicitly controlled conduit. This means separate network infrastructure, separate switches, separate routing domains, not just VLAN segmentation on shared equipment. VLANs are a useful tool, but misconfiguration, trunk port errors, and VLAN hopping attacks all represent failure modes that a physical separation eliminates. In high-consequence environments, physical separation is not paranoia. It is the appropriate engineering response to the threat model.
For conduits, the gold standard is a data diode or unidirectional security gateway: a hardware device that enforces one-way data flow at the physical layer. Data can travel from OT to IT process data, historian replication, alarm events, but no traffic can travel from IT to OT. This eliminates an entire class of attack paths: an adversary who compromises an IT system cannot reach the OT network through a unidirectional gateway. Vendors like Waterfall Security Solutions and Owl Cyber Defense offer purpose-built products for this use case. The tradeoff is that data diodes require careful design to accommodate any legitimate requirement for IT-to-OT data flow, which is usually minimal, most OT environments need to export data, not import it.
Where bidirectional communication is genuinely required: remote access for vendor support, patch management for Level 2 systems, time synchronisation , the conduit must be implemented through a properly architected OT DMZ (demilitarised zone): an intermediate network zone with its own security controls, through which data is inspected and brokered rather than passed directly. The DMZ hosts application-layer proxies, protocol translators, and logging infrastructure. Traffic from IT to OT must transit the DMZ and be explicitly proxied with no direct routed path from the IT network to the OT network should exist.
Credential isolation is equally critical.
OT systems should not be domain-joined to enterprise Active Directory. Engineering workstations, SCADA servers, and historian systems should authenticate against a separate identity infrastructure ideally a dedicated OT Active Directory domain with no trust relationships to the enterprise domain. The consequence of this is administrative overhead: separate accounts, separate password management, separate processes for user lifecycle management. That overhead is the point. It ensures that a credential compromise in the enterprise IT environment cannot be immediately leveraged against OT systems.
For remote access which, post-COVID and with increasing vendor support expectations, is now essentially universal, the model is explicit, time-limited, session-recorded, jump-host-mediated access. No VPN split-tunnelling that allows an OT-connected laptop to simultaneously reach the internet. No persistent remote access connections for vendor tooling. Every session initiated from outside the OT zone should require multi-factor authentication, generate a complete session recording, and terminate automatically on expiry.
Asset management is the prerequisite for everything else.
You cannot protect what you cannot see. In practice, many energy operators have incomplete asset registers for their OT environments particularly for Level 1 and Level 2 assets, which may have been installed and commissioned by contractors over many years and may never have been formally inventoried. Passive network discovery tools such as Claroty, Dragos, Nozomi Networks, or the open-source Zeek-based alternatives can identify devices by observing network traffic without sending probes that might upset process equipment. The output of that discovery exercise should feed a managed asset register that is treated as a living document, updated as part of every change process.
Patching requires a different process, not an exception.
The fact that OT systems cannot be patched on the same timescale as IT systems is sometimes used as an argument for either not patching them at all, or for connecting them to enterprise patch management infrastructure. Both conclusions are wrong. The right model is a separate, OT-specific patch management process with explicit testing in a representative staging environment before any patch is applied to production control systems, change management that coordinates with operations to identify appropriate maintenance windows, and compensating controls: network segmentation, protocol filtering, enhanced monitoring for vulnerabilities where patching is not feasible within an acceptable timeframe.
The organisational dimension — why the architecture argument alone is not enough
I want to be direct about something that does not appear in standards documents.
The principal barrier to proper IT/OT separation is not technical. The technical solutions are well-understood, reasonably mature, and available from multiple vendors at competitive prices. The principal barrier is organisational: the incentive structures, reporting lines, and cultural assumptions that govern how IT and OT teams relate to each other.
In many energy operators, IT and OT are managed by different parts of the organisation with limited shared governance. IT security teams often well-resourced, CISSP-certified, familiar with enterprise security frameworks have limited understanding of process safety constraints and operational requirements. OT teams are operationally expert, safety-conscious, deeply familiar with the physical systems they manage andhave historically operated without security professionals and have an ingrained resistance to changes that might affect operational stability. The convergence of their environments, absent organisational convergence around shared risk understanding, produces predictable outcomes: IT imposes controls that OT overrides because they break things, or OT resists controls that IT considers non-negotiable, and the result is an environment where neither party has a complete picture of the security posture.
The security architecture function which I would argue needs to exist as a distinct discipline spanning both IT and OT in any serious energy operator has a specific role here: to translate between these communities of practice, to maintain the architecture documentation that gives both sides a shared understanding of the environment, and to own the risk decisions that neither side can make independently.
This requires people who are uncomfortable in both camps: who understand process safety well enough to have a serious conversation with a process engineer about control system availability requirements, and who understand security architecture well enough to design a defence-in-depth model that satisfies a CISO. That combination is rare and should be cultivated deliberately.
Practical starting points — where to begin if your environment is already partially converged
If you are reading this and recognising your own organisation in the patterns I have described: incremental firewall rule accumulation, IT tooling that has crept into OT environments, Active Directory integration that nobody remembers authorising, you are not starting from zero. You are starting from a state of partial, unplanned, undocumented convergence, which is in some respects harder than a greenfield design.
Here is where I would start:
1. Zone mapping and network discovery. Before you can design toward a target architecture, you need an accurate picture of your current state. Commission a passive discovery exercise and produce a zone map: what assets exist, where they sit in the Purdue hierarchy, what network connectivity exists between zones, and what that connectivity was intended for. Expect surprises.
2. Conduit audit. For every connection between IT and OT zones, document the business justification, the traffic flows, the firewall rules, and the responsible owner. Identify connections that have no clear owner or no current business justification. These are your immediate risk reduction opportunities.
3. Crown jewel identification. Not all OT assets are equally critical. The SIS at a gas processing plant is not in the same risk category as the air conditioning control system. Identify the assets whose compromise would have direct process safety or critical availability consequences, and prioritise architectural protection for those assets first.
4. Remote access consolidation. Remote access paths are among the most common entry points for adversaries. Audit every remote access mechanism : VPNs, jump hosts, vendor-specific remote support tools, modem connections that someone installed in 2009 and forgot, and rationalise them to a defined, monitored, access-controlled set.
5. Engage operations from the outset. Every architectural change to an OT environment must be made with the involvement of the operations teams responsible for running it. Security improvements that break operational processes will be circumvented. Circumvented controls are worse than no controls, because they create a false impression of security. Build the relationship with operations before you start making changes.
The next convergence mistake is already being made
The energy sector has not finished processing the lessons of IT/OT convergence. And yet a new convergence narrative is already taking hold.
**Artificial intelligence , **specifically, large language models and ML-based analytics platforms is being integrated into operational environments with a familiarity that should, by now, feel uncomfortable. The pitch is different but the structure is identical: connect your OT data to an AI platform, unlock insights you could not previously access, improve efficiency and decision-making across the estate.
The questions nobody is asking are the same questions nobody asked in 2010.Where does the data go? What does the AI platform’s network connectivity look like from the OT side? Who controls the model, and what happens if it is manipulated adversarially or otherwise to issue recommendations that degrade process safety? If the AI system becomes load-bearing for operational decisions, what is the failure mode when it is unavailable, incorrect, or compromised?
AI is not inherently dangerous in OT contexts. But the pattern of deployment fast, enthusiasm-driven, architecturally underspecified is dangerous. We have seen this before. The assumption that a powerful new technology can be integrated into critical infrastructure without first asking hard architectural questions is not innovation. It is the same mistake, running again, on a shorter cycle.
The architecture question precedes the technology question. Every time.
Convergence as a business decision that demands security architecture
I want to end by being clear about what I am not arguing. I am not arguing against the integration of IT and OT data. The business value of operational analytics is real. The efficiency gains from remote monitoring and predictive maintenance are real. The energy transition, distributed energy resources, smart grid management, demand response, requires information flows between the physical operation of the grid and the digital systems that coordinate it. None of that goes away.
What I am arguing is that “convergence”, the word itself , is dangerous precisely because it suggests that IT and OT should become one thing, that the boundary between them should dissolve, that the controls that exist to protect process safety and operational continuity are obstacles to be worked around rather than features to be preserved. The correct model is not convergence. It is controlled integration: defined, documented, architecturally explicit connections between systems that remain, at the level of their most critical functions, architecturally independent.
The energy sector operates systems whose failure can cause physical harm, environmental damage, and cascading consequences for the communities that depend on energy infrastructure. The security architecture of those systems must reflect that reality. The assumption that IT and OT can simply converge, that the tools, processes, and governance models of enterprise IT can be imported wholesale into the OT environment is not just architecturally naive. In a threat landscape where sophisticated adversaries are actively seeking to exploit exactly this assumption, it is a risk that an energy operator simply cannot afford to hold.
The good news is that the alternative is well-defined. The standards exist. The technology exists. The architecture patterns exist. What is required is the organisational will to implement them with rigour, and the architectural expertise to translate them into real systems that operations teams can live with and security teams can verify.
That is the work.
Key references and further reading
- ISA/IEC 62443 series — The definitive standard for industrial control system security. Start with IEC 62443-3-3 (System Security Requirements and Security Levels) and IEC 62443-2-1 (Establishing an IACS Security Management System).
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security. A practical companion to ISA/IEC 62443 with US regulatory context.
- MITRE ATT&CK for ICS — The adversary behaviour framework for industrial control systems. Essential for threat modelling. Available at attack.mitre.org/matrices/ics/.
- Dragos Year in Review — Annual threat intelligence report on OT-specific adversary activity. Valuable for understanding the current threat landscape.
- Waterfall Security — Unidirectional Security Gateways: The Book — Andrew Ginter’s accessible treatment of the data diode architecture and its application in industrial environments.
- E-ISAC / NERC CIP — For operators of bulk electric systems in North America, the Critical Infrastructure Protection standards provide a regulatory framework that encodes many of the architectural requirements discussed here.
- NCSC — Operational Technology Security — The UK National Cyber Security Centre’s guidance for OT security, with specific guidance for critical national infrastructure operators.
This post is part of an ongoing series on security architecture for critical infrastructure and energy systems. The next post in the series examines threat modelling frameworks for critical national infrastructure — and why standard enterprise approaches fall dangerously short.
About the author: Cloud, Infrastructure, and Security Architect with 14 years of experience spanning enterprise architecture, operational technology environments, and regulated digital infrastructure.