Scenario: Engine-Room Monitoring Submission

This is an illustrative, typical scenario (not a specific project): an engine-room monitoring/alarm system going through the E27 journey end to end. Actual classification and pass/fail rest with the class society.

An engine-room alarm monitoring system (AMS/ERAMS) is an indispensable safety subsystem that provides continuous supervision of main/auxiliary engines, boilers, fuel oil, lubrication oil, cooling water, bilge/ballast, exhaust gas temperature per cylinder, crankcase pressure, and dead-man alarms. Typical architecture consists of PLC acquisition modules (up to 64 analogue inputs per module), a 15-inch touch HMI, remote LED panels at bridge and ECR locations, and Modbus RTU-TCP / CANBus / Ethernet communication links — with dual normal/emergency power supply redundancy required. Alarm signals must be visible and audible at the machinery space and all continuously attended control stations to satisfy SOLAS Chapter II-1 and the UMS (Unattended Machinery Space) class notation. Because the system sits deep inside the vessel's operational data flows, it has become a canonical subject for E27 scrutiny.

1. Confirm scope and category

Engine-room monitoring is a Computer Based System (CBS) within E27 scope. By UR E22's failure-effect view, monitoring/alarm functions often fall in Cat II (could eventually lead to danger), requiring documentation, FAT witnessing and a System certificate — not the Cat I "normally not verified" treatment.

Two scope questions must be settled first. First, E27 defines a CBS as "a programmable electronic device or set of such devices that processes, stores, or transmits information." Any system containing PLCs, firmware controllers or networked HMIs, and exchanging data via Ethernet, USB or serial interfaces, meets the trigger — even air-gapped systems remain in scope if physical service ports are not permanently disabled and physically blocked. Second, E27 was first issued in April 2022 and revised to Rev.1 in September 2023; the requirement is mandatory for ships with construction contracts signed on or after 1 July 2024. Earlier newbuilds may also be captured depending on contract terms or yard/owner agreement — confirm the applicable date at project inception.

Once the system is confirmed within E27 scope, the next step is category determination under UR E22 Rev.3. E22 defines three categories: Cat I for systems whose failure will not lead to dangerous situations — normally not verified; Cat III for systems whose failure could immediately lead to dangerous or catastrophic situations; and Cat II for systems — including vessel alarm, monitoring and control functions necessary to maintain the vessel in its normal operational and habitable conditions — whose failure "could eventually lead to dangerous situations for human safety, safety of the vessel and/or threat to the environment." Engine-room monitoring/alarm systems fall squarely in Cat II. Category II triggers: document submission, witnessed Factory Acceptance Test (FAT), and a System certificate — the system cannot bypass class review via reference design or internal testing alone.

2. Gap assessment

Walk it against E27's capability families. The two most common gaps for engine-room monitoring: no security audit log (mapping, in IEC 62443 FR taxonomy, to response/logging and use-control functional requirement areas — FR labels below follow IEC 62443 FR classification, not necessarily E27's own printed label; defer to your class society's interpretation); and unapproved, unbounded vendor remote maintenance (a use-control + restricted-data-flow gap).

Before the formal gap walk begins, two foundational documents must exist: a **CBS asset inventory** accurate to version level — covering PLC model and firmware version, HMI OS version, all third-party libraries and communication protocol stacks — and a **topology diagram** capturing physical and logical data flows, protocol types, and every external connection including the vendor's remote diagnostic interface. Both documents are also core submission deliverables under E27; building them early means gap assessment and document preparation advance in parallel, avoiding rework later.

With asset inventory and topology in place, the gap assessment can be evidence-based. E27 requires a CBS to satisfy at least 30 core security capabilities; systems communicating with untrusted networks — such as vendor VPN maintenance access or shore-based data push — must additionally satisfy 11 capabilities, totalling 41. Capability areas span: identification and authentication, software authenticity verification, backup and rollback, cybersecurity event logging, traffic monitoring and control, access control, encrypted communications, malware detection, security update mechanisms, and vulnerability disclosure. Engine-room monitoring systems typically exhibit five recurring gap categories across these 30–41 capabilities, each corroborated repeatedly in publicly available maritime cybersecurity guidance.

Gap (a) — missing audit logging — is the single most prevalent deficiency. E27 requires that every critical action (login, setpoint change, firmware update) generate a timestamped log entry, that logs be stored in tamper-resistant files, and that the system alert crew when security functions fail. ABS confirms in its E27 FAQ that the CBS "shall timestamp audit records." Many legacy engine-room monitoring firmwares log only process alarms, not user actions — a perfectly reasonable design choice in the era of purely functional safety but an explicit gap under E27.

Gap (b) — uncontrolled vendor remote channel — is characterised by OT security consultancy OTWarden as "one of the highest cyber risk vectors." The typical pattern: an OEM opens a VPN tunnel during commissioning for remote parameter adjustment; the tunnel remains persistently connected thereafter, never entered into the topology diagram, with no per-session approval mechanism. E27's additional 11 capabilities for untrusted-network-connected systems require: secure tunnels with endpoint authentication, integrity protection and transport-layer encryption; explicit local vessel authorisation before granting service laptop or remote access; per-session authorisation with immediate termination on completion; and physical means of ensuring disconnection (e.g., a patch cable that can be unplugged). Pen Test Partners note that remote-connectivity disconnection mechanisms installed onboard "are not always effective or obvious."

3. Remediation

After the gap assessment, remediation proceeds per gap type, with considerably different complexity and lead times for each. Documents must be updated in parallel so that the final submission package accurately reflects the as-built system state. Where a specific capability genuinely cannot be fully met, E27 allows compensating countermeasures — but the countermeasure must demonstrably address the same threats, provide equal protection, and not introduce higher security risk. Such claims must be argued in detail in the security capabilities description document for class review.

• Per-person accounts + strong passwords, replacing shared logins
• Enable security audit logging with reliable timestamps
• Deploy a secure remote-maintenance gateway: approval, session audit, boundary isolation
• Close unused ports/services; apply least functionality
• Back up configs regularly and test the recovery

**Logging gap remediation** is typically achieved via firmware/software update, making it one of the lower-complexity remediations: update the firmware to enable user-action logging, configure remote time synchronisation (NTP) to ensure timestamp reliability, direct logs to tamper-resistant storage (append-only files or a dedicated secure log server), update the test procedure and retest. Post-remediation, the system must be able to demonstrate: login events generate log entries, setpoint changes generate log entries, and logs cannot be deleted by a standard user.

**Remote-channel remediation** is considerably more complex, typically requiring insertion of a managed switch or firewall between the monitoring system and the external network, and configuration of a per-session approval workflow: vessel personnel approve OEM maintenance requests from a local console, the session is audited end-to-end, and terminated — automatically or manually — with the termination time recorded. Where existing Ethernet paths exist but were never documented, the topology must be redrawn to annotate all data flows and protocol types, and the security controls for those paths argued separately. Importantly, E27 does not require submission of actual software code or proprietary functionality detail — ABS explicitly confirms in its FAQ that class societies do not require actual code submission. What is required: the capability mapping, test procedures demonstrating security features work, and architecture documentation.

**SBOM remediation** is not technically complex but often takes time: the vendor must enumerate all system components (OS and version, third-party libraries and versions, firmware layers and versions), produce a living document, and agree on ongoing CVE notification and patch SLA responsibilities. The SBOM is both a submission deliverable under E27 and the operational foundation for post-delivery vulnerability disclosure and patch management. For shipowners, this means that at procurement stage, SBOM, vulnerability disclosure policy, and product end-of-life date should be contractual requirements.

4. Evidence and submission

After remediation, the process enters document package preparation and submission. E27 requires the supplier to submit five core documents: (1) CBS asset inventory — hardware and software component listing with exact versions; (2) CBS topology diagram — physical and logical network architecture annotating data flows, protocols and all connections; (3) security capabilities description — item-by-item mapping from system features to the 30+ mandatory security requirements; (4) security capabilities test procedure — per-requirement repeatable test steps; (5) security configuration guidelines (hardening manual) — default values and configuration hardening instructions. Three additional lifecycle documents are also required: Secure Development Lifecycle (SDL) documentation, a maintenance and verification plan, and information supporting the owner's incident response and recovery plan.

On receipt of the document package, class reviewers focus on several dimensions: **Document completeness** — are all five core documents present, is the asset inventory granular to version level? **Topology accuracy** — does the physical topology diagram annotate all data flows, protocols (Modbus, Ethernet, RS-485) and external connections; are remote access paths visible? **Capability-mapping quality** — does the security capabilities description map each of the 30 required capabilities to a specific system feature; for gaps, are compensating-measure arguments sufficiently substantiated? **Test-procedure quality** — is there a separate section per requirement; are tests repeatable; were they witnessed? **Hardening-guide adequacy** — does it provide actionable security configuration guidance, not merely a list of factory defaults?

During the FAT (Factory Acceptance Test), for case-by-case (non-type-approval) submissions, the class surveyor must physically attend the vendor's facility to witness the cybersecurity capability tests. Surveyors typically focus on two demonstrations: audit log verification — actually triggering login, setpoint change and firmware update events, verifying log entries are generated and proving logs cannot be deleted by a standard user; and remote-access control verification — confirming that the vendor cannot initiate a remote connection without explicit local authorisation, and that the session-termination mechanism is effective.

5. Type approval vs. case-by-case: which path?

E27 offers two certification pathways. **Path A (Type Approval):** A one-time review by the classification society, including a full documentation audit and witnessed FAT at the manufacturer's facility. Once a type approval certificate is held (typically valid for approximately 5 years, subject to actual class society terms), each subsequent ship installation may submit a reduced vessel-specific document package. As of November 2024, only approximately 24 CBSs had received type approval globally — roughly 4 under ClassNK and approximately 20 under DNV — a number still very limited. In the engine control domain, WinGD obtained DNV SP1 type approval on 30 November 2022, the first marine engine designer to do so, with approval covering identification and authentication, software authenticity verification, backup and rollback, cybersecurity event logging, and traffic monitoring and control. An analogous alarm-system example is Zenitel's EXIGO IP-based PAGA (Public Address/General Alarm) system, whose type approval process involved "detailed documentation assessments followed by rigorous testing based on IACS UR E27 criteria" and Threat and Risk Assessments (TRAs) to prioritise vulnerabilities. Note that Zenitel's type approval applies exclusively to new EXIGO deliveries from its Horten headquarters, installed by trained personnel; existing installations are not covered and cannot be upgraded in the field to fall within the approval.

**Path B (Case-by-Case):** A full document package is required for every vessel, and a class surveyor must physically attend the vendor's facility or shipyard to witness the FAT for that specific unit. Pen Test Partners note that non-type-approved systems require "a similar amount of documentation as would be required to obtain type approval" — leading shipyards to increasingly specify that all systems obtain type approval, to avoid the per-unit cost and surveyor availability dependency of the case-by-case path. For AMS/ERAMS vendors, the upfront investment in type approval significantly reduces per-ship compliance friction in the long run and creates a market differentiator.

6. Vendor vs. yard responsibility split

E27 (CBS product compliance) and E26 (vessel system integration compliance) have a clear demarcation of responsibility across the engine-room monitoring supply chain. The vendor, as E27 obligor, is responsible for: type approval evidence or case-by-case submission package, SBOM and CVE log with patch SLA, security configuration guidelines (hardening manual), SDL development lifecycle documentation, vulnerability disclosure policy, and end-of-life date publication. The shipyard/systems integrator, as E26 obligor, is responsible for: the zones and conduit diagram, vessel asset inventory, cybersecurity design description, ship cyber resilience test procedure, and maintaining an updated inventory throughout construction.

The **handoff point** between vendor and yard is the E27 CBS approval certificate plus hardening guide. The yard uses the vendor's approved configuration as the security baseline, then layers vessel-level controls — network segmentation and zone policy — on top. In the engine-room monitoring scenario specifically: the integrator must ensure the AMS/ERAMS is placed in the appropriate security zone (typically the OT zone), its Modbus/Ethernet connections are documented in the conduit diagram, any maintenance VPN path is firewalled and access-controlled, and the vessel-level cybersecurity design description references the vendor's hardening guide. If the monitoring system also pushes data to shore via a cloud energy-management module, that connection must be specifically identified — Pen Test Partners note that "cloud-connected energy monitoring systems are incredibly common" and frequently represent "poorly documented or insecure" high-risk connections that should be reviewed at the design stage, not discovered during audit.

Project timelines vary by ship; this scenario illustrates the order of steps, not durations; final classification and pass/fail rest with class society review. DNV's SP1 type approval is grounded in IEC 62443-3-3 Security Level 1 (SL1), which targets protection against "casual or coincidental" unauthorised access rather than targeted attacks — a threat model broadly aligned with the engine-room monitoring context. Vendors holding IEC 62443-4-2 SL1 component certification have a substantively stronger documentation starting point on the path to E27 type approval.