OT/IT Convergence Architecture: Modeling ISA-99 Security Zones in Sparx EA

Sparx EA gives industrial security architects the modeling environment to document ISA/IEC 62443 security zones, conduits, and control requirements: making the OT/IT boundary visible, governable, and auditable in a tool that operational technology and enterprise IT teams can both work with.

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 networks for data collection, remote monitoring, and cloud analytics, the security boundary that once protected plant floor systems from corporate network threats has eroded. The consequences of a security failure in the OT environment are not data breaches: they are production shutdowns, equipment damage, safety incidents, and in critical infrastructure, potential harm to human life. ISA/IEC 62443 (ISA-99) is the international standard that provides a systematic approach to securing Industrial Automation and Control Systems. Sparx EA is the modeling tool that brings that standard’s zone-conduit model into a governed, auditable enterprise architecture practice. This article explains how to implement ISA-99 zone and conduit modeling in Sparx EA, how to use the ArchiMate Technology layer to document OT architectures, and how to connect OT security architecture to enterprise risk governance.

Key Takeaways

• OT/IT convergence exposes operational technology: PLCs, SCADA, DCS: to enterprise IT threat vectors, with potentially severe operational and safety consequences.
• ISA/IEC 62443 (ISA-99) provides the security framework for Industrial Automation and Control Systems, structured around Security Zones and Conduits.
• Sparx EA models ISA-99 Levels 0–4 as Technology layer nodes with boundary and conduit relationships representing the zone architecture.
• Industrial protocols: OPC-UA, Modbus, Profinet, DNP3: are modeled as Communication Network elements with associated security requirement stereotypes.
• MDG Technology encodes ISA-99 security zone stereotypes, enabling model validation against zone security requirements.

What OT/IT Convergence Means: and Why It Creates Security Risk

Operational Technology (OT) comprises the hardware and software that monitors and controls physical processes: Programmable Logic Controllers (PLCs) that run automated equipment sequences, SCADA (Supervisory Control and Data Acquisition) systems that monitor and control distributed infrastructure, Distributed Control Systems (DCS) used in continuous process industries (oil and gas, chemicals, power generation), and industrial robotics.

Historically, OT systems operated in isolation: air-gapped from enterprise IT networks, running proprietary protocols on dedicated networks. Security through obscurity and physical isolation was the de facto approach.

Convergence has broken this isolation. The business case is compelling: real-time production data flowing to enterprise analytics platforms, remote monitoring and diagnostics by equipment vendors, cloud-based SCADA dashboards, and IIoT integration connecting sensors to cloud analytics. All of these require OT systems to have connectivity to IT networks and, in many cases, to the internet.

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. They use authentication mechanisms (or none at all) designed for physically isolated environments. Protocols like Modbus and Profinet were designed without security features. When these systems are connected to IT networks, the attack surface they present to adversaries: whether nation-state actors, ransomware operators, or insiders: is enormous.

The 2021 Colonial Pipeline ransomware attack (which forced the shutdown of a major US fuel pipeline), the 2021 Oldsmar water treatment plant incident (where an attacker attempted to increase sodium hydroxide levels to dangerous concentrations), and the Triton/TRISIS attack on a petrochemical facility’s Safety Instrumented System all illustrate the real-world consequences of insufficient OT/IT security architecture.

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 is structured across four series:

• Series 1: General: concepts, models, and terminology
• Series 2: Policies and Procedures: the security management system for IACS
• Series 3: System: security requirements for IACS systems (the zone-conduit model lives here, in IEC 62443-3-3)
• Series 4: Component: security requirements for IACS components and software development practices

For architecture purposes, IEC 62443-3-2 (Security Risk Assessment for IACS) and IEC 62443-3-3 (System Security Requirements and Security Levels) are the most relevant. Together they define:

• The Zone-Conduit Model: the approach to segmenting industrial networks into Security Zones with defined security requirements, connected by Conduits with controlled security policies.
• Security Levels (SL1–SL4): a four-level classification of security capability, from SL1 (protection against casual or coincidental violation) to SL4 (protection against state-sponsored attacks).
• Foundational Requirements: seven categories of security capability that each zone must satisfy at its target security level: 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 ISA-99 Zone-Conduit Model in Sparx EA

The Purdue Model (also called the Purdue Enterprise Reference Architecture, or PERA) provides the conceptual hierarchy for industrial automation systems, structured in five levels:

• Level 0: Field Devices: sensors, actuators, instruments
• Level 1: Basic Control: PLCs, drives, safety systems
• Level 2: Supervisory Control: SCADA, HMI, DCS operator stations
• Level 3: Manufacturing Operations: MES, historian, advanced control
• Level 3.5: Demilitarised Zone (DMZ): the controlled boundary between OT and IT networks
• Level 4: Enterprise: ERP, business analytics, corporate IT

In Sparx EA, each Purdue level is modeled as a Technology layer Node with a «ISA-99 Security Zone» stereotype. Tagged values on each zone node record:

• Purdue Level: 0 / 1 / 2 / 3 / DMZ / 4
• Target Security Level: SL1 / SL2 / SL3 / SL4
• Zone Owner: the operational team or OT manager responsible
• Asset Count: number of systems or devices in the zone
• Connection Risk: the assessed risk from connections to adjacent zones

Conduits: the controlled communication paths between zones: are modeled as Communication Network elements with a «ISA-99 Conduit» stereotype connecting adjacent zone nodes. Each conduit records:

• Allowed Protocols: the industrial or IT protocols permitted through the conduit (OPC-UA, Modbus/TCP, HTTPS)
• Direction: unidirectional / bidirectional
• Security Controls: the controls applied at the conduit (firewall, data diode, protocol gateway)
• Data Diode: whether a hardware data diode enforces unidirectionality

The combination of zone nodes and conduit relationships creates the ISA-99 zone diagram: the primary OT security architecture artifact, visible to both OT engineers and enterprise security architects.

ArchiMate Technology Layer for OT Architecture

ArchiMate’s Technology layer provides the modeling vocabulary for OT architecture in Sparx EA:

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), data diodes (Owl Cyber Defense, Waterfall Security).

Communication Networks represent the industrial and IT network segments: Profinet network (fieldbus at Level 1), OPC-UA network (supervisory at Level 2-3), SCADA WAN (supervisory communications across sites), corporate LAN (enterprise IT), and the DMZ network segment between them.

System Software elements represent the operating systems and industrial software: Windows Server (historian, SCADA server), real-time operating systems on PLCs, OPC-UA server software, SCADA software (Wonderware, Ignition, FactoryTalk View).

Devices represent field-level equipment: PLCs (Allen-Bradley, Siemens S7, Schneider Modicon), HMI panels, variable frequency drives, safety PLCs (IEC 61511 Safety Instrumented Systems).

Industrial protocols are modeled as communication standards on Communication Network elements:

• OPC-UA (Unified Architecture): The modern standard for secure, platform-independent industrial data exchange. Supports both publish-subscribe and client-server communication with built-in security (X.509 certificates, encrypted communication).
• Modbus/TCP: The legacy industrial protocol, widely used in legacy equipment. No built-in authentication or encryption: a significant security concern when exposed to IT networks.
• Profinet: Siemens industrial Ethernet protocol for time-sensitive automation applications.
• DNP3: Common in electric utility SCADA systems. DNP3 Secure Authentication (SA) 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 in Sparx EA. Risk elements represent identified threat scenarios:

• IT-OT Lateral Movement: An attacker who compromises the corporate IT network moves laterally into the OT DMZ and then into Level 2 SCADA systems.
• Remote Access Abuse: A vendor with legitimate remote access to OT systems uses that access to deploy malware or exfiltrate configuration data.
• Insider Threat: A disgruntled employee with physical or logical access to Level 1 control systems makes unauthorised changes to PLC logic.
• Ransomware Propagation: Ransomware that enters via corporate IT propagates through the OT DMZ into historian and SCADA servers, causing production shutdown.

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 systems (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 extension for Sparx EA provides:

1. «ISA-99 Security Zone»: extends Technology Node with Purdue Level, Target Security Level, Zone Owner, and Asset Count tagged values
2. «ISA-99 Conduit»: extends Communication Network with Allowed Protocols, Direction, and Security Controls tagged values
3. «OT Asset»: extends Device with Manufacturer, Model, Firmware Version, EOS Date (End of Support), and Protocol Support tagged values
4. «ISA-99 Control»: extends Requirement with Foundational Requirement category, Security Level target, and Implementation Status tagged values
5. «OT Risk»: extends Risk element with MITRE ATT&CK for ICS tactic, technique, and severity tagged values

Model validation rules check: are all conduits between zones at different Purdue levels configured with appropriate security controls? Are all OT Assets with Modbus (no native authentication) inside an appropriately restricted Security Zone? Are all zones with a Target Security Level of SL3 or SL4 connected only via data diodes or hardware-enforced unidirectional gateways?

FAQ

Q1: Is ISA/IEC 62443 mandatory, or is it a voluntary standard? ISA/IEC 62443 is voluntary as an international standard but is increasingly incorporated by reference in sector-specific regulations. NERC CIP (for North American electric utilities) has specific requirements that align closely with ISA-99 principles. The EU’s NIS2 Directive requires essential and important entities (including operators of industrial systems in critical infrastructure sectors) to implement appropriate security measures: ISA/IEC 62443 is the recognized standard for showing compliance. Many industrial operators and their insurance providers now treat ISA-99 compliance as a prerequisite for OT cyber insurance.

Q2: How does Sparx EA handle the difference between IT and OT security architectures in the same model? Sparx EA can hold both IT and OT security architectures in the same repository, with package structures separating them. The OT package uses ISA-99 stereotypes and Purdue Model notation; the IT package uses enterprise security architecture notation (SABSA, Zero Trust, NIST CSF). The DMZ and integration points between the two architectures are modeled explicitly: this is where the convergence risk is concentrated, and where the architecture most needs to be understood by both teams.

Q3: What OT-specific intrusion detection systems integrate with enterprise SIEM platforms? Purpose-built OT intrusion detection systems (Nozomi Networks Guardian, Claroty Platform, Dragos Platform) perform passive network monitoring of OT protocols without disrupting time-sensitive control communications. They can forward alerts to enterprise SIEM platforms (Splunk, Microsoft Sentinel) via syslog or API. In Sparx EA, the OT IDS is modeled as a Technology Node in the OT DMZ zone, with a security service relationship to the SIEM in the enterprise zone via a controlled conduit.

Q4: How do you model legacy OT equipment that cannot be patched or updated in Sparx EA? Legacy OT equipment with no patching path (end-of-support PLCs, Windows XP SCADA servers) is modeled as OT Asset nodes with EOS Date tagged values and Patch Status = Cannot Patch. The associated Risk elements capture the threat scenarios these assets create. Compensating controls: network micro-segmentation, application whitelisting, OT IDS monitoring, physical security controls: are modeled as Technology elements realizing the ISA-99 Control requirements. This makes the compensating control architecture visible and auditable.

Q5: What is the role of the OT DMZ in ISA-99 architecture, and how is it modeled? The OT DMZ (Purdue Level 3.5) is a segregated network zone that mediates all communication between the enterprise IT network (Level 4) and the OT supervisory network (Level 3). It hosts data transfer servers, remote access infrastructure (privileged access workstations, jump servers), and security monitoring platforms. In Sparx EA, the DMZ is modeled as a dedicated Security Zone node at Level 3.5, with conduits connecting it to both Level 3 and Level 4. No direct conduits are permitted between Level 4 and Level 3: all data must pass through the DMZ.

Q6: How does OT security architecture connect to the corporate risk management framework? OT risks: production shutdown, safety incident, equipment damage: must be expressed in enterprise risk terms (financial impact, regulatory exposure, reputational damage) for board-level governance. In Sparx EA, OT Risk elements are linked to enterprise Risk Category elements using the organization’s risk taxonomy (operational risk, safety risk, regulatory risk). This connection allows OT security risks to appear in the enterprise risk register without requiring board members to understand ISA-99 security levels.

Q7: What does a Sparx EA OT/IT convergence architecture model contain? A complete OT/IT convergence architecture model in Sparx EA contains: (1) the Purdue Model zone hierarchy with ISA-99 Security Zone stereotypes; (2) all OT assets (PLCs, SCADA, DCS, historians) as Technology Nodes within their zones; (3) all conduits between zones with protocol, direction, and security control documentation; (4) the ISA-99 Foundational Requirements as a Requirements package; (5) the threat model with Risk elements linked to zones and requirements; (6) compensating controls for legacy equipment; and (7) a remediation roadmap as Architecture Work Packages.

Q8: What Sparx Services engagement is appropriate for OT security architecture? The Amplify engagement is designed for organizations building an OT security architecture practice: it configures the ISA-99 MDG, establishes the zone-conduit architecture model, trains the architecture team, and produces the initial threat model and control gap analysis. For organizations that need the OT security architecture connected to enterprise risk reporting (Power BI dashboards of zone security levels, outstanding control gaps, remediation progress), the Connect engagement adds EA GraphLink.

Work With Sparx Services

OT/IT convergence is too important to document in Visio diagrams and spreadsheets. Sparx Services’ Amplify engagement builds your ISA-99 OT security architecture practice in Sparx EA: zone-conduit modeling, ISA-99 MDG configuration, threat modeling, and control gap analysis that satisfies both OT engineers and enterprise security governance.

Amplify from $45,000. Contact us to discuss your OT security architecture requirements.

Contact Sparx Services | Explore Amplify