Top Five Fail Points

There is no official statistic on how "common" each failure is; the five below are recurring rejection reasons seen in practice — treat them as a self-audit checklist, not an authoritative ranking. Each maps to an E27 capability family left unmet.

Context first: IACS UR E27 Rev.1 became mandatory on 1 July 2024 for vessels contracted for construction on or after that date. Yet as of November 2024, the number of shipboard OT products with class-society type approval was tiny — per Pen Test Partners and the ure27.com H2 2025 recap, ClassNK had approved roughly 4 systems and DNV roughly 20, against a vast global maritime OT equipment market (November 2024 snapshot; figures change continuously — consult class society bulletins for current counts). This widespread vendor lag is the shared root cause behind all five failure patterns: security was not engineered in from the start but bolted on in the weeks before submission.

Five failures → the family each breaks

Fail Point 1: Authentication gaps — default credentials and open ports (FR1)

This is the archetypal single-point veto. Equipment ships with factory default credentials (e.g., username admin, password 1234) and no technical mechanism forces the operator to change them at first login; or the system imposes no password-complexity floor and accepts any arbitrary short string; or certain network interfaces require no authentication at all, granting anonymous entry to the configuration screen. All of these violate a cluster of System Requirements (SRs) under IEC 62443-3-3:2013 FR1 "Identification and Authentication Control."

The relevant SRs map as follows (SR descriptions paraphrased from secondary sources — TeepTrak and UpGuard — normative text resides in IEC 62443-3-3:2013 itself): SR 1.1 "Human user identification and authentication" requires unique identification and authentication for every user on every interface providing human access; this is a SL1 baseline. SR 1.1 RE1 (SL2) additionally requires a separate authentication mechanism for each unique ID. SR 1.1 RE2 (SL3) requires multi-factor authentication (MFA) for connections over untrusted networks. SR 1.5 "Authenticator management" covers secure password storage, rotation frequency, and distribution controls at SL1. SR 1.7 "Strength of password-based authentication" enforces a minimum complexity floor (length and character types) at SL1. SR 1.11 "Unsuccessful login attempts" requires account lockout after repeated failures at SL1. SR 1.2 "Software process and device identification and authentication" requires mutual device-to-device authentication from SL2 onward — relevant for any OT device connecting into the shipboard network.

UR E27 Rev.1 goes one step further than IEC 62443-3-3's general wording: suppliers must enforce first-login password change through a technical control, not merely instruct users to do so in a manual. According to ure27.com analysis, this is one of the single biggest hurdles for Tier 2/3 suppliers — their firmware often runs on legacy embedded systems where adding enforced authentication logic requires fundamental rearchitecting of the codebase, not just overlaying a UI prompt.

Open ports are equally stealthy but equally fatal: reviewers run port scans against equipment and find navigation terminals exposing TCP 80 (HTTP admin panel), FTP, Telnet, and other services with no operational necessity. This violates IEC 62443-3-3 SR 7.7 "Least functionality" — all unneeded functions, ports, protocols, and services must be disabled by default at SL1. ure27.com is explicit that reviewers probe each exposed interface and treat any unnecessary open port as a trigger for technical rejection.

Remediation path: (1) Implement forced first-login password change at firmware level with complexity validation (suggested floor: at least 8 characters including at least one each of upper-case, lower-case, digit, and special character); (2) set account lockout after at most 5 consecutive failures, resettable by an administrator; (3) run a port scan against the factory image, close all non-operationally-necessary listening ports and services, and enumerate each remaining open port with its business justification in product documentation; (4) if the product authenticates device-to-device, introduce certificate or token-based mutual authentication from SL2 onward (SR 1.2); (5) MFA is mandatory from SL3 for remote access over untrusted networks — vendors must architect this capability in from the design stage, not retrofit it.

Fail Point 2: Shared accounts and absent audit trail (FR1 / FR2 / FR6)

Fail point 1 opens the authentication door; fail point 2 addresses who came through, what they did, and whether that can ever be traced. The most common pattern: the entire engineering team shares a single high-privilege admin account; service technicians plug in a laptop and use the same account; audit logs forever record "admin"; when an incident occurs it is impossible to determine which terminal, which person, in which time window, took which action. This problem spans three FR families: FR1 (unique identification is a prerequisite for authentication), FR2 (use control and least privilege), and FR6 (timely response to events and audit).

IEC 62443-3-3 SR 2.1 "Authorization enforcement" requires the system to enforce authorization for all users, roles, and parameters at SL1 baseline; SR 2.1 RE1 (SL2) extends this to all users with complete permission coverage; RE2 (SL3) requires mapping permissions to explicit roles. This means products must implement role-based access control (RBAC): operators get read-only access to operational data, engineers may modify set-points, administrators alone change system configuration — three roles with three distinct permission boundaries, non-interchangeable. A product with only one admin account already fails the intent of SR 2.1 at SL1 because "one account" makes the least-privilege principle structurally impossible.

The audit logging problem falls under SR 2.8 and FR6. SR 2.8 "Auditable events" (within FR2, SL1 baseline) requires the control system to record auditable events to system logs; SR 2.8 RE1 (SL2) requires a centrally managed system-wide audit trail. FR6 then reinforces this through SR 6.1 "Audit log accessibility" and SR 6.2 "Continuous monitoring": SR 6.1 requires authorized users to have read-only access to audit logs with tamper protection — users cannot modify logs; audit record content must cover timestamp, source, category, type, user ID, and outcome, across access-control events, configuration changes, firmware updates, backup/restore operations, and operations on the audit log itself. SR 6.2 "Continuous monitoring" requires an ongoing monitoring protocol — not periodic scans but real-time or near-real-time event awareness, which at SL2 implementation typically involves SIEM aggregation and an onboard OT-SOC capability.

What exactly do reviewers check? Per ure27.com analysis, reviewers expect to see: every critical action — login, set-point change, firmware update, configuration change — individually logged; log entries must carry reliable timestamps (typically requiring NTP synchronization); service-technician temporary access must be time-bounded and fully logged so it can be correlated after the fact; logs must not be deletable or modifiable through the normal user interface; the device must be able to export logs to an external monitoring system (syslog or equivalent) for inclusion in the system-level log architecture reviewers examine. A detail often missed: when logging itself fails — storage full, log daemon crashed — can the device alert the operator? This is a cross-requirement between SR 3.3 "Security functionality verification" and SR 6.2 "Continuous monitoring," and ure27.com explicitly identifies this as a blind spot where equipment frequently falls short (single source for this specific framing).

Remediation path: implement RBAC with at least three roles — operator / engineer / administrator — with each account bound to a unique individual identity; disable shared accounts. Embed a security audit logging module in firmware that records all required event types, with log files write-protected against operator-level overwriting or clearing. Configure session timeout (SR 2.6). Provide syslog or equivalent API for onboard SIEM integration. Implement logging health monitoring: when log writes fail, trigger an alert — via panel warning, SNMP trap, or SIEM heartbeat loss signal.

Fail Point 3: Vendor VPN direct-connect — the unapproved, unaudited back door (FR2 / FR5)

Remote maintenance is an unavoidable reality in modern shipboard OT: manufacturer engineers need to diagnose equipment faults from shore; software vendors need to push updates. The problem is that many devices come with a vendor-proprietary VPN client or remote management channel that is open by default, requires no ship-side approval to connect, and keeps connection records only on the vendor side — leaving the ship operator with zero visibility. Such a remote channel is in practice an unwatched back door: anyone who obtains the VPN credentials can, in principle, enter critical control systems without crew knowledge.

This maps to multiple SRs under IEC 62443-3-3 FR2 "Use Control" and FR5 "Restricted Data Flow." SR 2.1 "Authorization enforcement" requires authorization controls over all remote access. SR 2.4 "Use control of mobile code" and FR5's SR 5.1 "Network segmentation" and SR 5.2 "Zone boundary protection" require controlled data flow at OT network boundaries — unauthorized outbound connections must be blocked. UR E27's 11 additional capabilities for untrusted-network connections target exactly this scenario: any channel entering via an untrusted network — vendor VPN, satellite broadband, cellular — must meet additional requirements for session authorization, data-flow restriction, and audit. Pen Test Partners warns that relying on physical access controls to compensate for missing technical controls is often misguided and will be scrutinised by reviewers — the fact that a device is locked in the engine room does not excuse the absence of network-layer authentication and audit (single source for this specific framing).

Reviewers look for: whether the remote maintenance channel can only be initiated by the ship side — not the vendor — (the "call-out" model is preferred over passive listening); whether each remote session requires explicit approval from the ship's administrator; whether session content (action logs, transferred files) is retained in a ship-side-accessible system; whether the session can be unilaterally terminated by the ship at any moment ("kill switch"); and whether the channel provides boundary isolation that prevents the remote engineer from laterally moving from the maintenance interface into other systems.

Remediation path: introduce a Secure Remote Access Gateway through which all vendor remote connections are routed. The gateway must: require ship-side approval before a session is initiated (approval workflow); retain full session recording and action logs on the ship side; allow ship-side one-click disconnection of all remote sessions; enforce boundary isolation between the gateway and the OT network (only point-to-point data flow to specific device IPs and ports, lateral access blocked); and include all session records in the audit log (feeding FR6 requirements). At firmware level, any pre-built vendor direct-connect channel must be disabled by default and activatable only after explicit configuration.

Fail Point 4: Patch and update management — aging OS and security-function blind spots (FR3)

Patch management is not purely a technical problem — it is also a management-system obligation UR E27 places on suppliers: Rev.1 explicitly requires vendors to maintain a process for proactively notifying users of security updates, covering (a) how compatibility with new OS/firmware versions is communicated and (b) how risks of not applying updates are managed. This is a documentation and process requirement, not just a firmware feature. DNV's type-approval process audits supplier secure development processes, verifying conformance with UR E27 §4–5 and IEC 62443-4-1 (secure product development lifecycle), per DNV's official service page.

The starkest practical challenge is OS aging. Per Marlink data cited in a Bridewell Consulting report (2025): more than 40% of maritime operational systems were still running Windows 10 at the time of that report — a version that reached end-of-support in October 2025. This figure comes from Marlink's telemetry collection and was used by Bridewell to analyze maritime cyber exposure; it is the best publicly available estimate but should not be read as a comprehensive industry census — refer to the Marlink/Bridewell original for scope and methodology. More extreme cases exist in the field: vessel security assessments by Pen Test Partners and reporting by Riviera Maritime Media have found ECDIS systems running Windows XP (Microsoft support ended 2014) or even Windows NT — systems with no viable patch path and no upgrade route without manufacturer recertification.

IEC 62443-3-3 addresses this at the system integrity layer (FR3) through SR 3.3 "Security functionality verification," which requires that during test phases and maintenance procedures the IACS verify all security functions are operating correctly and report all deviations. In practice this means: if the antivirus on the device is disabled, if the log daemon crashes, or if firmware signature validation fails, the device must detect those anomalies and notify the operator. ure27.com identifies this as a blind spot where equipment commonly falls short — most embedded OT products have no built-in security-function health self-monitoring (single source for this specific characterization).

Reviewer focus areas: does the vendor have a product security advisory channel (PSIRT or equivalent)? Does product documentation declare OS/firmware end-of-support dates (EoL declaration)? Are firmware updates cryptographically signed (IEC 62443-4-2 component requirement)? Does the device provide security-function health status reporting? Has the vendor provided a complete CBS asset inventory/software bill of materials (SBOM, mapping to SR 7.8 and IEC 62443-4-1)?

Remediation path: establish a product security advisory mechanism (PSIRT) to regularly notify users of known vulnerabilities and available patches; explicitly declare EoL dates for all pre-installed software in the product manual, with risk mitigation guidance for scenarios where direct upgrade is not possible; implement cryptographic signing for firmware update packages, with device-side signature verification before installation; provide security-function health monitoring (watchdog-style) that triggers alerts when critical security processes fail; and supply a machine-readable SBOM in CycloneDX or SPDX format, updated with every firmware release.

Fail Point 5: No backup and insufficient availability design (FR7)

FR7 "Resource Availability" in IEC 62443-3-3 spans the complete availability chain from denial-of-service protection to backup and recovery — and is especially critical for shipboard OT: a vessel at sea cannot call on shore-side support; if a critical system cannot be recovered after a cyber incident or configuration corruption, the consequence directly affects navigation safety. Yet this capability family is often the most underestimated fail point at submission — vendors prioritize authentication and access control (FR1/FR2) and leave availability and backup as an "operational problem" for the ship owner to solve. This assumption is contradicted by E27's requirements.

Key SRs under FR7 mapped out (based on secondary sources — Shieldworkz, TeepTrak, UpGuard — normative text per IEC 62443-3-3:2013): SR 7.1 "Denial of service protection" requires the IACS to operate in a predetermined degraded mode under a DoS attack, with authorized maintenance access still possible in degraded state. SR 7.2 "Resource management" requires the system to manage resource allocation and prevent resource exhaustion. SR 7.3 "Control system backup" requires up-to-date backups always available to support complete system recovery after failure or misconfiguration; audit logs and other forensic data should be included in backups. SR 7.4 "Control system recovery and reconstitution" requires system workflows to ensure rapid return to a secure state after failure. SR 7.7 "Least functionality" requires restriction of unnecessary functions (overlaps with the port management dimension of Fail Point 1). SR 7.8 "Control system component inventory" requires a component-level asset inventory (overlaps with SBOM requirements in Fail Point 4).

What exactly do reviewers verify? First, SR 7.1: can the device articulate in documentation its "predetermined degraded mode" behavior — under network saturation or a DoS attack, which core functions continue and which non-critical functions are shed? Many vendors have no written definition of this and have never tested it. Second, SR 7.3 and SR 7.4: is there a backup and recovery procedure that has been actually executed and for which test evidence exists? "We can do a backup" and "we have verified the recovery procedure and retained execution evidence" are different things; E27 requires the latter. Shieldworkz notes that SL2 implementation typically requires documented RTO/RPO targets and tested daily/weekly/monthly backup procedures. Third, SR 7.1 maintainability in degraded mode: can authorized maintenance personnel still access the system for diagnostics while it operates in degraded mode?

Remediation path: (1) Define degraded-mode behavior explicitly in the product design specification (SR 7.1) and test it with recorded evidence during FAT/factory testing. (2) Implement network-stack input-queue rate limits to prevent a single malformed packet or network storm from exhausting device resources (SR 7.2). (3) Provide a signed backup/restore toolset with a documented operating procedure, defined RTO/RPO targets, and a requirement that the vendor complete at least one full recovery exercise before shipment, retaining evidence (SR 7.3/SR 7.4). (4) Publish a machine-readable SBOM in CycloneDX or SPDX format; include audit logs in backups (SR 7.3 forensic-data requirement combined with SR 7.8). (5) Ship with all non-operationally-necessary ports and services off by default (SR 7.7), listing each remaining open service with its business justification in the technical specification.

Beyond the five: the completeness of your submission evidence package

Beyond the five technical fail points, a sixth "procedural" pattern appears frequently: the technical capabilities are not actually bad, but the submission document package is incomplete, leaving reviewers nothing to verify against. UR E27 Rev.1 §3.1 defines the document composition required at submission, typically covering approximately 10 document types: asset and software inventory (SBOM/CBS asset list), network topology diagram, data-flow diagram, risk assessment report, security test report, declaration of conformity (DoC), configuration baseline records, patch management process documentation, security awareness training records, and a product security capability description document. Any missing or insufficiently substantiated document category triggers a Technical Query (TQ) requiring supplementation — delaying the review and, in severe cases, causing outright rejection.

Common evidence-deficiency patterns: (a) the network topology diagram shows only device-level connections without annotating communication protocols, port numbers, and data-flow directions — reviewers cannot verify boundary isolation; (b) security test reports cover only functional testing with no penetration test or vulnerability scan records, and no statement of the test scope boundary; (c) the SBOM lists only third-party libraries without including pre-installed system components in the OS image; (d) the declaration of conformity makes only qualitative assertions ("we conform to IEC 62443-3-3 SR 1.1") without cross-referencing test records — giving reviewers no traceable evidence chain. The ure27.com H2 2025 recap explicitly notes that in E27 type-approval failure cases, vessel-level compliance also does not automatically follow — even if each device separately passes type approval, integration into the actual shipboard network architecture still requires separate system-level verification by the shipyard and class society. The lesson for equipment vendors: evidence documentation must, from the outset, anticipate system integration — describing how the device is securely integrated into a larger CBS architecture, not just describing the device in isolation.

This list saves detours, but it does not replace a formal gap assessment; the actual classification and pass/fail rest with class society review.