A ShipJobs practical guide based on real-world implementation experience

Practical Applications of Ship Security Zones: 10 Pitfalls and How to Avoid Them

Introduction: The Security Zone Paradox

When IACS UR E26 Section 4.2.1 mandates that "all CBSs in the scope of applicability shall be grouped into security zones," it sounds straightforward enough. The requirement seems clear: organize your systems, segment your networks, protect the boundaries. Simple, right?

Not quite.

After working with shipyards, system suppliers, and shipowners across multiple E26 implementation projects, we've observed a recurring pattern: what appears simple in the standard becomes remarkably complex in practice. The gap between regulatory text and operational reality has created a minefield of misconceptions, costly mistakes, and retrofit nightmares.

This article examines the ten most common pitfalls we've encountered in security zone implementation—and more importantly, how to avoid them.

The Fundamental Misunderstanding

Before diving into specific pitfalls, let's address a fundamental issue that underlies many problems: confusion about what security zones actually are.

UR E26 defines a security zone as:

"A collection of CBSs in the scope of applicability of this UR that meet the same security requirements. Each zone consists of a single interface or a group of interfaces, to which an access control policy is applied."

Sounds technical. But here's what this actually means in plain language:

A security zone is NOT primarily about physical network segments. It's about grouping systems with similar security needs so they can be protected and managed consistently.

This distinction matters because it reveals why so many implementations go wrong: teams focus on network topology while neglecting security policy.

content

Pitfall #1: "One Network = One Zone"

Pitfall #2: Too Many Zones

Pitfall #3: Ignoring the Wireless Wild West

Pitfall #4: The "Air Gap" Illusion

Pitfall #5: Forgetting "Untrusted Networks"

Pitfall #6: Static Documentation for Dynamic Systems

Pitfall #7: Boundary Protection as an Afterthought

Pitfall #8: Neglecting Human Factors

Pitfall #9: Ignoring Existing Installations (Retrofit Denial)

Pitfall #10: Treating E26 as a Checkbox

Pitfall #1: "One Network = One Zone"

The Mistake

The most common error we see: treating network segments and security zones as synonymous. Teams create VLAN 10, call it "Security Zone 1," and assume they're done.

Why It Happens

Network engineers naturally think in terms of subnets and VLANs
Vendors deliver systems with predefined network configurations
The term "network segmentation" appears throughout E26, creating confusion
Traditional IT security often does equate zones with network segments

The Reality

A single network segment might contain systems with vastly different security requirements:

Example: Engine Room Network (10.50.1.0/24)

├─ Main Engine Control (Cat III, essential service)
├─ Auxiliary Engine Monitoring (Cat II)  
├─ Fuel Oil Treatment (Cat II)
├─ Bilge Alarm Panel (Cat II)
└─ Engine Room CCTV (Cat I, out of scope)

Should these all be in the same security zone? According to our interpretation of E26's requirements: No.

The main engine control system needs:

Highest protection level (Cat III)
Strictest access controls
Independent operation capability (UR E26 4.4.2)
Ability to isolate without affecting essential services

Putting it in the same zone as CCTV cameras makes no sense from a security perspective.

The ShipJobs Approach

Zone by security requirements, not by physical location.

Design zones based on:

System category (I, II, III per UR E22)
Criticality to ship operations
Required isolation capabilities
Common access control policies
Shared security characteristics (from UR E27)

Then map these logical zones onto your physical network—not the other way around.

Case Study: The Retrofit Disaster

A shipyard delivered 8 container vessels with "security zones" that were simply renamed VLANs. During the first Annual Survey, the Classification Society identified 23 non-conformities because:

Essential systems couldn't be isolated independently
Zone boundaries didn't align with security policies
Cat III systems shared zones with Cat II systems
No clear isolation strategy for cyber incidents

The cost: Complete network redesign on all 8 vessels. Timeline: 18 months. Budget impact: €2.4M beyond original contract.

Could this have been avoided? Absolutely. By designing zones based on security requirements from the start.

Pitfall #2: Too Many Zones

The Mistake

In reaction to Pitfall #1, some teams swing to the opposite extreme: creating dozens of micro-zones, each containing just one or two systems.

We've seen zone diagrams with 40+ zones on a single vessel. One ambitious project defined 63 zones across a fleet of 6 ships.

Why It Happens

Misinterpreting "defense in depth" to mean "maximum isolation"
Each supplier wanting "their own zone" for liability reasons
Belief that more zones = more security
Confusion between security zones and network segments

The Reality

More zones don't automatically mean more security—they mean more complexity.

Each additional zone creates:

More firewall policies to maintain
More boundary protection devices to manage
More potential points of misconfiguration
More documentation to maintain
More complexity for crew operations
Higher cost (more equipment, more labor)

UR E26 doesn't require isolated zones for every system. It requires that systems with similar security needs be grouped together and protected appropriately.

The Hidden Cost

Consider the operational burden:

Scenario: Security Update Rollout


6 Zones:
- 6 firewall devices to update
- 6 sets of rules to verify  
- 6 isolation tests to perform
- Manageable in 1-2 days

40 Zones:  
- 40 firewall devices to update
- 40 sets of rules to verify
- 40 isolation tests to perform
- Requires 2+ weeks
- High risk of errors

One shipowner told us: "We designed for maximum security but ended up with minimum maintainability. The crew can't manage it, suppliers can't troubleshoot it, and our OPEX is through the roof."

The ShipJobs Approach

Optimize for the minimum necessary zones, based on:

Distinct security requirements (not just "nice to have" separation)
Operational independence needs (UR E26 4.4.3)
Criticality tiers (essential vs. non-essential services)
Regulatory mandates (navigation ≠ machinery per E26 4.2.1.3)
Practical maintainability (crew capability, cost, complexity)

Our typical design: 4-8 zones for most commercial vessels, rarely exceeding 12 even for complex ships.

Case Study: The Over-Engineered LNG Carrier

Initial design: 47 security zones Firewall rules: 2,340+ Documentation: 890 pages of zone specifications

First-year operations:

18 cyber-related alarms (all false positives)
6 incidents of crew accidentally isolating critical systems
3 supplier interventions requiring remote access (each taking 4+ hours due to zone complexity)

Re-design to 9 zones:

Firewall rules: 340
Documentation: 140 pages
False positive rate: reduced by 85%
Remote access time: reduced to <1 hour
Annual maintenance cost: reduced by 60%

Pitfall #3: Ignoring the Wireless Wild West

The Mistake

Treating wireless networks as an afterthought, or worse, ignoring the E26 requirement that "wireless devices shall be in dedicated security zones" (4.2.1.3).

Why It Happens

Wireless infrastructure often added late in the build process
Multiple suppliers installing their own wireless access points
Crew bringing personal WiFi routers onboard
Bluetooth devices proliferating without documentation
"It's just WiFi, how dangerous could it be?"

The Reality

Wireless networks are inherently more vulnerable than wired networks (UR E26 4.2.5.2 acknowledges this). Every wireless access point is a potential entry vector.

What we commonly find on vessels:

Undocumented Wireless Networks:

├─ Engine monitoring system (supplier-installed)
├─ HVAC control (different supplier, different WiFi)
├─ Cargo monitoring (yet another isolated WiFi)
├─ Crew welfare network (IT department)
├─ Guest network (captain's initiative)  
├─ Multiple personal hotspots (crew phones)
└─ Bluetooth devices (uncountable)

None of these are in documented security zones. All violate E26 requirements. Each represents a gap in the ship's cyber resilience.

The Consequences

Real incident from our case files (details anonymized):

A container vessel's steering system experienced unexplained intermittent failures. Investigation revealed:

Supplier had installed wireless transmitters for rudder angle sensors
Crew had installed a personal WiFi router nearby for better cabin coverage
The router was on the same frequency
Interference caused packet loss → steering anomalies

Not a cyber attack, but a violation of E26 wireless requirements that created a safety risk.

The ShipJobs Approach

Wireless-First Zone Design:

Inventory ALL wireless:
- Document every radio transmitter (WiFi, Bluetooth, proprietary)
- Include supplier equipment, IT infrastructure, crew devices
- Map frequencies and coverage areas
- Identify all wireless-enabled components in CBS
Dedicated wireless zones (not optional, it's required):

Wireless Zone Architecture:

   
   Zone W1: OT Wireless (isolated)
   └─ Engine/machinery wireless sensors
   └─ Controlled by OT security policies
   └─ No dual-homed devices (E26 4.2.5.3)
   
   Zone W2: Navigation Wireless (isolated)  
   └─ Navigation system wireless components
   └─ Separate from OT and IT
   
   Zone W3: Crew/Guest WiFi (untrusted)
   └─ Internet-connected only
   └─ Physically segmented from all OT zones
   └─ Encrypted (WPA3) per E26 4.2.5.3

Strict policies:
- No unauthorized wireless devices
- All wireless in asset inventory (UR E26 4.1.1)
- Regular wireless scanning (detect rogue APs)
- Encryption mandatory (UR E26 4.2.5.3)
Physical and logical separation:
- Wireless devices cannot be "dual-homed" (E26 4.2.5.3 explicit requirement)
- No wireless to wired bridging without zone boundary protection
- Regular audit of wireless spectrum

Case Study: The Hidden WiFi

Classification Society survey discovered 14 undocumented wireless access points during a Special Survey. Systems integrator had no records. Suppliers had installed them "for convenience" during commissioning.

Result: Vessel detained, 6-week delay, €450K in costs (surveyor time, fixes, re-testing, schedule disruption).

Prevention cost would have been: Comprehensive wireless inventory and proper zone allocation during design phase. Estimate: €15K.

Pitfall #4: The "Air Gap" Illusion

The Mistake

Believing that physical disconnection ("air gapping") automatically creates a secure zone boundary—and that air-gapped systems don't need zone documentation.

Why It Happens

"If it's not connected, it's not vulnerable" mentality
Confusing "isolated" with "air-gapped"
Assuming air gaps are permanent
Underestimating indirect connection vectors

The Reality

True air gaps are rare and difficult to maintain. What teams call "air-gapped" is often just "temporarily disconnected."

Common "air gap" scenarios that aren't:

Scenario 1: The Maintenance Laptop

System: "Air-gapped" ballast control system
Reality: Service engineer connects laptop for diagnostics every 3 months
Vector: Laptop has been to 40 other ships, multiple shore facilities
Status: Not air-gapped, just periodically connected

Scenario 2: The USB Update
System: "Air-gapped" main engine ECU  
Reality: Software updates via USB stick from shore
Vector: USB stick used on shore computers, other ships
Status: Not air-gapped, indirect connection via removable media

Scenario 3: The "Temporary" Connection
System: "Air-gapped" cargo system
Reality: Connected to office network for "one-time" data export
Vector: "Temporary" cable still installed, used monthly
Status: Not air-gapped, intermittently connected

UR E26 recognizes this: Systems that are "air-gapped" but receive maintenance or updates via removable media are still subject to malware protection requirements (4.2.3), access control (4.2.4), and mobile device controls (4.2.7).

The ShipJobs Approach

Honest Assessment of "Air Gaps":

Challenge every air gap claim:
- How are software updates delivered?
- How is maintenance performed?
- Are there any removable media interfaces?
- Any "temporary" connections for commissioning/testing?
- Any wireless capabilities (even if "disabled")?
Document air gaps properly:
- If truly air-gapped → still document as a zone
- Specify how the gap is maintained
- Define procedures for any breaches (updates, maintenance)
- Implement compensating controls (UR E27 Section 2.4)
Design for reality, not theory:

 Instead of: "Air-gapped, no security measures needed"
   
   Design for:  
   ├─ Removable media controls (UR E26 4.2.4.3.4)
   ├─ Malware scanning before media insertion (E26 4.2.3)
   ├─ Portable device restrictions (E26 4.2.7)
   ├─ Procedures for "temporary" connections
   └─ Access control for physical interfaces

When air gaps make sense:
- Cat III systems where network connection isn't operationally necessary
- Systems with very infrequent update requirements
- Systems where the cost of network security exceeds air gap cost
- Legacy systems where adding network security is impractical
But: Document them, protect them, manage them as zones.

Case Study: The "Isolated" DP System

DP Class 3 system delivered as "air-gapped from all networks for maximum security."

Reality discovered during commissioning:

Redundant workstations connected to ship network for "data logging"
Service USB ports accessible in public corridor
WiFi adapter installed (disabled in software) for "future use"
Bluetooth enabled for "wireless keyboard option"

Not remotely air-gapped. Required complete re-design to either:

True air gap (remove all connection capability), OR
Proper network zone integration with boundary protection

Shipowner chose option 2. Cost: €180K redesign + 4-week delay.

Lesson: If you're going to claim air gap, commit fully. Otherwise, design proper zone integration from the start.

Pitfall #5: Forgetting "Untrusted Networks"

The Mistake

Focusing all zone design on internal ship systems while neglecting the boundary between ship and shore—what E26 calls "untrusted networks."

Why It Happens

Zone design starts with ship systems (the familiar)
Shore connections added later ("just IT stuff")
Misconception that untrusted networks are IT department's problem
Underestimating OT systems' shore connectivity

The Reality

More OT systems connect to shore than most people realize:

Typical Vessel's Shore Connections:


1. Remote Monitoring
   ├─ Engine performance monitoring
   ├─ Fleet management system
   ├─ Condition-based maintenance
   └─ Fuel optimization

2. Remote Maintenance  
   ├─ Supplier diagnostic access
   ├─ Software updates/patches
   ├─ Configuration changes
   └─ Emergency support

3. Data Exchange
   ├─ Noon reports
   ├─ Cargo data integration
   ├─ Compliance reporting  
   └─ Weather routing

4. "Smart Ship" Services
   ├─ Predictive analytics
   ├─ Digital twin data feeds
   ├─ AI-based optimization
   └─ Cloud-based platforms

Every one of these is an interface to an untrusted network and must be documented and protected per UR E26 Section 4.2.6.

E26 is explicit:

"For CBSs in the scope of applicability of this UR, no IP address shall be exposed to untrusted networks." (4.2.6.3)

The Consequences

We reviewed a Zones and Conduit Diagram for a new VLCC. It showed beautiful internal zone architecture but had a single box labeled "Shore Connection" with no details.

During detailed review:

14 different OT systems had shore connectivity
6 different VPN solutions in use
3 systems exposed public IP addresses directly
No consistent firewall policy
Zero documentation of how this complied with E26 4.2.6

Classification Society: "This is not approvable. Re-submit with compliant design."

The ShipJobs Approach

Untrusted Network Interface as Primary Design Concern:

Inventory all shore connectivity:

For Each CBS in Scope:

   ├─ Does it connect to shore? (even indirectly)
   ├─ How? (VPN, direct, satellite, mobile data)
   ├─ For what purpose?  
   ├─ What data flows?
   ├─ How often?
   ├─ Who initiates? (ship or shore)
   └─ Who has remote access?

Consolidated shore interface:

Recommended Architecture:

   
   Untrusted Network (Internet/Shore)
           |
           ↓
   [DMZ Zone] - Zone Boundary Protection
      ├─ VPN concentrator
      ├─ Firewall (explicit rules per E26 4.2.6.3)
      ├─ Intrusion detection  
      └─ Connection logging
           |
           ↓
   [Shore Interface Zone] - Internal boundary
      ├─ Jump server / bastion host
      ├─ Multi-factor authentication (E27 item 31)
      ├─ Session recording
      └─ Explicit approval mechanism (E26 4.2.6.3.1)
           |
           ↓
   Individual OT Security Zones

Case Study: The Vendor VPN Nightmare

Shipowner discovered (during cyber incident investigation) that 8 different equipment suppliers had "permanent" VPN connections to ship systems. Some had been active for years without shipowner knowledge.

Compliance violations:

No explicit access approval mechanism
No session termination capability from ship
No multi-factor authentication (several used default passwords)
No logging of remote access events
IP addresses exposed to untrusted networks

Result: Complete remote access redesign across 24-vessel fleet. Cost: €1.2M + 8 months.

Root cause: Shore connectivity treated as "vendor's responsibility" rather than integrated into zone design.

Pitfall #6: Static Documentation for Dynamic Systems

The Mistake

Creating beautiful Zones and Conduit Diagrams during newbuild—then never updating them as the ship evolves.

Why It Happens

E26 is new; update procedures not yet established
Assumption that zones are "set and forget"
Management of Change (MoC) processes don't trigger zone diagram updates
No clear owner for maintaining zone documentation
Updates are tedious and time-consuming

The Reality

Ships are living systems. Over a vessel's 20-25 year life:

Systems are upgraded
New equipment is added
Network configurations change
Suppliers install "temporary" connections that become permanent
Software updates alter network behavior
Wireless devices proliferate

UR E26 4.1.1.3 is explicit:

"The inventory shall be kept updated during the entire life of the ship. Software and hardware modifications potentially introducing new vulnerabilities or modifying functional dependencies or connections among systems shall be recorded in the inventory."

This applies equally to the Zones and Conduit Diagram—it's part of the vessel asset inventory.

The Consequences

First Annual Survey scenario:

Surveyor: "Please show me the current Zones and Conduit Diagram." Ship: Produces diagram from delivery 2 years ago Surveyor: Walks to engine room, finds new monitoring system installed 6 months ago "Is this in your diagram?" Ship: "Uh... probably not?" Surveyor: "Show me how this system is allocated to a security zone." Ship: Cannot

Result: Non-conformity. Must update diagram, re-verify zone allocation, potentially re-test boundary protection. Survey delayed.

The ShipJobs Approach

Living Documentation Strategy:

Assign clear ownership:

Documentation Responsibility Matrix:

   
   During Newbuild:
   └─ Systems Integrator owns and maintains
   
   After Delivery:
   ├─ Fleet IT/OT Manager: overall ownership
   ├─ Ship's Master: verification of accuracy
   ├─ Superintendent: approval of changes
   └─ DPA: integration with SMS

MoC triggers for zone updates:

Any of these trigger zone diagram review:

   ├─ New CBS installation
   ├─ CBS upgrade/modification
   ├─ Network configuration changes
   ├─ New shore connectivity
   ├─ Wireless device addition
   ├─ Software updates affecting network behavior
   └─ "Temporary" connections exceeding 30 days

Version control discipline:
- Date stamp all diagrams clearly
- Version number (major.minor):
  - Major: new zones, zone reallocation
  - Minor: updates within existing zones
- Change log: what changed, when, why, by whom
- Annual review even if no changes
Lightweight update process: Don't require full re-submission to Class for minor updates. Instead:

Update Process:

   
   Minor Changes (within existing zones):
   ├─ Update diagram internally
   ├─ Document in change log
   ├─ Present at next Annual Survey
   └─ No pre-approval required
   
   Major Changes (new zones, re-allocation):
   ├─ Update diagram
   ├─ Submit to Classification Society
   ├─ Await approval
   └─ Implement
   
   Emergency Changes (safety/security critical):
   ├─ Implement immediately if needed
   ├─ Document thoroughly  
   ├─ Submit to Class within 30 days
   └─ Regularize at next survey

Digital tools:
- Use editable format (not just PDF)
- Consider network diagramming tools (Visio, Lucidchart, draw.io)
- Maintain source files on ship and shore
- Cloud backup (in secure, controlled manner)

Case Study: The Well-Maintained Fleet

One shipowner we work with has 18 LNG carriers. Their approach:

Zones and Conduit Diagrams in SharePoint (version controlled)
Fleet-wide monthly review call (30 min, all vessels)
Any changes discussed, diagram updates coordinated
Quarterly consolidated submission to Classification Society
Annual audit by independent consultant (us)

Result over 3 years:

Zero Annual Survey delays due to zone documentation
Rapid incident response (accurate diagrams enable faster troubleshooting)
Proactive identification of configuration drift
Estimated cost savings: €500K+ vs. reactive approach

Key insight: "The diagram is not a deliverable, it's a living tool. We use it weekly for troubleshooting, planning, and training. Of course we keep it updated."

Pitfall #7: Boundary Protection as an Afterthought

The Mistake

Designing zone architecture meticulously, then treating the actual boundary protection (firewalls, routers, diodes) as "implementation details" to be figured out later.

Why It Happens

Separation of responsibilities (network architect vs. installation team)
"We'll specify firewall during procurement"
Budget pressure (boundary devices are expensive)
Assumption that "any firewall will do"
Not understanding E26's specific requirements

The Reality

UR E26 4.2.1 states:

"Security zones shall either be isolated (i.e. air gapped) or connected to other security zones or networks by means providing control of data communicated between the zones (e.g. firewalls/routers, simplex serial links, TCP/IP diodes, dry contacts, etc.)"

Note "providing control of data communicated"—not just "separated by." There are specific technical requirements for boundary protection:

From E26 4.2.2:

Firewalls or equivalent means
Protection against excessive data flow rate (DoS)
Principle of Least Functionality

From E26 4.2.1.1:

Only explicitly allowed traffic shall traverse

This requires:

Explicit firewall rules (not default-allow)
DoS protection capability
Traffic monitoring/logging
Management interface security

The Consequences

Common scenario:

Zones and Conduit Diagram shows 6 zones with 12 conduits (zone-to-zone connections). Approved by Classification Society during design review.

FAT time: "What firewall will you use for these boundaries?"

Systems Integrator: "We... haven't specified that yet. Can we use [commercial IT firewall brand]?"

Issue: Commercial IT firewall may not meet:

OT network requirements (deterministic performance)
Environmental qualifications (UR E10)
DoS protection requirements for OT traffic
Visibility into OT protocols
Available port count/bandwidth

Result: Emergency procurement, schedule delay, potential redesign of zone boundaries to fit available equipment.

The ShipJobs Approach

Boundary Protection as Core Design Element:

Specify boundary protection during zone design:

For Each Conduit (zone boundary):

   ├─ What data must traverse? (protocols, rates, direction)
   ├─ What protection level is needed?
   │   ├─ Stateful firewall
   │   ├─ Application-aware firewall  
   │   ├─ Data diode (unidirectional)
   │   └─ Protocol gateway/proxy
   ├─ What performance is required? (latency, throughput)
   ├─ What environmental rating? (UR E10)
   └─ What management capability? (local, remote, none)

Early vendor engagement:
- Identify suitable products during design
- Verify technical specifications match requirements
- Confirm availability and lead time
- Get budget pricing
- Don't wait until procurement phase
Firewall rule specification: Poor approach: "Firewall between Zone 1 and Zone 2" ShipJobs approach:

Conduit C1: Engine Control Zone → Monitoring Zone

   
   Allowed Traffic:
   ├─ MODBUS TCP: Engine ECU (10.1.5.10) → Monitoring Server (10.2.1.20)
   │   Port: 502, Direction: Unidirectional (data diode)
   ├─ OPC UA: Engine Sensors (10.1.5.0/24) → HMI (10.2.1.15)
   │   Port: 4840, Direction: Monitored reads only
   └─ NTP: Monitoring NTP Server (10.2.1.5) → All Engine Zone devices
       Port: 123, Direction: Inbound to Zone 1 only
   
   Denied: All other traffic (default deny)
   
   DoS Protection: Rate limit 100 Mbps, 10,000 pps
   
   Logging: All denied connection attempts
   
   Hardware: Industrial firewall, -25 to +55°C rated

Testing boundary protection (critical for FAT):
- Verify explicit allow rules work
- Verify default deny (attempt prohibited traffic)
- Verify DoS protection (flood test)
- Verify logging functionality
- Document results
Types of boundary protection: Know when to use each: Firewall (most common):
- Bidirectional traffic needed
- Complex rule sets
- Multiple protocols
- Example: Navigation Zone ↔ Monitoring Zone
Data Diode (unidirectional):
- Monitoring only (no control back)
- Highest security requirement
- Defense in depth
- Example: Engine Control → Shore Monitoring
Protocol Gateway:
- Protocol translation needed
- Deep packet inspection required
- Example: Proprietary protocol → Standard protocol
Physical Isolation (air gap):
- No network communication required
- Highest security + operational independence
- Example: Emergency systems

Case Study: The Firewall Bottleneck

New build specified 8 security zones requiring 14 boundary protection devices (firewalls). Design approved.

Procurement phase: Selected low-cost IT firewalls not rated for marine environment.

Commissioning: Firewalls failed environmental testing (vibration, temperature, EMI).

Emergency re-procurement of industrial-grade firewalls: €180K additional cost, 6-week delay.

Prevention: Specify environmental and technical requirements for boundary protection during zone design, not during procurement.

Pitfall #8: Neglecting Human Factors

The Mistake

Designing technically perfect zone architecture that the crew cannot operate or maintain.

Why It Happens

Engineers design for technical elegance, not operational simplicity
Underestimating crew workload and cyber security competence
Not involving ship personnel in design process
Assuming shore support will handle everything
Forgetting E26 must work 24/7/365 in all conditions

The Reality

Ship crews are not cyber security experts. They're navigators, engineers, deck officers with:

Minimal cyber training (slowly improving)
High workload (especially short-handed vessels)
Responsibility for vessel safety (cyber security is one of many concerns)
Limited shore support (especially in transit)

UR E26 4.4.3.3 requires:

"There shall be available instructions and clear marking on the device that allows the personnel to isolate the network in an efficient manner."

This implies: Crew must be able to operate zone isolation during an incident.

But if your zone architecture requires:

Logging into 6 different firewall management interfaces
Understanding complex network topology
Making critical decisions about which zones to isolate
Technical knowledge beyond typical crew training

Your crew cannot execute E26 response procedures effectively.

The Consequences

Real incident (anonymized):

Vessel experienced suspected cyber incident (unusual network traffic). Incident Response Plan said: "Isolate affected security zone."

Chief Engineer attempted to isolate zone per procedure. Couldn't determine which firewall controlled which zone. Accidentally isolated wrong zone. Disrupted ballast system during cargo operations.

Result: Near miss (stability issue), investigation, procedure revision, crew retraining.

Root cause: Zone architecture designed without crew input, overly complex for shipboard operation.

The ShipJobs Approach

Design for Human Operation:

Crew involvement in design:
- Review Zones and Conduit Diagram with Master, Chief Engineer
- Explain what each zone does, why it exists
- Walk through isolation procedures
- Get their input: "Can you operate this?"
Simplicity as a design principle:

Technical Perfection vs. Operational Reality:

   
   Option A: 12 zones, maximum isolation
   └─ Crew cannot determine which zone is affected during incident
   
   Option B: 6 zones, operational clarity
   └─ Crew can quickly identify and isolate affected zone
   
   Choose Option B.

Clear labeling and documentation:
- Physical labels on firewalls: "Engine Zone Firewall"
- One-page laminated poster: Zone diagram with isolation instructions
- Color coding (optional but helpful)
- Located near network equipment, not buried in a manual
Isolation procedures that work:

Poor procedure:

   "Isolate Security Zone 3 by accessing firewall management 
   interface at https://192.168.100.5, login with admin 
   credentials, navigate to Zone Policies > Outbound Rules > 
   Disable All"
   
   ShipJobs procedure:
   "ZONE 3 - CARGO SYSTEM ISOLATION
   
   Location: Engine Control Room, port side rack
   
   To Isolate:
   1. Locate firewall labeled 'CARGO ZONE FW'
   2. Press and hold RED button for 5 seconds
   3. Verify 'ISOLATED' LED illuminates
   4. Inform bridge and shore office
   
   To restore:
   1. Press GREEN button
   2. Verify 'CONNECTED' LED illuminates
   3. Test cargo system functions"

Training and drills:
- Include zone isolation in cyber drills
- Practice during commissioning (before delivery)
- Annual refresher
- Document in SMS
Shore support model:
- Crew handles: immediate isolation, basic troubleshooting
- Shore handles: detailed investigation, complex changes, recovery
- Clear escalation criteria

Case Study: The User-Friendly Fleet

One shipowner's fleet cyber security philosophy: "If our crew can't operate it during a typhoon at 3 AM, it's not a good design."

Their zone architecture:

5 zones maximum (regardless of vessel complexity)
Physical isolation switches (not software menus)
Laminated one-page zone diagram at every control station
Monthly drills (5-minute isolation exercises)
Crew feedback loop (quarterly survey on procedures)

Result:

Successful isolation during two actual incidents (malware detected, isolated, contained)
High crew confidence in procedures
Fast incident response (isolation in <2 minutes)
Low false isolation rate

Quote from Master: "I don't need to understand firewalls to protect my ship. The design makes it simple to do the right thing."

Pitfall #9: Ignoring Existing Installations (Retrofit Denial)

The Mistake

Designing "perfect" greenfield zone architecture while ignoring that most of the world's fleet is already built and must retrofit E26 compliance.

Why It Happens

UR E26 examples focus on newbuild scenarios
Retrofit is harder, so teams avoid thinking about it
Assumption that existing vessels are "grandfathered" (they're not, entirely)
Shipyards prefer designing new over fixing old

The Reality

E26 scope (1.3.1) includes ships "contracted for construction on or after 1 July 2024."

But:

Many ships currently under construction were contracted before cutoff
Existing fleet has 20+ years of service life
Charterers increasingly demand E26 compliance
Insurance may require cyber resilience measures
Major conversions may trigger E26 requirements

Retrofitting security zones onto existing vessels is painful:

Network infrastructure already installed (expensive to change)
Systems from multiple suppliers, different eras
Limited space for new equipment
Operational disruptions during retrofit
No "as-designed" documentation (often)

The Real Question

Not "Is E26 mandatory for this vessel?"

But: "How can we achieve cyber resilience given real-world constraints?"

The ShipJobs Approach

Pragmatic Retrofit Strategy:

Assess current state honestly:

Retrofit Assessment:

   ├─ Network discovery (what's actually installed)
   ├─ System inventory (all CBS, not just new ones)
   ├─ Connectivity mapping (understand what talks to what)
   ├─ Identify de facto zones (they exist, even if not designed)
   └─ Document vulnerabilities and gaps

Zone overlay on existing architecture:
- Don't force "ideal" zones onto incompatible infrastructure
- Work with what exists
- Identify minimum necessary changes
- Prioritize based on risk, not perfection
Compensating countermeasures (UR E27 Section 2.4): Example: Cannot physically separate navigation from machinery network without major expense. Instead:
- Logical segmentation (VLANs)
- Enhanced monitoring (IDS)
- Strict access controls
- Procedural controls
- Document as compensating countermeasure
Phased approach:

Phase 1: No/Low-Cost Improvements (immediate)

   ├─ Document existing de facto zones
   ├─ Implement logical segmentation where possible
   ├─ Add firewall rules to existing equipment
   ├─ Enhance access controls
   └─ Update procedures

   Phase 2: Moderate Investment (next drydock)
   ├─ Install boundary protection devices
   ├─ Upgrade critical systems  
   ├─ Add monitoring/logging capability
   └─ Crew training

   Phase 3: Major Changes (special survey/major conversion)
   ├─ Network infrastructure upgrade
   ├─ Full zone architecture implementation
   └─ Approach newbuild standard

Criteria for triggering retrofit:
- Charter requirements
- Insurance requirements
- Operational safety needs
- Major system upgrades (good opportunity)
- Regulatory requirements (if applicable)
- Risk assessment findings

Case Study: The 15-Year-Old Tanker

Owner faced charter requirement for "E26-equivalent cyber resilience" on a 2009-built Aframax.

Initial quote for full retrofit: €1.8M, 60-day drydock.

ShipJobs approach:

Documented existing network (it had logical zones, just not labeled)
Added 4 industrial firewalls at key boundaries (€80K)
Implemented access controls and logging (mostly software/procedures)
Created Zones and Conduit Diagram reflecting actual architecture
Developed Ship Cyber Security Program appropriate for vessel age

Cost: €280K Time: Completed alongside other drydock work, no additional days Outcome: Charterer accepted, Classification Society reviewed positively

Key insight: "The vessel was more cyber resilient than we thought; we just hadn't documented or formalized it. We didn't need to rebuild everything."

Pitfall #10: Treating E26 as a Checkbox

The Mistake

Viewing security zones as a compliance exercise ("get the diagram approved") rather than as a foundation for actual cyber resilience.

Why It Happens

Regulatory pressure to "get certified"
Procurement mentality ("just meet the minimum")
Separation between compliance team and operations team
Not understanding that E26 is about resilience, not just rules
Time/budget pressure

The Reality

UR E26 is titled "Cyber resilience of ships"—not "Cyber compliance of ships."

Resilience means:

"The capability to reduce the occurrence and mitigating the effects of cyber incidents..." (E26 Section 2)

A Zones and Conduit Diagram is not resilience. It's a tool to support resilience by:

Organizing systems for effective protection
Enabling rapid incident response (isolation)
Limiting lateral movement of attacks
Supporting recovery operations
Facilitating ongoing management

If your zones exist only to satisfy a surveyor, they provide no actual security value.

The Mindset Shift

From: "What's the minimum to get approved?" To: "How can zones help us actually defend this ship?"

The ShipJobs Approach

Zones as Operational Tools:

Design zones for actual use cases:

Use Case 1: Malware Detection

   If malware detected in Crew WiFi zone →
   └─ Isolate that zone (already designed for isolation)
   └─ Other zones continue operating
   └─ Incident contained

   Use Case 2: Supplier Remote Access
   Supplier needs access to Engine Control System →
   └─ Connect via dedicated Shore Access Zone
   └─ Jump to Engine Zone only  
   └─ Session logged, monitored
   └─ Can be terminated by crew
   └─ Other zones never exposed

   Use Case 3: System Upgrade
   Upgrading navigation software →
   └─ Isolate Navigation Zone  
   └─ Machinery operations unaffected
   └─ Verify in isolation before reconnecting
   └─ Planned, controlled process

Use zones for operational decisions:
- Where to install new equipment? (Which zone?)
- How to connect this system to shore? (Via which zone?)
- Which systems can be upgraded together? (Same zone)
- What's the impact of this failure? (Zone dependencies)
Zones in incident response:
- Incident Response Plan references zones by name
- Isolation procedures are zone-based
- Recovery priorities are zone-based
- Drills practice zone isolation
Zones in everyday operations:
- Network monitoring organized by zone
- Access requests specify zone
- Change management considers zone impact
- Crew understands what each zone does
Measure actual resilience: Not: "Do we have an approved Zones and Conduit Diagram?" But:
- Can we isolate a compromised zone in <5 minutes?
- Can the ship operate with Zone X isolated?
- Do crew know which zone contains which systems?
- Can we recover a failed zone without affecting others?
- Have we tested isolation procedures?

Case Study: Two LNG Carriers

Vessel A: Beautiful Zones and Conduit Diagram, approved by Class. 8 zones, detailed documentation. Never practiced isolation. Crew didn't know what the zones were.

Cyber incident (malware on crew laptop): Crew didn't isolate anything (didn't know how). Malware spread to multiple systems. 3-day operational disruption, port state control detention.

Vessel B: Simple 5-zone design. Monthly isolation drills. Crew could draw zone diagram from memory.

Similar incident: Crew isolated affected zone in 90 seconds. Malware contained. Ship operations continued. Incident resolved in 6 hours.

Question: Which vessel had better cyber resilience?

Answer: Obviously Vessel B—despite simpler zone architecture, because they treated it as an operational tool, not a compliance checkbox.

The ShipJobs Security Zone Design Framework

Drawing from the lessons above, here's our recommended approach:

Step 1: Security Requirements Analysis

For Each CBS in Scope:

├─ System Category (I, II, III per E22)
├─ Criticality (essential service?)
├─ Independence requirement (must it operate if isolated?)
├─ Data flow requirements (what talks to what?)  
├─ Shore connectivity (yes/no)
└─ Wireless components (yes/no)

Step 2: Logical Zone Design

Group CBS by Shared Requirements:


Zone 1: Essential Propulsion & Steering
└─ Cat III, must operate independently, no shore connection

Zone 2: Essential Safety Systems
└─ Cat III, independent operation, limited shore connectivity

Zone 3: Operational OT (Machinery)
└─ Cat II, can operate isolated, some shore connectivity

Zone 4: Navigation & Communication
└─ Statutory systems, separate from zones 1-3, shore connectivity

Zone 5: Monitoring & Management  
└─ Cat II/I, shore connectivity heavy, can be isolated

Zone 6: Crew/Guest IT
└─ Untrusted, internet-connected, fully isolated from zones 1-5

Wireless Zones (dedicated):
└─ W1: OT Wireless (separated by function)
└─ W2: Crew WiFi

Step 3: Boundary Protection Specification

For each conduit (zone-to-zone connection):

Allowed traffic (explicit protocols, sources, destinations)
Boundary device type (firewall, diode, air gap)
Technical specifications (performance, environmental rating)
Firewall rules (detailed, tested)

Step 4: Physical Implementation

Map logical zones onto network infrastructure
Install boundary protection devices
Verify isolation capability
Test performance

Step 5: Documentation

Zones and Conduit Diagram (per E26 5.1.1)
Cyber Security Design Description (per E26 5.1.2)
Vessel Asset Inventory (per E26 4.1.1)
Include zone allocation for each CBS

Step 6: Operational Integration

Incident Response Plan references zones
Isolation procedures written and tested
Crew trained
Management of Change triggers zone review
Annual audit of zone documentation

Step 7: Continuous Improvement

Learn from incidents
Incorporate crew feedback
Update as systems evolve
Benchmark against industry practice
Share lessons learned

Conclusion: Zones That Work

Security zones under UR E26 are not a bureaucratic exercise. Done properly, they are the architectural foundation of a ship's cyber resilience.

The ten pitfalls we've examined share a common theme: misunderstanding the purpose of zones, leading to implementations that satisfy compliance requirements on paper but provide little actual security value.

The path forward:

Design zones based on security requirements, not network topology
Optimize for operational simplicity, not technical perfection
Include wireless from the start, don't retrofit it
Be honest about air gaps, they're rarer than claimed
Treat shore connectivity as a primary design concern, not an afterthought
Maintain living documentation, zones evolve with the ship
Specify boundary protection early, it's not an implementation detail
Design for human operation, crews must be able to execute procedures
Plan for retrofit reality, most vessels are already built
Measure actual resilience, not just diagram approval

The goal is not to have the most zones, the most complex architecture, or the most impressive diagram.

The goal is a ship that can continue safe operations even when facing cyber incidents—and security zones are the structure that makes this possible.

What's Next?

This article examined the practical challenges of security zone implementation. In our next piece, we'll tackle an equally contentious topic:

"41 Security Capabilities: Do You Really Need Them All?"

We'll explore:

Which UR E27 security capabilities matter most
When compensating countermeasures make sense
How to prioritize implementations on limited budgets
The ShipJobs Prioritization Framework for security capabilities

Until then, if you're working on zone design and want to discuss your specific challenges, we're here to help.

Fair winds and secure networks, The ShipJobs Team