E27 applicable · not self-assessed

Navigation & Comms

IACS UR E27 Category II · E27

Cyber-resilience compliance for Navigation & Comms (IACS UR E27 Category II): clauses in scope Authentication, Access control, Audit logging, Data integrity, common failure points and submission evidence on one page. HAISHIDE helps you find the gaps and pass. For reference only; class society decides.

Cyan = E27 applicable / not yet self-assessed; ready or risk shows only after assessment. This page presets no result and sells no fear.

Interpretations of IACS UR E26/E27 on this site are for reference only; formal compliance is determined by class society review.

System category

IACS UR E27 Category II

Scope · Core

A tampered or failed ECDIS — wrong fix, forged ENC, manipulated AIS/radar overlay — misleads conning and sits on the 'could ultimately endanger' side; but it does not directly drive propulsion, steering or power, and a compliant backup (dual ECDIS or equivalent) is mandated as redundancy, so it is engineered toward Category II rather than III. Where it is deeply integrated into an INS and participates in automatic track-keeping or an autopilot loop, the consequence chain extends toward control and some class societies may raise their scrutiny. Final classification rests with the class society.

Scope & interfaces

ECDIS is the bridge's primary situational-awareness and route-decision computer system: it contains a microprocessor, runs a general-purpose OS (usually Windows), has physical USB / optical-drive ports, and can update charts over satellite or shore links — placing it within the E26/E27 definition of a CBS. It is handled as a single-system type approval under E27, is not normally exempt, and the final scope rests with the class society. The general capabilities apply almost in full; whether each untrusted-network additional capability applies depends on whether the ECDIS is designed with that connectivity (under E27, additional requirements apply only to systems designed for such connections). Common untrusted touchpoints: (1) the chart / permit update path (USB / optical drive or online ship-shore — USB is hard to forbid in practice and is the main channel for updates and the AV database); (2) online / shore chart updates over VSAT or satellite (public penetration research has demonstrated 'update-as-implant'); (3) vendor remote maintenance (the OEM engineer's laptop); (4) the connected removable media / laptop itself. It is a high-exposure device.

E27 clauses in scope

Human-user identification and authentication — note the bridge exception
Foundational requirement · FR1 Identification & Authentication (≈ SR 1.1, indicative)
In plain terms: In principle one account per person, traceable; but E27 allows an exception to user authentication for bridge systems that 'need immediate access', and ECDIS often falls into this category. Even where the exception applies, it does not waive audit logging, privilege separation or media control — these are replaced by equivalent compensating measures that must be declared to and assessed by the class society.
Hardened access control over untrusted networks
Foundational requirement · FR1 additional (≈ SR 1.13, indicative)
In plain terms: Pulling online chart updates over satellite or shore links means dealing with an untrusted network, so access along this path must be verified more strictly than on the internal network (public penetration work has confirmed it is a real entry point).
Multi-factor authentication for external remote access
Foundational requirement · FR1 additional (indicative)
In plain terms: If external remote login is allowed, a single password is not enough — two factors are required.
Authorization enforcement and least privilege
Foundational requirement · FR2 Use Control (≈ SR 2.1, indicative)
In plain terms: Day-to-day navigation rights and engineering / maintenance rights must be tiered, not crammed into one account.
Removable / portable device and USB media control
Foundational requirement · FR2/FR3 (≈ SR 2.3 / 3.2, indicative)
In plain terms: USB is both the main update channel for ECDIS and the number-one virus entry; since it is hard to forbid, lock down how it is used (controlled access plus mandatory scanning).
Auditable events and time stamps
Foundational requirement · FR2 (≈ SR 2.8 / 2.11, indicative)
In plain terms: Record who changed which chart or parameter and when, with accurate time stamps; this is commonly missing in service, and the authentication exception does not waive it.
Communication integrity / sensor-input integrity
Foundational requirement · FR3 System Integrity (≈ SR 3.1, indicative)
In plain terms: GPS, AIS, radar and gyro inputs mostly run over plaintext NMEA0183 without authentication, so injection of forged positions or targets must be guarded against.
Malicious-code protection
Foundational requirement · FR3 (≈ SR 3.2, incl. untrusted-network condition, indicative)
In plain terms: Legacy Windows plus USB / online updates is a breeding ground for malware; host protection plus malware-free assurance is required on any connection.
Software & information integrity / ENC provenance verification (S-63)
Foundational requirement · FR3 (≈ SR 3.4, indicative)
In plain terms: Plaintext S-57 charts still circulate and can carry illicit ENCs; the S-63 encryption / licensing / provenance scheme is needed to block forged or infected charts.
Session integrity
Foundational requirement · FR3 (≈ SR 3.8, indicative)
In plain terms: Within an INS, the sessions between the ECDIS and each node must be protected against hijacking and tampering.
Network zoning and zone boundaries
Foundational requirement · FR5 Restricted Data Flow (≈ SR 5.1 / 5.2, indicative)
In plain terms: The navigation domain must be its own zone, not sharing a flat network with crew internet or business traffic.
Accessible audit logs and continuous monitoring / alerting
Foundational requirement · FR6 Timely Response to Events (≈ SR 6.1 / 6.2, indicative)
In plain terms: Sensor failure or manipulation must raise an alarm (such as a position-failure alarm), and retrievable records must be retained.
Backup and recovery / reconstitution (incl. ENC / permits / configuration)
Foundational requirement · FR7 Resource Availability (≈ SR 7.3 / 7.4, indicative)
In plain terms: Paperless operation relies entirely on high availability plus a compliant backup; the primary and backup should not run identical software and permits, so that one vulnerability or one malicious chart cannot take out both at once.
Minimal functionality (disable unneeded services / ports)
Foundational requirement · FR7 (≈ SR 7.7, indicative)
In plain terms: Disable exposed web / HTTP, remote desktop, telnet and other non-navigation services to shrink the attack surface.
Component inventory and configuration baseline
Foundational requirement · FR7 (≈ SR 7.8 / 7.6, indicative)
In plain terms: Be able to produce an asset inventory and topology: which OS and version, which OEM software, and which sensors are connected.

Common failure points for this equipment

Legacy OS out of support (many in-service ECDIS run Windows XP / 7)
Consequence: XP (end of support 2014-04) and Win7 (2020-01); a 'stability over patching' culture leaves patches long overdue, so an off-the-shelf exploit can gain control and often there is no patch to plug it (FR3/FR7).
USB / optical updates without signature checks, copied straight in
Consequence: Malicious code enters the host with the update media; USB is hard to forbid, so it must be handled by controlled access plus mandatory scanning (FR2/FR3).
Online / shore chart-update path poisoned
Consequence: 'Update-as-implant' has been demonstrated by public penetration research, turning the supply / update chain into a remote entry point (triggering the untrusted-network additional capabilities).
ENC integrity bypassable (no S-63)
Consequence: Forged or malicious charts can be loaded, showing wrong positions or depths and misleading conning (FR3).
Plaintext NMEA0183 sensor inputs open to injection (GPS spoofing is a known maritime phenomenon)
Consequence: The watch sees a manipulated picture with no way to notice (FR3, an ECDIS-specific failure point).
Flat network, no zoning
Consequence: Public penetration research has shown lateral movement within bridge OT after a local-Ethernet intrusion, amplifying a single breach into multi-system exposure (FR5, conflicting with E26 whole-ship zoning).
Shared / default accounts, no operation trail
Consequence: Bridge systems that 'need immediate access' may apply for an authentication exception — but the exception does not waive audit or privilege separation, so 'no audit, no privilege separation' is the solid failure point (FR6/FR2).
Side-channel services / ports left open (HTTP/telnet management, remote desktop)
Consequence: The attack surface is needlessly enlarged by non-navigation services (FR7).
Primary and backup fully identical, same permit, updated together
Consequence: One vulnerability or malicious chart takes out both at once, rendering the redundancy meaningless (FR7, undermining the backup premise that the Cat II rating relies on).
Vendor remote maintenance without approval, audit or MFA; the maintenance laptop may be infected
Consequence: The maintenance channel becomes a backdoor (untrusted-network additional capability, FR1/FR3).

Evidence to prepare for submission

CBS asset inventory (primary/backup host models, OS and patches, OEM software, ENC/permit incl. HW_ID binding, sensor interfaces, media policy)
Physical + logical topology diagrams (incl. boundaries to untrusted networks / USB / shore updates)
Security capability description (incl. declaration and compensation for the bridge authentication exception)
Test procedures and reports (authentication or exception compensation, authorization, media scanning, S-63 verification, manual approval before connection, MFA, log alerting, backup and recovery, port trimming)
Security configuration / hardening baseline
SDLC documentation (drawn from 62443-4-1)
Chart-update provenance verification evidence
Network zoning design description (aligned with E26)

Remediation direction

E27 capability gap assessment (line-by-line comparison plus declarable compensation for the bridge exception; produce a capability mapping and gap list)
Treat the hard-to-forbid USB channel with controlled media plus mandatory scanning plus provenance verification (S-63 in practice)
Make the navigation domain its own zone; define conduits and boundaries (aligned with E26)
Tier account roles plus remote MFA plus manual approval before connection plus audit logging (provide equivalent compensation and declaration material for the exception case)
Pair the out-of-support legacy OS with a 62443-4-1 vulnerability-management / patch process plus compensating controls (minimal functionality, disabling side-channel services, host protection)
Write the test procedures and reports
Assemble the submission package along the type-approval route

How HAISHIDE helps you pass

Harden interfaces, add auth & logging, prepare submission evidence.

Run a gap assessment for this equipment

E27 landing pages for other equipment

← First, understand what E26 / E27 is