
# Post 2/17 — Security Zones & Network Segmentation
🚢 If your propulsion control system can "talk" to your cargo management software, you may have a classification problem — and a cyber risk problem.
**What UR E26 §4.2.1 Requires**
Every Computer-Based System in scope must be assigned to a defined security zone with a documented policy. Zones must be isolated or connected only through controlled conduits — and only traffic explicitly permitted in the Cyber Security Design Description may cross a zone boundary. This Zones and Conduit Diagram is a formal design document submitted for Society approval, not an internal reference.
**Maritime-Specific Implications**
Ships operate in a uniquely constrained environment: minimal IT staff, remote locations, and systems that cannot simply be taken offline for patching or reconfiguration. UR E26 §4.2.1 mandates that safety-critical systems — propulsion, steering — reside in physically separate zones. Navigation must never share a zone with machinery or cargo systems. Wireless devices require their own dedicated zones. Critically, zone isolation must be achievable without disrupting primary CBS functionality within that zone — so the design must account for operational realities from day one.
**IEC 62443 Technical Depth**
E26 §4.2.1 directly implements the IEC 62443-3-2 §5.2 zone/conduit methodology at vessel level. In IEC 62443, zones are defined by shared security requirements and risk profile — not physical location alone. Each conduit connecting zones must carry an explicit security policy governing permitted traffic, protocol, and direction. This is foundational: zone definition in IEC 62443-3-2 is the primary risk-reduction mechanism before any individual control requirement (SR) is applied — get the zone boundaries wrong, and every downstream control is undermined.
**UR E27 Connection**
E27 §3.1.2 requires equipment suppliers to provide system topology diagrams — these feed directly into the vessel-level Zones and Conduit Diagram required under E26. Additionally, E27 SR 7.6 (referenced in E26 Appendix II) requires that CBS connected to untrusted networks expose readable security configuration settings, enabling crew to verify zone boundary controls without needing specialist tools. The layered relationship is clear: E27 handles what the component must deliver; E26 defines how it integrates into the vessel's security architecture.
**Implementation Insight**
One of the most common gaps in shipyard practice: the Zones and Conduit Diagram is built for class approval but not maintained as a living document. Annual survey requires demonstrating that zone boundaries match the approved design. Integrators should establish a formal change management process so that any network modification — even a temporary maintenance connection — is reviewed against the approved diagram before implementation.
**What's your experience with maintaining zone boundary integrity through a vessel's operational lifecycle — particularly after refit or system upgrades?**

📌 Post 2/17 in my IACS UR E26 series — breaking down all 17 requirements across the Identify → Protect → Detect → Respond → Recover framework
'Security > Maritime Cyber Security' 카테고리의 다른 글
| [IACS UR E26] Protect – 04 Antivirus, Antimalware & Malicious Code Protection (0) | 2026.05.28 |
|---|---|
| [IACS UR E26] Protect – 03 Network Protection Safeguards (0) | 2026.05.28 |
| [IACS UR E26] Identify – 01 Vessel Asset Inventory (0) | 2026.05.27 |
| [IACS UR E27] Untrusted Network – 41 Session ID Invalidation after Termination (0) | 2026.05.26 |
| [IACS UR E27] Untrusted Network – 40 Session Integrity (0) | 2026.05.26 |