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 can mean a production shutdown, equipment damage, or a safety incident as well as a data breach. ISA/IEC 62443 gives you the zone-conduit model to manage that boundary, and Sparx EA gives you the place to make it visible, governable, and auditable.

The security architect's job is to decide where the zones are, what may cross each conduit and which controls protect each boundary. Building the zone and conduit model, tagging assets and tracing threats to controls are mechanical tasks that grow with every new connection. In AI-augmented work the architect states the zoning rules and the target security levels, and AI builds and maintains the model and flags conduits that break the rules. The skill is knowing the standard and the plant well enough to say where the boundaries belong and to review what comes back. The rest of this article is the reference for that.

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, NIS2 in Europe).

The standard spans four series: Series 1 (General) covers concepts, models and terminology; Series 2 (Policies and Procedures) covers the security management system for IACS; Series 3 (System) covers system security requirements, where the zone-conduit model is applied in IEC 62443-3-2 and 3-3; and Series 4 (Component) covers 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

ArchiMate's Motivation elements provide 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

From spreadsheets to a governed OT security architecture

OT/IT convergence is too consequential to document in Visio diagrams and spreadsheets. Configure the Solution covers zone-conduit modeling, MDG configuration, threat modeling and control gap analysis that satisfies both OT engineers and enterprise security governance. The same repository can feed dashboards in Prolaborate or Power BI showing zone security levels, outstanding control gaps and remediation progress. See how this fits the broader enterprise architecture discipline.