[IACS UR E26] Protect – 07 Remote Access Control & Untrusted Network Communication

IACS UR E26 - Remote Access Control & Untrusted Network Communication

 

**Remote Access at Sea: Where Cyber Risk Meets Real-Time Operations** 🔐

What happens when a shore-based technician connects to a vessel's engine control system at 0200 in the middle of the Pacific — and no one on the bridge knows it's happening?

 

**What UR E26 §4.2.6 Requires**

Every CBS must be shielded from untrusted networks — no CBS IP address may be externally visible, ever. All remote connections must route through secure tunnels (VPN/DMZ), authenticate both the endpoint and the user via MFA, and critically, receive explicit on-board acceptance before a session opens. There are no exceptions and no automatic sessions.

 

**Maritime-Specific Implications**

Ships are not data centers. The crew member responsible for accepting a remote session may be the Chief Engineer on watch, managing multiple operational priorities simultaneously. Yet E26 places that accept/interrupt/abort authority firmly on board — meaning crew must be trained, procedures must be drilled, and remote maintenance windows must be operationally planned. The CSDD must document every CBS that communicates with untrusted networks, turning this from a technical control into a vessel-level governance obligation.

 

**IEC 62443 Technical Depth**

E26 §4.2.6 implements three IEC 62443-3-3 Security Requirements in full:

→ SR 1.13 RE1 — Explicit Access Approval: on-board acceptance before any remote session

→ SR 1.1 RE2 — Multi-Factor Authentication: mandatory for all human users from untrusted networks

→ SR 6.1 — Audit Log Accessibility: every remote session must be logged and retrievable at annual survey

 

E26 has not selectively adopted IEC 62443 here — it has embedded the complete untrusted network requirement set as vessel-level legal obligations under class.

 

**UR E27 Connection**

E26 Appendix II maps all 11 E27 §4.2 untrusted network items (items 31–41) directly to §4.2.6. These cover MFA, device authentication, login attempt limits, warning banners, access monitoring, session termination, cryptographic integrity, input validation, session integrity, and session ID invalidation. E26 §4.2.6 is the vessel-level umbrella; E27 §4.2 items 31–41 define what each individual system or component must technically implement beneath it.

 

**Implementation Insight** 🛡️

The hardest gap to close in practice is the pre-tested patch requirement. E26 §4.2.6 mandates that remote maintenance patches be pre-tested, supplier-confirmed, and capable of rollback — before installation. Most shipboard OT systems today lack formal patch staging environments. Shipyards and system integrators need to build this into FAT/SAT procedures now, not as a retrofit.

 

**Engagement Question**

How are your remote access procedures currently documented — are crew roles, session acceptance authority, and rollback steps written into your SMS, or are they still living in vendor service agreements?

 

📌 Post 7/17 in my IACS UR E26 series — breaking down all 17 requirements across the Identify → Protect → Detect → Respond → Recover framework

IACS UR E26