OT/IT Convergence Architecture: Modeling ISA-99 Security Zones in Sparx EA
When operational technology connects to enterprise IT, the boundary that once protected the plant floor erodes — and a security failure stops being a data breach. It becomes a production shutdown, equipment damage, or a safety incident. ISA/IEC 62443 gives you the zone-conduit model to manage that boundary; Sparx EA gives you the place to make it visible, governable, and auditable.
OT/IT convergence is the defining security challenge of modern industrial organizations. As operational technology — PLCs, SCADA systems, DCS platforms, industrial robotics — becomes connected to enterprise IT for data collection, remote monitoring, and cloud analytics, the air gap that once isolated plant-floor systems from corporate-network threats has gone. ISA/IEC 62443 (ISA-99) is the international standard that provides a systematic approach to securing Industrial Automation and Control Systems, and Sparx EA is the modeling tool that brings its zone-conduit model into a governed, auditable practice. This article covers how to implement ISA-99 zone and conduit modeling in Sparx EA, how to use the ArchiMate Technology layer for OT architecture, and how to connect OT security architecture to enterprise risk governance.
What OT/IT convergence means — and why it creates risk
Operational Technology (OT) is the hardware and software that monitors and controls physical processes: Programmable Logic Controllers (PLCs) running automated equipment sequences, SCADA systems monitoring distributed infrastructure, Distributed Control Systems (DCS) in continuous-process industries, and industrial robotics.
Historically, OT operated in isolation — air-gapped from enterprise IT, running proprietary protocols on dedicated networks. Security through obscurity and physical isolation was the de facto approach.
Convergence broke that isolation, and the business case is compelling: real-time production data flowing to enterprise analytics, remote monitoring and diagnostics by vendors, cloud-based SCADA dashboards, and IIoT integration connecting sensors to cloud analytics. All of it requires OT systems to have IT connectivity, and often internet exposure.
The security consequences are severe. OT systems were designed for reliability and real-time performance, not security. They run legacy operating systems (Windows XP, Windows 7) that can no longer be patched, use authentication mechanisms designed for isolated environments — or none at all — and rely on protocols like Modbus and Profinet that were built without security features. Connected to IT networks, the attack surface they present is enormous. The 2021 Colonial Pipeline ransomware attack, the 2021 Oldsmar water-treatment incident, and the Triton/TRISIS attack on a petrochemical Safety Instrumented System all illustrate the real-world consequences.
ISA/IEC 62443: the security standard for industrial systems
ISA/IEC 62443 (commonly called ISA-99, after the ISA committee that developed it) is a family of standards addressing cybersecurity for Industrial Automation and Control Systems (IACS). It is the primary international standard for OT security and is referenced by IEC, NIST, and sector-specific regulations (NERC CIP for electric utilities, CFATS for chemical facilities, NIS2 in Europe).
The standard spans four series: Series 1 (General) — concepts, models, terminology; Series 2 (Policies and Procedures) — the security management system for IACS; Series 3 (System) — security requirements, where the zone-conduit model lives, in IEC 62443-3-3; and Series 4 (Component) — requirements for IACS components and secure development.
For architecture purposes, IEC 62443-3-2 (Security Risk Assessment) and IEC 62443-3-3 (System Security Requirements and Security Levels) matter most. Together they define the zone-conduit model (segmenting industrial networks into Security Zones connected by controlled Conduits), the Security Levels SL1-SL4 (from protection against casual violation up to protection against state-sponsored attacks), and the seven Foundational Requirements — FR1 Identification and Authentication Control, FR2 Use Control, FR3 System Integrity, FR4 Data Confidentiality, FR5 Restricted Data Flow, FR6 Timely Response to Events, FR7 Resource Availability.
The Purdue model and zone-conduit structure in Sparx EA
The Purdue Model (Purdue Enterprise Reference Architecture, or PERA) provides the conceptual hierarchy for industrial automation, structured in levels from field devices up to enterprise IT, with a controlled DMZ between the OT and IT worlds. In Sparx EA, each level becomes a Technology-layer Node carrying an ISA-99 Security Zone stereotype, and the conduits between them become controlled communication paths.
Each Purdue level becomes an ISA-99 Security Zone node; conduits connect only adjacent zones, and no traffic crosses the OT/IT boundary except through the DMZ.
Tagged values on each zone node record the Purdue Level (0 / 1 / 2 / 3 / DMZ / 4), the Target Security Level (SL1-SL4), the Zone Owner, the Asset Count, and the assessed Connection Risk from adjacent zones. Conduits — the controlled communication paths — are modeled as Communication Network elements with an ISA-99 Conduit stereotype connecting adjacent zone nodes, each recording Allowed Protocols, Direction (unidirectional or bidirectional), Security Controls (firewall, data diode, protocol gateway), and whether a hardware Data Diode enforces unidirectionality.
ArchiMate technology layer for OT architecture
ArchiMate's Technology layer supplies the modeling vocabulary for OT architecture. Technology Nodes represent the physical and virtual computing elements — PLC cabinets, SCADA servers, engineering workstations, historian servers, DMZ jump servers, industrial firewalls (Fortinet FortiGate, Palo Alto Networks, Tofino Security), and data diodes (Owl Cyber Defense, Waterfall Security). Communication Networks represent the network segments — Profinet at Level 1, OPC-UA at Levels 2-3, SCADA WAN across sites, corporate LAN, and the DMZ segment between them. System Software elements represent the operating systems and industrial software, and Devices represent field-level equipment — PLCs (Allen-Bradley, Siemens S7, Schneider Modicon), HMI panels, drives, and safety PLCs.
Industrial protocols are modeled as communication standards on the Communication Network elements:
- OPC-UA — the modern standard for secure, platform-independent industrial data exchange, with built-in security (X.509 certificates, encrypted communication).
- Modbus/TCP — the legacy protocol, widely used in older equipment, with no built-in authentication or encryption; a significant concern when exposed to IT networks.
- Profinet — Siemens industrial Ethernet for time-sensitive automation.
- DNP3 — common in electric-utility SCADA; DNP3 Secure Authentication adds authentication but is not widely deployed.
- EtherNet/IP — Rockwell Automation's industrial Ethernet protocol.
Threat modeling and security requirements in Sparx EA
The ArchiMate Motivation layer (Strategy layer in ArchiMate 3) provides the framework for OT threat modeling. Risk elements represent identified threat scenarios — IT-OT lateral movement (an attacker who compromises corporate IT moves into the OT DMZ and then Level 2 SCADA), remote access abuse (a vendor with legitimate access deploying malware), insider threat (an employee making unauthorized changes to PLC logic), and ransomware propagation (ransomware entering via corporate IT and reaching historian and SCADA servers).
Each Risk element is linked to the Security Zone nodes it threatens and to the ISA-99 Foundational Requirements (modeled as Requirement elements) that mitigate it. Controls — firewall rules, network segmentation, OT-specific intrusion detection (Nozomi Networks, Claroty, Dragos) — are modeled as Technology elements realizing the Requirement elements. This creates end-to-end traceability from threat to requirement to control: the foundation for OT security assurance documentation.
MDG configuration for ISA-99 architecture
A purpose-built ISA-99 MDG Technology extension provides the stereotypes that make the whole model queryable and checkable:
«ISA-99 Security Zone»— extends Technology Node with Purdue Level, Target Security Level, Zone Owner, and Asset Count.«ISA-99 Conduit»— extends Communication Network with Allowed Protocols, Direction, and Security Controls.«OT Asset»— extends Device with Manufacturer, Model, Firmware Version, EOS Date, and Protocol Support.«ISA-99 Control»— extends Requirement with Foundational Requirement category, Security Level target, and Implementation Status.«OT Risk»— extends the Risk element with MITRE ATT&CK for ICS tactic, technique, and severity.
Model validation rules then enforce the architecture: are all conduits between zones at different Purdue levels configured with appropriate security controls? Are all OT Assets running Modbus (no native authentication) inside an appropriately restricted zone? Are all SL3/SL4 zones connected only via data diodes or hardware-enforced unidirectional gateways?
Frequently asked questions
Is ISA/IEC 62443 mandatory, or is it a voluntary standard?
Voluntary as an international standard, but increasingly incorporated by reference in sector-specific regulations. NERC CIP aligns closely with ISA-99 principles, and the EU's NIS2 Directive requires essential and important entities to implement appropriate security measures — ISA/IEC 62443 is the recognized standard for showing compliance. Many operators and insurers now treat ISA-99 compliance as a prerequisite for OT cyber insurance.
How does Sparx EA handle IT and OT security architectures in one model?
It holds both in one repository, with package structures separating them. The OT package uses ISA-99 stereotypes and Purdue notation; the IT package uses enterprise security notation (SABSA, Zero Trust, NIST CSF). The DMZ and integration points are modeled explicitly — that is where convergence risk concentrates and where both teams most need a shared picture.
What OT intrusion detection systems integrate with enterprise SIEM platforms?
Purpose-built OT IDS platforms (Nozomi Networks Guardian, Claroty, Dragos) passively monitor OT protocols without disrupting control communications and forward alerts to enterprise SIEM platforms (Splunk, Microsoft Sentinel) via syslog or API. In Sparx EA, the OT IDS is a Technology Node in the OT DMZ zone, with a security service relationship to the SIEM in the enterprise zone via a controlled conduit.
How do you model legacy OT equipment that cannot be patched?
As OT Asset nodes with an EOS Date tagged value and Patch Status = Cannot Patch. Associated Risk elements capture the threat scenarios these assets create. Compensating controls — micro-segmentation, application whitelisting, OT IDS monitoring, physical security — are modeled as Technology elements realizing the ISA-99 Control requirements, making the compensating-control architecture visible and auditable.
What is the role of the OT DMZ, and how is it modeled?
The OT DMZ (Purdue Level 3.5) mediates all communication between the enterprise IT network (Level 4) and the OT supervisory network (Level 3), hosting data transfer servers, remote access infrastructure, and security monitoring. In Sparx EA it is a dedicated Security Zone node at Level 3.5, with conduits to both Level 3 and Level 4. No direct conduit is permitted between Level 4 and Level 3 — all data passes through the DMZ.
From spreadsheets to a governed OT security architecture
OT/IT convergence is too consequential to document in Visio diagrams and spreadsheets. Sparx Services' Configure the Solution engagement builds your ISA-99 OT security architecture practice in Sparx EA — zone-conduit modeling, MDG configuration, threat modeling, and control gap analysis that satisfies both OT engineers and enterprise security governance. For teams that need the architecture connected to enterprise risk reporting, the same repository feeds dashboards of zone security levels, outstanding control gaps, and remediation progress. See how this fits the broader enterprise architecture discipline.
Make your OT/IT boundary visible and auditable.
Talk to a practitioner about modeling ISA-99 security zones and conduits in Sparx EA.
Book a call →Keep reading
You might also be interested in
IIoT architecture patterns for manufacturing
A Sparx EA implementation guide for industrial IoT — the other half of the convergence story.
Read → InsightEA governance for energy and utilities: OT meets IT
Governing the OT/IT boundary in a sector where it carries the most risk.
Read → For leadersConfigure the Solution
The build engagement for an ISA-99 OT security architecture practice in Sparx EA.
See how → DisciplineEnterprise architecture
How Sparx Services supports enterprise architecture teams across regulated industries.
Explore →