Anatomy of a Ship ZCD — Understanding the Building Blocks of an IACS UR E26 Zone and Conduit Diagram
📚 Ship OT Cybersecurity Series — 5 Parts
Part 2
Zone Before VLAN — Designing Logical Networks Using the Purdue Model and Zone & Conduit Concepts
Part 3
From Networks to ZCD — Translating Physical and Logical Networks into IACS UR E26 Documentation
▶ Part 5
Anatomy of a Ship ZCD — Understanding the Building Blocks of an IACS UR E26 Zone and Conduit Diagram
📋 Contents — 15 Components
1. Purpose of a ZCD
9. Network Devices
2. Asset Inventory
10. Zone Table
3. Purdue Level Assignment
11. Conduit Table
4. Zone Definition
12. Data Flow Table
5. Conduit Definition
13. ZCD Diagram
6. Data Flow Matrix
14. Relationship with CSDD
7. Security Level Targets
15. Maintaining the ZCD
8. Security Controls
📖 Key Terms — Terminology Used in This Article
ZCD (Zone and Conduit Diagram)
— A visual representation of a ship's cybersecurity zones and communication paths. The core document required by IACS UR E26 and the subject of this article's anatomical analysis.
Asset Inventory
— A list of all cyber-relevant equipment and systems onboard. Includes equipment name, function, operational protocol, and location. The starting point for any ZCD — Zones cannot be defined without it.
Purdue Model
— A reference model dividing industrial control systems into levels (0–5). Level 1 = field control (PLCs, sensors); Level 2 = SCADA/HMI; Level 3 = operations management; Level 3.5 = DMZ (buffer zone); Level 4 = business IT; Level 5 = external internet.
Zone
— A logical grouping of assets sharing common security requirements (IEC 62443). Defined by trust level, not physical location. Examples: OT Zone, Bridge Zone, Crew Zone.
Conduit
— A permitted communication path between Zones. Security controls must be explicitly defined — Firewall, ACL, VPN, IDS — for a connection to qualify as a Conduit.
Data Flow Matrix
— A table mapping source-to-destination communication by protocol, port, direction, and purpose. The basis for firewall rules and a key evidence document in E26 audits.
SL-T (Security Level Target)
— The required cybersecurity protection level for each Zone (SL-1 to SL-4), set through risk assessment. A higher number requires stronger protection.
CSDD (Cyber Security Design Description)
— The complete documentation package required by IACS UR E26. Includes Asset Inventory, Zone/Conduit definitions, Data Flow Matrix, SL-T, ZCD, and verification activities. The ZCD is the central component of the CSDD.
FAT / SAT (Factory Acceptance Test / Site Acceptance Test)
— FAT verifies equipment functionality before it leaves the factory. SAT verifies correct operation after installation onboard under actual operating conditions. A complete ZCD is required to design the test scope for both.
MoC (Management of Change)
— A formal procedure for updating the ZCD and related documents whenever ship systems are changed. Skipping it causes documentation to diverge from actual configuration — a major deficiency in classification surveys.
Introduction — Why a ZCD Is More Than a Picture
A Zone and Conduit Diagram (ZCD) is frequently described as a deliverable. Engineers produce it, classification societies request it, and auditors review it.
But what exactly is a ZCD? What does it consist of? And what must be true before it can be drawn?
A ZCD is not a drawing.
It is the visible expression of the assumptions, trust boundaries, and communication rules that define a ship's cyber resilience.
01
Understanding the Purpose of a ZCD
Required by
IACS UR E26
Core of
CSDD
Represents
Cyber Architecture
The ZCD does not describe hardware. It describes trust relationships — which systems can communicate, through which boundaries, under which controls. It is the graphical form of the entire security design.
⚖️ Regulatory Basis
IACS UR E26 §2
ZCD is the core component of the Cyber Security Design Description (CSDD). E26 requires graphical documentation of the ship's Zone and Conduit architecture to be submitted to the classification society.
IEC 62443-3-2 §5.3
Provides the normative definition of the Zone and Conduit model. The ZCD is the final visual output of Zone and Conduit analysis as defined by this standard — a graphical expression of all security design decisions.
02
Asset Inventory — The Foundation of Everything
Before a single zone can be defined, the asset inventory must be complete. It is impossible to define trust boundaries for systems that have not been identified.
Required Attributes
📌 Asset ID
📌 System Name
📌 Supplier
📌 Function
📌 Purdue Level
📌 Criticality
Common Examples
ECDIS
Radar
IAS
AMS
PMS
No asset inventory → No valid zone definition.
⚖️ Regulatory Basis
IACS UR E26 §2
Requires identification and documentation of all Onboard Computer Systems (OCS) and Computer Based Systems (CBS). Zone definition is not permissible without a complete asset inventory. Must include Asset ID, function, supplier, Purdue level, and criticality.
IEC 62443-3-2 §5.2
Asset identification is defined as the first step of the initial cybersecurity risk assessment. Zone classification begins only after assets are inventoried; unidentified assets become blind spots excluded from Zone and Conduit analysis.
NIST SP 800-82 Rev.3 (ID.AM-1)
Identifies maintenance of a physical device and OT system inventory as a key control. The OT asset inventory is a prerequisite for security design, risk assessment, and incident response.
ISO 27001:2022 A.5.9
Requires creation and maintenance of an information asset inventory as a control item. Includes documentation of asset owner, function, and classification. In the ship environment, the OCS/CBS list satisfies this control.
03
Purdue Level Assignment — Mapping Assets into Levels
Each asset must be assigned to a Purdue level. This assignment drives zone definition and conduit design.
Level 5
External Connectivity
Internet · VSAT · LTE
Level 4
Business Network
Office · Crew Welfare
Level 3.5
DMZ
Jump · Patch · Gateway
Level 3
Operations Network
Navigation · Comms
Level 2
Supervisory Control
HMI · Operator Stations
Level 1
Basic Control
PLCs · Controllers
⚖️ Regulatory Basis
IEC 62443-3-2 §5.3
Adopts the Purdue model hierarchy as the reference architecture for IACS security design. Levels 0–5 form the basis for Zone definition and trust boundary setting. Level 3.5 (DMZ) is a mandatory buffer zone that must be reflected in every E26 design.
NIST SP 800-82 Rev.3 §5
Recommends the Purdue reference model as the hierarchical baseline for OT network security design. Provides the theoretical foundation for physical and logical IT/OT separation, and underpins the design of firewalls and DMZs that restrict data flow between levels.
04
Zone Definition — Defining Trust Boundaries
Zone Attributes
→ Zone ID
→ Zone Name
→ Description
→ Security Level Target (SL-T)
→ Assets Included
Baseline Nine Zones
① External Access Zone
② Business Zone
③ Crew Welfare Zone
④ DMZ
⑤ Security Monitoring Zone
⑥ Navigation Zone
⑦ Communication Zone
⑧ Machinery Zone
⑨ Cargo / Mission Zone
⚖️ Regulatory Basis
IACS UR E26 §2
Requires Zones to be defined as groups of assets sharing common security requirements, with a risk assessment-based SL-T assigned to each. Zone boundaries are set by trust level, not physical location.
IEC 62443-3-2 §5.3.1
"A zone is a grouping of assets based on similar security requirements." — The normative international standard basis for Zone definition. Explicitly states that assets sharing physical space must be separated into distinct Zones if they operate at different trust levels.
ISO 27001:2022 A.8.22
Requires groups with different security classifications to be separated into distinct networks as a control item. Provides the information security standard basis for Zone separation design and mandates the separation of OT and IT networks.
05
Conduit Definition — Defining Controlled Communication
A conduit is not simply a cable or a network link. It is a defined, controlled communication path between two Zones — with explicit security attributes.
Conduit Attributes
→ Conduit ID
→ Source Zone
→ Destination Zone
→ Communication Purpose
→ Direction
→ Security Controls
⚖️ Regulatory Basis
IACS UR E26 §2
Requires all communication paths between Zones to be defined as Conduits, with security controls (firewall, VPN, IDS, ACL) explicitly stated for each. A connection without security controls is not recognized as a Conduit and is classified as a design deficiency.
IEC 62443-3-2 §5.3.2
Defines a Conduit as 'a set of one or more channels forming a managed path for information exchange between Zones, with security controls applied.' Clearly distinguishes a Conduit from a simple cable or network link.
ISO 27001:2022 A.8.20
Requires security controls to be implemented on network communication paths. Sets the control objective of protecting networks from unauthorized access — the ISO basis for Conduit security controls.
06
Data Flow Matrix — The Heart of the ZCD
Most Critical
The Data Flow Matrix is the foundation from which conduit definitions, firewall rules, and verification procedures are derived. Without it, conduits are assumptions.
Required Attributes
→ Source Asset
→ Destination Asset
→ Protocol
→ Port
→ Direction
→ Justification
⚖️ Regulatory Basis
IACS UR E26 §2
Designates data flow documentation as a mandatory CSDD component. Without a complete Data Flow Matrix — covering source/destination assets, protocol, port, direction, and purpose — Conduit definitions lack a design basis and may result in audit failure.
IEC 62443-3-2 §5.4
Requires data flows — source/destination, protocol, port, and direction — to be documented as part of Zone and Conduit analysis. The normative basis document for firewall rule design and the foundation for deriving FAT/SAT test items.
NIST SP 800-82 Rev.3 (DE.CM-1)
Requires baseline data flow documentation for monitoring network communications and connection status. The Data Flow Matrix serves as the normal baseline for detecting anomalous traffic.
07
Security Level Targets (SL-T) — Protection Requirements
SL-Ts are derived from risk assessment and define the required level of protection for each Zone across three security dimensions.
🔄
Availability
🔒
Integrity
🔐
Confidentiality
Navigation Zone
SL-T 3
Machinery Zone
SL-T 3
Crew Network
SL-T 1
⚖️ Regulatory Basis
IACS UR E26 §2
Requires SL-T to be assigned to each Zone based on risk assessment results. Navigation and Machinery Zones typically receive SL-T 3. The SL-T is the reference value for selecting the appropriate security control level per Zone.
IEC 62443-3-2 §5.2
Defines the procedure for determining SL-T through risk assessment combining threat likelihood and consequence severity. Establishes a 4-level scale from SL-1 (basic) to SL-4 (highest). SL-3 corresponds to protection against a sophisticated adversary — appropriate for safety and navigation systems.
IEC 62443-3-3 §SR 7
Specifies availability requirements according to SL-T level. In OT environments, availability and integrity take precedence over confidentiality — this priority must be reflected in SL-T determination.
08
Security Controls — How Conduits Are Protected
⚙ Technical Controls
🛡 Firewall
📋 ACL
🔐 VPN
👁 IDS
📝 Logging
🔑 MFA
📄 Administrative Controls
→ Procedures
→ Access Approval
→ Maintenance Control
⚖️ Regulatory Basis
IACS UR E26 §2
Requires security controls commensurate with SL-T to be implemented for each Zone and Conduit. Must include both technical controls (firewall, VPN, IDS, MFA) and administrative controls (procedures, access approval, maintenance control). The control list must be documented in the CSDD.
IEC 62443-3-3 §SR 1~SR 7
SR 1 (Identification & Authentication), SR 2 (Use Control), SR 3 (System Integrity), SR 4 (Data Confidentiality), SR 5 (Restricted Data Flow — normative basis for firewalls and ACLs), SR 6 (Timely Response to Events — logging and IDS), SR 7 (Resource Availability). Each SR scales in required stringency with SL-T level.
ISO 27001:2022 A.8.21~A.8.22
Requires network service security (A.8.21) and network segregation (A.8.22) as control items. Provides the information security standard basis for implementing firewalls, ACLs, encryption, and IDS.
NIST CSF 2.0 PR.AC
Recommends applying least privilege, multi-factor authentication (MFA), and remote access controls. Provides the framework basis for administrator and privileged account controls, and underpins remote access control design via Jump Server.
09
Network Devices Behind the ZCD — The Physical Reality
The ZCD is a logical representation. Behind it sits physical infrastructure that implements the architecture.
🔀
Router
🛡
Firewall
⚡
Core Switch
🔌
Access Switch
📶
Wireless AP
👁
IDS Sensor
🖥
Jump Server
+
and more
⚖️ Regulatory Basis
IACS UR E27 §3
Defines cybersecurity functional requirements at the equipment level for individual Computer Based Systems (CBS) installed onboard. Where E26 governs the overall system architecture (ZCD), E27 defines functional requirements for each device — firewall capability, authentication, patch management, logging, and disabling unnecessary ports.
IEC 62443-4-2
Defines the technical security requirements (Component Requirements, CR) that individual components — network switches, firewalls, wireless APs, Jump Servers — must satisfy. The technical foundation standard for IACS UR E27; the reference for equipment selection and specification writing.
Supporting Artifacts (10–12)
The ZCD diagram itself is the visible tip. These three tables are what support and justify every element in the diagram.
10
Zone Table — Supporting Artifact #1
⚖️ Regulatory Basis
IACS UR E26 §2
The Zone Table is a mandatory CSDD submission. Required to include Zone ID, constituent assets, Purdue level, SL-T, and description. Classification society auditors cross-check the ZCD diagram against the Zone Table for consistency; discrepancies are flagged as design deficiencies.
11
Conduit Table — Supporting Artifact #2
⚖️ Regulatory Basis
IACS UR E26 §2
The Conduit Table is a mandatory CSDD submission. Required to specify source/destination Zones, communication protocol, port, direction, and applied security controls. Serves as the direct reference for firewall policy design and FAT/SAT verification activities.
IEC 62443-3-2 §5.3.2
Requires documentation of security control attributes when defining Conduits. The Conduit Table is the specific implementation document for this requirement, recording the controls applied to each Conduit (FW, VPN, MFA, IDS) in a verifiable format.
12
Data Flow Table — Supporting Artifact #3
⚖️ Regulatory Basis
IACS UR E26 §2
The Data Flow Table is the normative basis document for firewall rules and access control policies. Auditors use it to verify which communications are permitted and which must be blocked. Defining Conduits without it constitutes a lack of design basis and may result in audit failure.
IEC 62443-3-2 §5.4
Requires documentation of data flows — source/destination, protocol, port, and direction — as part of Zone and Conduit analysis. The Data Flow Table is the direct implementation document for this requirement and the supporting evidence for all Conduit definitions.
13
ZCD Diagram — The Visible Part of Cyber Architecture
The diagram is the graphical output of all preceding work. It uses standardized symbols to represent the architecture at a glance.
□
Zones (Trust Boundaries)
↔
Conduits (Controlled Paths)
🔥
Firewalls
╌
Trust Boundaries
The diagram is only as accurate as the
tables that support it.
⚖️ Regulatory Basis
IACS UR E26 §2
Requires the ZCD — visually representing Zones, Conduits, security boundaries, and security control devices (firewalls, etc.) — to be submitted to the classification society as part of the CSDD. The ZCD diagram is a visualization of the Zone Table, Conduit Table, and Data Flow Matrix; inconsistencies with the tables result in audit rejection.
IEC 62443-3-2 §5.3
Defines the ZCD as the final visual output of Zone and Conduit analysis. The principle that the diagram is a visualization of the tables and cannot exist independently originates from this standard. Submitting the diagram alone does not satisfy CSDD requirements.
14
Relationship with CSDD — How ZCD Fits into E26 Documentation
The ZCD is not a standalone document. It sits within the Cyber Security Design Description (CSDD) as the graphical summary of the full architecture.
Asset Inventory
↓
Purdue Level
↓
Zone Definition
↓
Conduit Definition
↓
Data Flow Matrix
↓
Security Level
↓
🗺 ZCD
↓
CSDD
↓
✅ Verification
⚖️ Regulatory Basis
IACS UR E26 §2
Requires the CSDD as an integrated design documentation package encompassing asset inventory, Zone/Conduit definitions, Data Flow Matrix, SL-T, ZCD, and verification plan. The ZCD is the core structural document within the CSDD; submitting the ZCD alone, without the other components, is not accepted.
IMO MSC-FAL.1/Circ.3 Rev.2 (2022) §2
The IMO-level basis for cyber risk management documentation requirements. Provides the overarching international regulatory context for the IACS UR E26 CSDD requirement, establishing the obligation for shipowners and flag states to maintain cybersecurity documentation systematically.
15
Maintaining the ZCD — Keeping Architecture Aligned with Reality
A ZCD is only valid as long as it reflects the actual ship. Management of Change (MoC) is essential to keep the architecture current.
The ZCD must be reviewed and updated when:
!
Suppliers modify or update systems
!
Software updates affect network behavior
!
Network expansion adds new systems
!
Temporary connections are made
!
Remote access sessions are established
An outdated ZCD is worse than no ZCD.
It creates false confidence.
⚖️ Regulatory Basis
IACS UR E26 §4 (In-Service Requirements)
Requires implementation of a formal MoC procedure to update the entire CSDD — including the ZCD — whenever ship systems are modified. Failure to implement MoC may be classified as a Major Finding in periodic classification surveys and is applied in conjunction with the ISM Code Safety Management System.
IEC 62443-2-1 §4.4 (Change Management)
Requires a formal change management process and documentation for all system changes affecting cybersecurity. The MoC procedure must include pre-change risk assessment, approval, document updates, and post-change verification.
IMO Resolution MSC.428(98) (2017)
Requires integration of ship cyber risk management into the Safety Management System (SMS). The supreme IMO regulatory basis for the obligation to maintain cyber documents such as the ZCD throughout vessel operations; applicable from the first DOC verification due on or after 1 January 2021.
Final Thoughts
A Zone and Conduit Diagram is not a drawing.
It is the visible expression of the assumptions,
trust boundaries, and communication rules
that define a ship's cyber resilience.
It begins with cables. It ends with verified architecture.
🎉 Ship OT Cybersecurity Series — Complete
Full Journey
Physical Network → Logical Network → ZCD → CSDD → Verification
This series laid the architectural foundation. The next series will go deeper — into practical implementation.
🔭 Coming Next — E26 ZCD Practical Guide
Part 6
Designing Conduits and Firewall Rules
Part 7
Security Level Targets (SL-T) and Risk Assessment
Part 8
From ZCD to CSDD
Part 9
Verification, FAT and SAT
Part 10
Maintaining Cyber Architecture Throughout the Vessel Lifecycle
Captain Paul
Maritime cybersecurity professional specializing in IACS UR E26/E27 compliance, OT system architecture, and shipyard-level cyber resilience design. Writing for engineers, superintendents, and operators navigating Maritime 4.0.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment