Zones and Conduit Diagram: Establishing the Vessel’s Security-Zone Architecture
From CBS allocation and network segmentation to conduit control, as-built verification and survey-cycle maintenance
The Zones and Conduit Diagram, or ZCD, is the principal ship-level document used to demonstrate how computer-based systems (CBSs) are grouped into security zones, how communication is permitted within and across those zones, and how interfaces with networks outside the IACS UR E26 scope are controlled. A reliable ZCD is not merely a network drawing: it is the controlled architectural baseline linking supplier information, vessel design, commissioning evidence and operation-phase maintenance.
Key message: A compliant ZCD must represent the same in-scope CBSs as the Vessel Asset Inventory, show their zone allocation and physical locations, and agree with the communication and boundary-control design in the Cyber Security Design Description (CSDD) and the final installed vessel. It must also remain maintainable after delivery, because the Shipowner is required to keep the diagram updated and demonstrate continued management of security-zone boundaries during the operational survey cycle.
How This Article Uses “ZCD,” “Conduit” and Related Terms
Series scope. The six core deliverables group the five document categories in UR E26 §5.1 and the test procedure in §5.2.1. The exclusion assessment and description of compensating countermeasures apply where relevant. Supplier documentation, test records and the Shipowner’s operation-phase program are also part of the compliance framework.
CRSI means Cyber Resilience System Integrator in this series: a specialist performing or supporting the cyber-resilience aspects of the IACS-defined Systems Integrator function. CRSI is not a separate IACS stakeholder category. Responsibilities follow the applicable requirements and the party’s appointment.
Applicability. UR E26 Rev.1 is implemented by IACS Societies for ships within its scope contracted for construction on or after 1 July 2024. It may serve as non-mandatory guidance for other ships. The applicable Class Rules, implementation dates and project conditions must be identified for each vessel; the newest published edition is not automatically the applicable project edition.
IACS UR E26 uses the document title “Zones and conduit diagram.” This article uses the abbreviation ZCD for readability. UR E26 formally defines a security zone, a network segment, a logical network segment, a physical network segment and an untrusted network. It does not provide a separate formal definition of conduit or zone boundary device in Section 2.
For the ZCD requirement, UR E26 expressly uses the term conduit for network communication between different security zones and for any communication between a security zone and an untrusted network. IEC 62443 uses a broader supporting concept in which a conduit groups communication channels connecting zones under a common security treatment. That IEC concept may support the engineering method, but it should not be presented as the formal IACS definition.
IACS UR E26 does not prescribe a mandatory number of ZCD sheets or require separately titled “Physical ZCD” and “Logical ZCD” drawings. Separate coordinated views are recommended for complex vessels, while a combined representation may be used where all required information remains clear, complete and acceptable to the Society. A Purdue Model overlay may also be used for explanation, but it is not an IACS requirement and does not replace the UR E26 zone and conduit decisions.
Content expressly required by an IACS Unified Requirement. Additional or class-specific obligations are identified separately.
Implementation explanation provided by a Classification Society, including examples of acceptable documentation or verification.
A structured engineering method recommended for consistency, traceability and lifecycle maintenance, but not presented as a standalone IACS obligation.
1. Why the Zones and Conduit Diagram Matters
A conventional network drawing may show switches, cables, IP networks and connected equipment. A ZCD must go further by explaining the vessel’s security architecture. It must identify the in-scope CBSs, allocate them to security zones, show the relevant physical locations, illustrate required communication relationships and make boundary-crossing communication traceable to the controls described in the CSDD.
The ZCD serves three related functions:
- Architectural definition: it establishes the vessel-level segmentation model used to limit cyber-incident propagation and unauthorised lateral movement.
- Design traceability: it provides the architectural basis for the CSDD, which explains communication purpose, protocols, data flows, boundary devices and permitted traffic.
- Lifecycle control: it becomes an as-built baseline that the Shipowner must maintain under Management of Change and use during the operational survey cycle.
Under UR E26, all CBSs within scope are grouped into security zones with defined security policies and capabilities. Zones are either isolated or connected through means that control the communicated data, and only explicitly authorised traffic may cross a security-zone boundary.
2. Regulatory Purpose and Mandatory Content
2.1 Security-Zone Requirement
UR E26 defines a security zone as a collection of in-scope CBSs that meet the same security requirements and are subject to an applicable access-control policy. This means that a security zone is not automatically equivalent to one Supplier system, one shipboard department, one room, one switch, one VLAN, one IP subnet or one Purdue level.
Those attributes may influence the design, but the zone decision must be defensible in terms of common security requirements, trust, exposure, access policy, functional dependencies and the ability to control boundary-crossing communication.
2.2 Minimum ZCD Content
The Systems Integrator is required to submit the ZCD and CSDD during the design phase. The ZCD must include the following information.
| Required content | Practical meaning | Obligation |
|---|---|---|
| Clear identification of security zones | Each zone boundary and zone identifier must be distinguishable. | Shall |
| Simplified illustration of each in-scope CBS | Each CBS must be identifiable, allocated to a zone and associated with a physical location. | Shall |
| Reference to approved Supplier topology diagrams | The vessel-level representation must be traceable to the detailed system topology approved under UR E27. | Shall |
| Network communication within a security zone | Same-zone network relationships must be illustrated at a level that remains complete and traceable. | Shall |
| Network communication between different security zones | Inter-zone network communication is represented as conduits. | Shall |
| Any communication between a security zone and an untrusted network | Boundary-crossing communication to out-of-scope networks is represented as conduits; the CSDD must also address discrete and serial interfaces. | Shall |
Grouped Representation Must Remain Complete
A complex ZCD may group same-zone communication to preserve readability, but only where the underlying communication relationships remain complete and traceable through a controlled communication register or approved Supplier topology reference. Aggregation should not conceal an undocumented path or omit a relationship needed to understand the zone policy.
3. Core Concepts and Interpretation Boundaries
| Concept | Status | Meaning for ZCD development |
|---|---|---|
| Security zone | IACS-defined term | A collection of in-scope CBSs meeting common security requirements and subject to an access-control policy. |
| Network | IACS-defined term | Two or more computers communicating through a protocol over a communication medium. This definition is not limited to IP. The narrower Ethernet definition below applies to network segment. |
| Network segment | IACS-defined term | An OSI Layer 2 Ethernet segment or broadcast domain in the context of UR E26. |
| Logical network segment | IACS-defined term | A network segment sharing physical components with one or more other logical network segments. |
| Physical network segment | IACS-defined term | A network segment whose physical components are not shared with other network segments. |
| Untrusted network | IACS-defined term | Any network outside the scope of applicability of UR E26. |
| Conduit | IACS usage; not separately defined in §2 | A boundary-crossing communication relationship identified in the ZCD between different security zones or between a security zone and an untrusted network. Detailed engineering may group one or more channels under a common security treatment. |
| Zone boundary device | Implementation term used by UR E26 | A device or function enforcing or mediating communication across a zone boundary. UR E26 requires the CSDD to identify such devices but does not provide a separate formal definition in §2. |
| DMZ | Architectural pattern; not an automatic compliance designation | An intermediate security zone may be used where services, trust relationships or exposure justify it. The actual assets, functions, scope and boundary controls must be defined. |
Inter-Zone Non-IP Communication
UR E26 §4.2.1.4.1 requires network communication between in-scope zones and any communication with untrusted networks to be illustrated. “Non-IP” is not a blanket exemption: distinguish a non-IP network from a point-to-point serial or discrete interface. ClassNK’s Edition 1.1 guidance (§4-2.2) describes same-zone and inter-zone communication in IP terms and separately addresses serial and discrete communication with untrusted networks. This is a class implementation explanation, not a universal redefinition of “network” in UR E26.
For other inter-zone links, document the protocol, direction and boundary-control or isolation implications, and agree the representation with the Society. Showing boundary-crossing serial, fieldbus and discrete links is recommended to make functional dependencies visible. Communication with an untrusted network must be illustrated regardless of whether it uses IP.
4. Roles, Inputs and Data Ownership
4.1 Stakeholder Responsibilities
| Stakeholder | Principal ZCD responsibility |
|---|---|
| Systems Integrator | Establish the vessel-wide zone model, allocate CBSs, define conduits, coordinate Supplier information, submit the ZCD, maintain it during construction and verify the as-built implementation. |
| CBS Suppliers | Provide approved CBS Asset Inventories, physical and logical topology diagrams, interface information, protocols, connected-system information and relevant security-capability documentation. |
| Shipyard design disciplines | Provide equipment locations, network architecture, wiring and cable information, switch and firewall arrangements, redundancy information and construction changes. |
| Shipowner | Provide operational requirements, Owner-supplied equipment information, shore interfaces, remote-access requirements and applicable cyber-security policies. |
| Classification Society | Review the design, issue comments or approval status, and witness or assess relevant commissioning verification. |
| Shipowner/Company after delivery | Maintain the ZCD under Management of Change and demonstrate continued implementation during applicable surveys. |
4.2 IACS Source Information and CRSI-Recommended Engineering Inputs
The following table distinguishes information expressly required by IACS from structured project inputs recommended for efficient integration. Not every recommended register is a separate IACS submission.
| Input | Purpose | Basis |
|---|---|---|
| Preliminary Vessel Asset Inventory | Identifies candidate CBSs, network devices, security devices, Suppliers, locations and scope status. | IACS UR E26/E27 |
| CBS categorisation results | Records applicability, the required UR E22 category where applicable, exclusion status and safety significance. A combined categorisation register is a recommended format. | IACS basis Register format: CRSI practice |
| Vessel system-of-systems architecture | Identifies functions, system boundaries, interfaces and dependencies. | IACS UR E22 |
| Supplier CBS Asset Inventories | Provides hardware, software and interface information for vessel-level integration. | IACS UR E27 |
| Supplier physical and logical topology diagrams | Provides detailed endpoints, devices, communication paths, protocols and external connections. | IACS UR E27 |
| Vessel network, wiring and equipment-location information | Confirms actual physical connections, network segments, boundary devices and mandatory location data. | Design evidence |
| Communication and interface matrix | Structures source, destination, purpose, direction, medium, protocol and data-flow information. | CRSI practice |
| Zone Catalogue and Conduit Catalogue | Creates controlled identifiers, policy descriptions and cross-document references. | CRSI practice |
| Owner-supplied equipment register | Prevents late identification of equipment that may connect to OT or ship networks. | Class guidance / practice |
| Remote-access, wireless and shore-interface design | Identifies high-exposure conduits, dedicated zones and boundary arrangements. | IACS UR E26 |
| Isolation and functional-dependency analysis | Confirms whether a zone can be isolated without loss of its primary functionality. | Evidence method |
5. Zone Design and Segmentation
5.1 Zone-Allocation Criteria
Correct zone allocation requires more than grouping systems by equipment name or physical location. A CRSI should assess the following characteristics and document the rationale for the chosen grouping.
| Criterion | Zone-design consideration |
|---|---|
| Safety function and consequence | Whether compromise or failure could affect human safety, vessel safety or the environment. |
| System category | The UR E22 category and associated integrity, availability and segregation expectations, where applicable. |
| Security requirements | Whether the CBSs can comply with a common set of UR E26 and UR E27 requirements. |
| Access-control policy | Whether the same users, roles, devices and administrative rules can apply. |
| Trust and exposure | Whether systems have different exposure to shore, crew, wireless, remote-maintenance or other lower-trust domains. |
| Communication purpose | Whether the data flows are operationally related and compatible with the proposed zone policy. |
| Availability and isolation | Whether the zone can be isolated without impairing the primary functionality of its CBSs. |
| Maintenance model | Whether the systems share compatible update, support and remote-access arrangements. |
| Supplier capability | Whether inherent security capabilities, limitations and compensating measures are compatible. |
| Lifecycle ownership | Whether the zone policy, devices and configurations can be maintained coherently after delivery. |
5.2 UR E26 Segmentation and Dedicated-Zone Principles
| Design subject | Required treatment | Obligation level |
|---|---|---|
| General zone separation | Networks of a security zone are logically or physically segmented from other zones or networks. | Shall |
| Required safety functions | CBSs providing required safety functions are grouped into separate security zones and physically segmented from other security zones. | Shall |
| Navigation/communication versus machinery/cargo | Navigational and communication systems are not placed in the same zone as machinery or cargo systems. | Shall not |
| Navigation or radiocommunication systems approved to an equivalent standard | Such systems should be placed in a dedicated security zone. | Should |
| Wireless devices | Wireless devices are placed in dedicated security zones. | Shall |
| Systems, networks or CBSs outside UR E26 scope | They are treated as untrusted and physically segmented from required security zones. As an alternative, an OT system may form part of a zone if it meets the same requirements as that zone. | Shall, with stated alternative |
| Required local/backup control and monitoring systems covered by §4.4.2 | Where networked to a remote-control system or another CBS, the local control and monitoring system is treated as a separate security zone and protected under §§4.2.1 and 4.2.2. | Shall; case-by-case special consideration possible |
| Zone isolation | It is possible to isolate the zone without affecting the primary functionality of the CBSs within it. | Shall |
Local Control and Monitoring Must Be Addressed in the Zone Model
For CBSs needed for local backup control under SOLAS II-1 Regulation 31, including the HMI needed for effective local operation, UR E26 §4.4.2 requires independence from the primary control system. The local control and monitoring CBS must be self-contained for its intended operation. Where network communication is arranged with a remote-control system or another CBS, the applicable segmentation and network-protection safeguards apply and the local control and monitoring system is treated as a separate security zone. Different design concepts may receive case-by-case consideration from the Society.
5.3 Physical and Logical Segmentation
ClassNK explains physical segmentation as the use of separate Layer 2 network components without sharing the same Layer 2 switch. Logical segmentation may use VLANs or other logical mechanisms on shared infrastructure, provided that communication crossing the zones is redirected through the applicable boundary-control function.
ClassNK Q&A Q99 clarifies that a single firewall can serve separate physical segments when its functions and configuration keep the relevant physical ports independent. VLAN separation over one shared physical port does not meet this physical-segmentation interpretation. This is ClassNK guidance; verify the arrangement with the vessel’s Society.
A Router or Layer 3 Switch Is Not Automatically Equivalent to a Firewall
UR E26 identifies routers as one example of a means that may control data communicated between zones. It separately requires security zones to be protected by firewalls or equivalent means. A router or Layer 3 switch may therefore form part of an accepted boundary solution only where the implemented security functions provide demonstrable protection equivalent to the applicable firewall requirement and the arrangement is accepted by the Society.
Simple Layer 3 forwarding, static routing or basic subnet separation should not be presented as equivalent boundary protection. Supporting evidence should address, as applicable, restrictive traffic policy, prevention of unintended bypass, secure configuration management, logging, denial-of-service considerations, configuration backup, change control and suitability for the availability and safety requirements of the connected zones. These evidence items are CRSI-recommended substantiation, not a separate universal checklist stated verbatim by UR E26.
5.4 DMZ Use
UR E26 does not require a DMZ at every security-zone boundary. A DMZ is an architectural pattern that may be appropriate where direct communication between high-trust OT and lower-trust networks should be avoided, where intermediary services are required, or where remote maintenance and ship-to-shore communication justify an intermediate zone.
Determine the scope of DMZ assets from their functions, interfaces and role in the vessel architecture under UR E26 §1.3.2. A missing E26/E27 capability does not by itself make an asset out of scope: it may require remediation, accepted compensating countermeasures or a justified exclusion. Identify the DMZ assets, services, scope and boundary controls, including any equipment relied upon to meet the vessel’s cyber-resilience requirements.
6. Conduits and Communication Scope
6.1 Communication within a Security Zone
UR E26 requires the ZCD to illustrate network communication between systems within the same security zone. The CSDD then describes the purpose and characteristics of that communication, including relevant protocols and data flows.
Every packet-level flow does not need to be printed individually on the overview diagram. Grouped representation is a recommended documentation method, subject to Society acceptance, where the underlying flow set remains complete, controlled and traceable.
6.2 Communication between Security Zones
Network communication between different security zones is represented as a conduit. The ZCD should show the source and destination zones, the direction where relevant, the communication path, the applicable boundary device or control function and a controlled conduit identifier or reference. The CSDD specifies the communication purpose, protocols, data flows and traffic permitted to cross the boundary.
6.3 Communication with Untrusted Networks
An untrusted network is any network outside the scope of UR E26. Communication between an in-scope security zone and an untrusted network is represented as a conduit. The associated CSDD description must include discrete signals, serial communication and the purpose and characteristics of IP-based network communication, together with boundary devices and permitted traffic.
6.4 Communication-Scope Matrix
| Communication type | Minimum IACS treatment | CRSI-recommended representation |
|---|---|---|
| Network communication within one zone | Illustrate in the ZCD; describe purpose, protocols and data flows in the CSDD. | Show individual or grouped relationships supported by a complete communication register or Supplier topology reference. |
| Network communication between in-scope zones | Illustrate as conduits; describe purpose, protocols, data flows, boundary devices and permitted traffic. | Assign conduit IDs and show direction, boundary device and CSDD reference. |
| IP communication to an untrusted network | Illustrate as a conduit and fully describe in the CSDD. | Show the complete external path, intermediate domains, boundary controls and communication direction. |
| Serial communication or discrete signals to an untrusted system | Include in the CSDD communication description; the ZCD requirement covers any communication to untrusted networks. | Illustrate every such boundary-crossing path in the ZCD or a coordinated sheet; cross-reference supporting detail in the CSDD. |
| Non-IP communication between two in-scope zones | Do not exclude a network communication path solely because it is non-IP. Distinguish network communication from point-to-point serial or discrete interfaces; see Section 3 for the IACS wording and ClassNK interpretation. | Show boundary-crossing links and their control or isolation implications; agree any simplified treatment with the Society. |
| Supplier-internal serial, fieldbus or I/O communication | UR E27 §3.1.2 requires supplier topology information, including serial links and communication with I/O units. The ship-level ZCD may reference this detail, while still showing required same-zone network relationships and boundary crossings. | Avoid redrawing every internal link; show interfaces that affect zone allocation, external dependency or isolation. |
| Temporary maintenance connection | Treat according to actual connectivity, trust and access path. | Show the authorised connection point, target zone, control mechanism and temporary-use condition. |
| Wireless connection | Wireless devices are allocated to a dedicated security zone and the boundary is controlled. | Show access points, wireless zone, connected zones, external or portable endpoints and boundary device. |
| Remote-access path | All relevant untrusted-network communication and security boundaries must be addressed. | Show the full path through shore interface, DMZ or remote-maintenance zone to the target zone. |
6.5 Excluded CBSs and Untrusted-Network Treatment
Exclusion status and interface trust classification should be recorded separately, but they are related. Where the Society accepts exclusion of a CBS from the UR E26 scope under §6.4, the resulting scope boundary must be reflected in the design. UR E26 §4.2.1.3 states that systems, networks or CBSs outside the scope are considered untrusted networks.
Communication between such an excluded CBS and an in-scope security zone must be shown as communication with an untrusted system and controlled in accordance with §4.2.1, including the physical-segmentation requirement or the stated alternative where accepted. An exclusion does not remove the boundary obligations of the remaining in-scope zone. Record the exclusion basis and Society decision, and reconcile them with the asset scope and interface documentation.
7. Recommended ZCD Package
IACS requires specified information, not a fixed drawing count. For a simple vessel, one combined diagram may be sufficient. For a complex vessel, a controlled package with coordinated physical and logical views is generally easier to review, maintain and verify.
| ZCD component | Recommended content | Status |
|---|---|---|
| Document control and legend | Project, vessel, drawing number, revision, status, symbols, line types, zone conventions and abbreviations. | Necessary document control |
| Zone Catalogue | Zone ID, name, purpose, included functions, policy basis, segmentation type, principal locations and isolation considerations. | CRSI recommended practice |
| Physical ZCD | Physical locations, CBSs, cabinets or racks, network/security devices, interface media, external connections and Supplier topology references. | Recommended for complex vessels |
| Logical ZCD | Zone boundaries, logical segments, conduits, direction, boundary controls, wireless, remote access and untrusted domains. | Recommended for complex vessels |
| Conduit Catalogue | Conduit ID, source, destination, purpose, direction, medium, boundary device, CSDD reference and implementation status. | CRSI recommended practice |
| Boundary Device Allocation Table | Device ID, type, location, connected zones, security role, redundancy and controlled configuration reference. | CRSI recommended practice |
| Switch and Network Allocation Table | Switch ID, location, connected equipment, network classification, zone assignment and boundary role. | CRSI recommended practice |
| Cross-Reference Matrix | Mapping between CBS IDs, asset entries, Supplier drawings, zones, conduits, CSDD sections and test cases. | CRSI recommended practice |
| Revision and Change Log | Changes, affected zones or conduits, MoC reference, approval status and as-built closure. | Lifecycle control |
7.1 Data Ownership and Sensitive Information
The ZCD should not become an unreadable substitute for the CSDD or a repository for every IP address, port number and firewall rule. A controlled data-ownership model reduces conflicting duplication. However, §4.2.1.4.1 requires the CSDD to specify permitted boundary traffic. An external register must not leave this required content outside the reviewed design baseline. The CSDD also covers the other applicable design-phase requirements in UR E26 Section 4; communication control is only one part.
| Data type | Recommended authoritative source |
|---|---|
| Asset identity and hardware/software version | Vessel Asset Inventory |
| Zone and conduit architecture | ZCD |
| Communication purpose and security rationale | CSDD |
| Detailed addresses, ports and permitted-traffic rules | CSDD or a controlled, revision-identified annex/register incorporated into the CSDD review package and accepted by the Society |
| Passwords, private keys and other authentication secrets | Separate protected credential-management process; drawings and communication registers reference the process or account role without containing the secrets |
| Exclusion rationale | Risk Assessment for Exclusion |
| Compensating-measure basis | Description of Compensating Countermeasures |
| Verification method and acceptance criteria | Ship Cyber Resilience Test Procedure |
| Executed evidence | Test records and survey records |
7.2 Optional Purdue Overlay
A Purdue-level overlay may help explain the functional hierarchy of a complex OT environment. It remains informative only: Purdue levels are not security zones, one level may contain multiple zones, and one zone may span more than one functional level where justified. Project conventions such as “Level 3.5” should be labelled as conventions and must not override UR E26 requirements for safety, wireless, navigation/machinery separation, untrusted networks or zone isolation.
8. Development and As-Built Lifecycle
The ZCD should be developed iteratively from preliminary scope identification through as-built verification. During construction, the Systems Integrator is required to keep the diagram updated. Changes affecting hardware, software, interfaces, segmentation, boundary devices, wireless, remote access or Owner-supplied equipment must be assessed through Management of Change.
8.1 Management of TBD Information
Early design submissions may contain “TBD” information where data is genuinely unavailable. Each TBD should have an owner, required source, closure milestone and identified impact on other documents. A TBD should not remain unresolved at commissioning where it affects scope, zone allocation, segmentation, boundary-device selection, untrusted-network connectivity, permitted communication, isolation capability, compensating measures or test coverage.
8.2 Typical Change Triggers
- equipment-model substitution;
- firmware, operating-system or application-version change;
- addition or removal of an interface;
- new VLAN, subnet, route or trunk;
- firewall or ACL change;
- new remote-access function;
- new wireless connection;
- equipment relocation;
- new inter-zone communication;
- new untrusted-network connection;
- change to Supplier security capability;
- change to exclusion or compensating-measure status.
9. Traceability, Commissioning and Survey-Cycle Relevance
9.1 Cross-Document Traceability
| Related document | Consistency and traceability check |
|---|---|
| Vessel Asset Inventory | The ZCD and inventory cover the same in-scope CBSs with consistent identities. Zone and physical-location information must appear in the ZCD; zone/category fields in the inventory are optional under §4.1.1.3.1. If duplicated in the inventory, zone and location data must agree. |
| Supplier CBS Asset Inventory | Hardware and interface information matches the vessel-level representation. |
| Supplier physical topology | The simplified ZCD references the approved detailed physical architecture. |
| Supplier logical topology | Endpoints, paths and protocols support the vessel-level logical design. |
| CSDD | Each relevant internal flow and conduit has a corresponding purpose, protocol, data-flow and boundary-control description. |
| Risk Assessment for Exclusion | The excluded CBS and interface treatment are consistent with the approved scope decision. |
| Description of Compensating Countermeasures | Boundary or intermediary devices used as compensating measures appear in the ZCD and Asset Inventory. |
| Ship Cyber Resilience Test Procedure | Tests verify zone implementation, segmentation, boundary traffic and isolation arrangements. |
| Ship Cyber Security and Resilience Program | The maintained ZCD supports operation-phase boundary management, change control and survey evidence. |
9.2 Commissioning Verification
Before final commissioning, UR E26 §5.2 requires the Systems Integrator to submit the updated as-built design documents and test procedure, and carry out testing witnessed by the Society under the approved procedure.
During commissioning, the Systems Integrator must demonstrate that the onboard security zones match the approved ZCD, CSDD, Vessel Asset Inventory and relevant Supplier documents, and that security-zone boundaries permit only the traffic documented in the approved design. UR E26 gives physical inspection, network scanning, firewall-rule evaluation and port scanning as examples of suitable verification methods.
The following are evidence methods, not a complete list of required tests. The approved procedure must also address applicable network-protection and isolation demonstrations under §§4.2.2 and 4.4.3. Scanning is an example method under §4.2.1.4.3, not a universally required ZCD test. Any permitted omission of previously certified tests is decided by the Society under §5.2.1. Plan intrusive tests with the affected CBS suppliers and within the vessel’s safe test conditions.
Depending on the vessel and approved test plan, commissioning evidence may include:
- inspection of equipment and cable installation;
- switch, router and firewall configuration review;
- VLAN and routing verification;
- network and port scans;
- rule-set comparison;
- communication-path tests;
- zone-isolation tests;
- configuration exports and backups;
- photographic evidence;
- discrepancy and closure records.
9.3 Operation-Phase Survey Cycle
| Survey stage | Direct responsible party | ZCD-related demonstration |
|---|---|---|
| First Annual Survey | Shipowner/Company | Demonstrate that the ZCD has been kept updated and that security-zone boundaries are managed under the approved Ship Cyber Security and Resilience Program. |
| Subsequent Annual Surveys | Shipowner/Company | Demonstrate continued implementation upon request by the Society. |
| Special Survey | Shipowner/Company | Demonstrate the zone implementation and boundary-traffic activities in §4.2.1.4.3 under the maintained test procedure. Other tests follow the specific operation-phase clauses; not every commissioning test is repeated automatically. |
The Systems Integrator hands over the documentation required by UR E26 §5. The Shipowner carries the operation-phase duties; continued CRSI support depends on its appointment. Recommended operation-phase evidence includes the current ZCD revision, change log, MoC records, boundary-device configuration reviews, firewall or ACL review records, network or port-scan results, isolation-test records, configuration backups and relevant Society correspondence.
10. Classification Society and Supporting-Standard Notes
10.1 ClassNK
ClassNK’s Guidelines for Cyber Resilience of Ships, Edition 1.1, provides detailed implementation explanations for the ZCD, including scope display, Supplier topology references, conduit treatment, physical and logical segmentation, VLAN examples, dedicated-zone requirements, untrusted-network separation and zone isolation. The official ClassNK page listed Edition 1.1 when checked on 5 October 2026. Its Q&A provides further implementation explanations. These ClassNK interpretations should not be treated as additional universal IACS clauses.
10.2 Lloyd’s Register
Lloyd’s Register’s public publication page lists the Rules and Regulations for the Classification of Ships dated 1 July 2026 and directs readers to Regs4ships. This article verifies that publication information; it does not claim a clause-by-clause review of the 2026 rule text. For an LR-classed vessel, identify the applicable edition, effective amendments, notices and project instructions with LR.
10.3 IEC 62443
IEC 62443-3-2:2020 provides the supporting industrial-control-system methodology for partitioning a system under consideration into zones and conduits, assessing risk and documenting target security levels. IEC 62443-3-3:2013 provides detailed system security requirements used with defined zones and conduits. These standards are supporting references; the governing marine compliance basis remains IACS UR E26, the applicable Class Rules and Society decisions.
IACS UR E26 provides a common minimum baseline. Within their implementation of that baseline, Classification Societies may differ in document codes, accepted formats, treatment of inter-zone non-IP communication, evidence expected for segmentation, acceptance of equivalent boundary devices and commissioning-test depth. Interpretations affecting architecture, scope or acceptance should be agreed with the vessel’s Society.
11. Practical Review Appendices
12. Conclusion
The Zones and Conduit Diagram is the central architectural document for vessel-level cyber resilience under IACS UR E26. It establishes the applicable security zones, CBS allocation, physical implementation, boundary-crossing communication, untrusted-network interfaces and the traceability linking Supplier information, ship-level design and verification evidence.
A compliant ZCD begins with accurate scope identification and Supplier data. It requires defensible zone-allocation criteria, correct physical or logical segmentation, complete interface analysis and controlled conduit definition. It must remain consistent with the Vessel Asset Inventory, CSDD, exclusion assessments, compensating countermeasures and Ship Cyber Resilience Test Procedure.
The quality of the final ZCD should be assessed against four questions:
- Does it represent the correct scope?
- Does it describe a defensible security architecture?
- Does it match the installed and tested vessel?
- Can the Shipowner maintain and use it throughout the operational survey cycle?
A ZCD that satisfies all four questions is more than a plan-approval drawing. It is the controlled architectural baseline for vessel cyber resilience.
Series Navigation
The CRSI Role and Six Core Ship-Level Deliverables
Systems Integrator responsibilities, lifecycle baseline and the six-document framework.
Zones and Conduit Diagram
Security-zone architecture, segmentation, conduit scope and lifecycle verification.
Cyber Security Design Description
Communication controls, security design rationale and requirement traceability.
Vessel Asset Inventory
Asset scope, Supplier integration, Rec.190 structure and lifecycle updates.
Risk Assessment for the Exclusion of CBSs
Exclusion criteria, evidence, risk methodology and approval basis.
Description of Compensating Countermeasures
Capability gaps, equivalent protection, implementation ownership and testing.
Ship Cyber Resilience Test Procedure
Test selection, acceptance criteria, evidence and survey-cycle maintenance.
References
- International Association of Classification Societies, UR E26 Rev.1: Cyber Resilience of Ships, November 2023, particularly §§1.3, 2, 4.1.1.3.1, 4.2.1, 4.2.2, 4.4.2–4.4.3, 5 and 6.4. Rev.1 PDF hosted by ClassNK.
- International Association of Classification Societies, UR E27 Rev.1: Cyber Resilience of On-board Systems and Equipment, September 2023, particularly §§3.1.1–3.1.3 and Appendix II.
- International Association of Classification Societies, UR E22 Rev.3 Corr.1: Computer-based Systems, September 2025. Rev.3 Corr.1 PDF hosted by ClassNK.
- ClassNK, Guidelines for Cyber Resilience of Ships, Edition 1.1, 29 August 2025, particularly Chapter 4, §4-2. Edition 1.1 PDF; UR E26/27 Q&A, Q99.
- Lloyd’s Register, Rules and Regulations for the Classification of Ships, public listing for the edition dated 1 July 2026, checked 5 October 2026; rule text available through Regs4ships. Publication information only.
- International Electrotechnical Commission, IEC 62443-3-2:2020 — Security risk assessment for system design.
- International Electrotechnical Commission, IEC 62443-3-3:2013 — System security requirements and security levels.
About the Author
Woojin Lee specializes in maritime and IoT security with expertise spanning multiple ISO standards and compliance frameworks, including IACS UR E26/E27, ISO 27001, ISO 27701, ISO 42001, and ISMS-P. Woojin brings technical depth in automation cybersecurity engineering and privacy advisory services, holding an M.S. in Computer Software Engineering from Korea University and a B.S. in Software Engineering from Lancaster University (Upper Second Class Honours). Recognitions include the Outstanding Paper Award at the Korea Blockchain Academic Conference (2021) and the Grand Prize at the Korea Financial Security Institute (2022).
GitHub: https://github.com/lwjace
Meet Woojin and the ShipJobs Crew: https://www.shippauljobs.com/p/202601-crew-behind-shipjobs-ship-ai.html
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment