The IACS UR E26 Design Approach: Risk-Based Segmentation for Newbuilds
While the Three-Zone model offers a pragmatic solution for existing vessels, vessels subject to IACS Unified Requirement E26 (in force since July 2024 for newbuilds) must implement a deliberate, risk-based segmentation strategy beginning at the initial design stage.
This guide details the compliance-driven approach required to satisfy IACS UR E26, ensuring that your vessel’s security architecture is built around isolating Essential Services and minimizing risk propagation.
TAGSIA Tags: IACS UR E26 (3.1, 3.2); IEC 62443-3-3 SR 1 (Zones & Conduits); IACS UR E27
1. The Design Mandate: Risk-Based Zoning of Essential Services
IACS UR E26 mandates that the ship’s OT network security be built around a formal Risk Assessment that determines Security Zones based on the criticality of the services they provide. The design must prove that the compromise of a non-essential system cannot cascade into a failure of an Essential Service.
- Risk-Based Grouping (Control 3.1): Systems that share similar security and criticality requirements can be grouped into a single Security Zone. This allows for an efficient and manageable architecture.
- Focus on Isolation: While grouping is permitted, the central requirement is that functional groups with significantly different security needs—especially those providing Essential Services (Navigation, Propulsion, Power Management)—must be isolated from non-essential systems (like IT).
- The E26/E27 Relationship: E26 (Vessel Level) requires the overall segmentation plan and risk assessment, while E27 (System Level) governs the security requirements of the specific equipment (assets) within each zone, holding the OEMs accountable.
2. Identifying Security Zones: Isolation of Essential Services
IACS UR E26 requires that systems be grouped into Security Zones based on a risk assessment, with the primary goal of ensuring the isolation and integrity of Essential Services. Systems with different functional roles and security requirements must be isolated from each other via secure conduits.
The following functional groups are commonly established as distinct, isolated Security Zones in E26-compliant designs to prevent cross-system compromise:
| Functional Group | Primary Goal of Segmentation (Risk Mitigation) | Reason for Isolation (Example Risk) |
| Navigation & Bridge Systems | Ensure integrity of position, route planning, and collision avoidance. | Isolation prevents spoofing/jamming attacks from spreading to control systems. |
| Propulsion & Machinery Control | Guarantee safe command and control of the main engine and steering. | Isolation prevents IT-borne malware from triggering loss of maneuverability. |
| Power Management (PMS/IAS) | Maintain continuous, stable power supply to all critical loads. | Isolation prevents compromise from causing system-wide blackouts. |
| Safety & VDR/GMDSS | Protect essential safety, communication, and evidence capture systems. | Isolation ensures emergency systems remain available during a breach. |
| Vessel Administration & Crew IT | Isolate primary ingress points (email, internet) from all operational systems. | Isolation limits the attack vector from a phishing or internet-based threat. |
3. Securing the Conduits: The Critical Link
In the E26 approach, the Conduits (the connections between zones) are where the security policy is strictly enforced. The design must specify how communication is restricted and monitored.
- Deny-by-Default Policy: All firewalls and routers separating zones must be configured to block all traffic unless explicitly required (e.g., allow read-only data for PMS monitoring only).
- Data Flow Analysis: A data flow analysis is required to prove that only necessary information (like operational status or health metrics) is passed between zones. This is critical for demonstrating compliance with the risk assessment.
- Security Level Enforcement: A Conduit connecting a high-criticality zone (e.g., Propulsion, required to be IEC 62443 Security Level 2 or 3) must be designed to enforce that higher security level, ensuring data integrity and preventing spoofing.
4. Documentation and Auditable Evidence
Compliance with E26 segmentation requires extensive, auditable documentation that must be prepared and maintained throughout the design and construction process.
- System Definition Document: A formal document for each critical system defining its boundaries, components, interfaces, and required security levels (feeding into E27).
- Zone & Conduit Diagram: A detailed, version-controlled schematic showing all defined zones, the specific hardware acting as the conduits (firewalls, routers), and the allowed ruleset between them.
- Risk Mitigation Proof: Documentation proving that the chosen segmentation mitigates the risks identified in the initial assessment (e.g., proving that a compromise of the Admin Zone cannot affect the Propulsion Zone).
Crucial Takeaway for Newbuilds: Segmentation must be driven by a risk assessment that dictates the necessary isolation of Essential Services. This is about compliance and safety assurance, not simply network design.


