Anatomy of a Ship ZCD — Understanding the Building Blocks of an IACS UR E26 Zone and Conduit Diagram

🗺 ZCD Anatomy Ship OT Cybersecurity Series Part 5 of 5 · Final IACS UR E26

Beyond the Diagram: What Really Makes a ZCD

Anatomy of a Ship ZCD

Understanding the Building Blocks of an IACS UR E26 Zone and Conduit Diagram

Ship OT Cybersecurity Series · Part 5 — Final

Captain Paul

Maritime 4.0 · AI, Data & Cyber Security · linkedin.com/in/shipjobs

📚 Ship OT Cybersecurity Series — 5 Parts

Part 1 From Cable to Cyber Resilience — Designing Physical Networks for IACS UR E26/E27

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 4 Why Most Ship ZCDs Fail — Seven Common Mistakes in IACS UR E26/E27 Projects

▶ 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

Examples

ECDIS → Radar IEC 61162

AMS → IAS Modbus TCP

⚖️ 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

Zone ID	Zone Name	Purdue Level	SL-T	Description
Z-01	Navigation Zone	L3	SL-T 3	ECDIS, Radar, VDR
Z-02	Machinery Zone	L2	SL-T 3	IAS, AMS, PMS
Z-03	DMZ	L3.5	SL-T 2	Jump, Patch, Gateway

⚖️ 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

Conduit ID	Source	Destination	Protocol	Controls
C-01	External	DMZ	HTTPS	FW · VPN
C-02	DMZ	Navigation	RDP	FW · MFA · Log
C-03	Navigation	Machinery	IEC 61162	ACL · IDS

⚖️ 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

Source	Destination	Port	Protocol	Purpose
ECDIS	Radar	4001	IEC 61162	Position overlay
AMS	IAS	502	Modbus TCP	Alarm integration
Jump Server	Eng. WS	3389	RDP	Remote maintenance

⚖️ 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.

💼 LinkedIn ↗ 🌐 More Articles ↗

Related Articles

• E26 Zone Defense — Learn IACS UR E26 as a Tower Defense Game
• Why Most Ship ZCDs Fail: Seven Mistakes That Derail IACS Compliance
• IACS UR E26 vs E27: The Complete Comparison

 Field Note — Captain Paul

A ZCD is not a drawing — it is the visible expression of trust relationships inside a vessel. That distinction matters most when you look at the three supporting artifacts the article enumerates: the Zone Table, the Conduit Table, and the Data Flow Matrix. Each one answers a different question. The Zone Table defines what assets exist and what security level each zone must reach. The Conduit Table defines the permitted communication paths and their permitted protocols. The Data Flow Matrix maps which data crosses which zone boundaries and by which mechanism. None of the three is useful in isolation; all three must be internally consistent before the ZCD diagram itself carries any evidential weight.

The most commonly overlooked operational obligation is Management of Change (MoC). E26 does not treat ZCD as a one-time design artifact — it must remain accurate across the vessel's operational lifecycle. A software update, a new interface, a change in network topology: any of these can invalidate the ZCD without triggering an automatic review. Projects that treat ZCD as a delivery milestone rather than a living document consistently produce surveys where the as-installed state diverges from the approved documentation.

The 15-component structure in this article is a practical checklist for auditing an existing ZCD — not just a template for creating a new one.

A common misconception in practice:
"Once the ZCD is drawn and Class-approved, it's finished." E26 treats ZCD as a living document that must reflect the actual as-installed state at every annual survey. A design-stage ZCD that is never updated after delivery will diverge from reality and create survey findings.

Key practical takeaways:

• Verify that all three supporting artifacts — Zone Table, Conduit Table, and Data Flow Matrix — are complete and internally consistent before treating the ZCD diagram as valid evidence.
• Establish a formal MoC trigger list: software updates, new interfaces, topology changes, and supplier changes must each initiate a ZCD review.
• Use the 15-component checklist to audit an existing ZCD for completeness, not only when creating one from scratch.

📖 RELATED COMPLETE GUIDE

Ship Cyber Resilience Complete Guide: IACS UR E26, OT Security & SCARP →

How to build, maintain, and verify cyber resilience throughout a ship's lifecycle — OT security zones, SCARP planning, and IACS UR E26 compliance.

📖 IACS UR E26 Complete Guide

IACS UR E26 — Cyber Resilience of Ships: The Complete Guide

ZCD · CBS Classification · SCARP · Audit Procedures · E27 Interface — 모든 것을 한 페이지에서.

전체 가이드 읽기 →

⚓ Join the ShipPaulJobs Community

Join →