Why Most Ship ZCDs Fail — Seven Common Mistakes in IACS UR E26/E27 Projects

⚠ Lessons Learned Ship OT Cybersecurity Series Part 4 of 5 IACS UR E26/E27

Why Most Ship ZCDs Fail

Seven Common Mistakes in IACS UR E26/E27 Projects

Ship OT Cybersecurity Series · Part 4 — Final

Captain Paul
Captain Paul
Maritime 4.0 · AI, Data & Cyber Security · linkedin.com/in/shipjobs
📌 Series Overview

This series explored how physical networks evolve into logical architectures and ultimately become the cyber resilience documentation required by IACS UR E26 and E27. This final part examines where real-world projects most frequently go wrong.

📖 Key Terms — Terminology Used in This Article
ZCD (Zone and Conduit Diagram) — A structural diagram showing a ship's cybersecurity zones and communication paths. The primary document required by IACS UR E26 and the first item classification society auditors request.
Zone — A grouping of assets (equipment and systems) that share common security requirements. Defined by trust level, not physical location (IEC 62443).
Conduit — A permitted communication path between Zones — a managed path with applied security controls (firewall, ACL, VPN, IDS). A connection with no controls is not a Conduit.
VLAN (Virtual LAN) — A network segment logically separated through switch configuration. A tool for implementing Zones, but a VLAN is not itself a Zone. Zone = security policy; VLAN = implementation mechanism.
DMZ (Demilitarized Zone) — A buffer zone between IT and OT networks (Purdue Level 3.5). Houses jump servers, patch servers, and remote access gateways. Frequently omitted in E26 designs — a critical gap.
Data Flow Matrix — A table defining device-to-device communication by protocol and port. The basis for firewall rules; Conduit definitions written without this table may be rejected in audit.
MoC (Management of Change) — The process of updating the ZCD and related documents whenever ship systems are modified. Replacing equipment without MoC causes the ZCD to diverge from actual configuration — a critical deficiency in audit.

Introduction

After reviewing numerous ship cyber security projects, one observation becomes clear.

Most projects do not fail because of

Technology

They fail because of

Architecture

Or more precisely — because the documentation does not represent reality.

A Zone and Conduit Diagram (ZCD) is often one of the first documents requested by classification societies. Ironically, it is also one of the most misunderstood deliverables. Many diagrams look impressive. Few actually describe how the ship operates.

When architecture diverges from reality,
cyber resilience becomes little more than a drawing.

#1

Mistake One

Starting With Firewalls Instead of Systems

Many projects begin by asking: "Where should the firewall be installed?"

But this is the wrong question. The first question should be: "What systems exist, and how do they interact?"

Firewalls are security controls. They are consequences of architecture — not the architecture itself.

Correct Sequence

Asset Inventory Dependency Mapping Zone Definition Conduit Definition Firewall Rules

Starting from products almost always leads to unnecessary complexity.

#2

Mistake Two

Treating VLANs as Zones

The most common assumption:

VLAN = Zone

✗ These concepts are fundamentally different.

VLAN

A networking mechanism

Zone

A trust boundary

One Zone may contain multiple VLANs. Two systems with different trust levels should never belong to the same Zone simply because they share a switch.

Zones define trust. VLANs implement trust. Not the other way around.
#3

Mistake Three

Ignoring Level 3.5

Level 3.5 is often viewed as an inconvenience. As a result, remote access servers, patch servers, and engineering workstations are directly connected to operational networks. This creates dangerous trust relationships.

Level 3.5 (DMZ) acts as the buffer between IT and OT. Without it, there is no controlled trust — only connectivity.

Typical systems located in the DMZ:

🖥 Jump Servers 📦 Patch Servers 🔑 Remote Access Gateways 🛡 Antivirus Servers 📝 Syslog Servers
#4

Mistake Four

Trying to Make the ZCD Match the Switch Diagram

A physical network drawing
A switch topology
An IP addressing diagram
A cable layout

The purpose of a ZCD is to represent:

✓ Trust boundaries ✓ Communication paths ✓ Security controls ✓ Security levels

Trying to represent every switch and cable produces diagrams that are difficult to understand and impossible to maintain.

Good ZCDs are abstractions — not wiring diagrams.
#5

Mistake Five

Defining Conduits Without Data Flows

Many projects define conduits by name — C-01, C-02, C-03 — but fail to explain what flows through them.

Why communication exists
Which protocols are used
Which direction is required
Which ports are necessary

Without understanding data flows, conduits become meaningless lines on paper.

Data Flow Matrices are the foundation of: Conduit Definitions, Firewall Rules, and Verification Activities.

Good conduits originate from operational requirements — not assumptions.
#6

Mistake Six

Forgetting That Availability Comes First

Traditional IT Security

Focuses on Confidentiality

Maritime OT

Prioritizes Availability

Ships must continue operating. Therefore, cyber resilience depends not only on protection but also on survivability.

Physical network design should consider redundancy:

🔄 Redundant Core Switches 🔁 Ring Topologies ⚡ Dual Power Supplies 🌐 RSTP 🔗 PRP 🔗 HSR
Cyber resilience means designing systems that continue functioning when abnormal conditions occur.
#7

Mistake Seven — Most Dangerous

Believing That Documentation Equals Reality

A ZCD may satisfy documentation requirements.

But if the actual ship differs from the document, the architecture no longer exists.

Many discrepancies emerge because:

Suppliers modify systems after delivery.
Temporary connections become permanent.
Maintenance laptops are introduced into networks.
Remote access sessions remain active indefinitely.
Networks evolve after vessel delivery.

Over time, the ship changes. But the documents often do not.

Cyber resilience disappears in the gap between them.

A Good ZCD Is Not a Picture

A good ZCD is much more than a deliverable. It is the graphical expression of cyber architecture.

A ZCD represents

Trust relationships
Security boundaries
Controlled communication
Cyber resilience assumptions

Most importantly, it provides a common language between all stakeholders in a ship cyber project:

🏢 Owners 🏭 Shipyards 🔧 Integrators ⚙ Equipment Suppliers 📋 Classification Societies
Without that common language, cyber resilience becomes difficult to design, verify, and maintain.

Final Thoughts

Common Interpretation

IACS UR E26/E27 = Cyber security requirements

Reality

They are architectural requirements.

The objective is not to install more security products. The objective is to build ships capable of maintaining essential functions despite cyber incidents.

The Complete Journey

⚡ Begins with cables
🌐 Continues through networks
🔒 Becomes Zones & Conduits
🛡 Evolves into Cyber Resilience

Cyber resilience is not created by firewalls.

It is created by architecture.

And architecture is only valuable when it reflects reality.

🎉 Series Complete

Ship OT Cybersecurity Series — All 4 Parts

Physical Network → Logical Network → ZCD → CSDD → Verification

Captain Paul
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 →
Share

Comments