Part 2. Designing Secure Remote Access for Ships
Part 1 established why modern ships require jump servers. This article addresses how to design a secure remote access architecture that is technically sound, operationally practical, and compliant with IACS UR E26/E27 and related international standards.
Secure remote access for ships is a multi-domain engineering challenge spanning architecture, identity management, session control, cryptography, vendor governance, software integrity, and maritime-specific operational constraints. This article examines thirteen design domains in structured depth. A jump server that is poorly designed — or correctly designed but poorly integrated — provides less security assurance than its presence might suggest.
Architecture
The jump server's architectural position determines what it can protect and what remains exposed. A correctly positioned jump server enforces access control for all remote sessions. A poorly positioned one creates a false sense of security while leaving direct access paths open.
A cruise vessel retrofits a jump server between its satellite gateway and its IT network. The OT network, however, retains a separate direct VPN connection configured by the engine automation OEM during commissioning. The jump server protects the IT side; the OT side remains accessible without passing through it.
• Flat network topologies allow lateral movement if any connected session is compromised
• Insufficient network segmentation means a compromised vendor session can probe adjacent systems
IACS UR E26 requires that networks carrying safety-critical functions be segmented from networks carrying non-safety functions. IMO MSC-FAL.1/Circ.3 emphasizes controlling access points as part of broader cyber risk management. IEC 62443 zone-and-conduit model applies.
• Apply the IEC 62443 zone-and-conduit model as reference for OT segmentation
• Document network architecture formally; review at each IACS UR E26 annual assessment
• Physically separate the jump server from the systems it protects
Authentication
Weak authentication is the most common initial step in successful remote access attacks. For maritime systems, where compromised credentials may not be detected for days due to intermittent satellite connectivity, authentication failure has disproportionately severe consequences.
A cargo vessel's engine room monitoring system uses a shared service account for vendor remote access. Three separate OEMs use the same credentials; none of them know the others do. The account has never been changed since commissioning.
• Passwords shared across multiple organizations are effectively uncontrolled, including by former employees
• Static passwords that are never rotated remain valid indefinitely after a vendor's support contract ends
IACS UR E26 requires access control mechanisms for all CBS including controls over remote access. NIST SP 800-207 (Zero Trust Architecture) treats user identity as a core pillar — authentication must be continuous and risk-based, not binary.
• Issue individual named accounts; prohibit shared credentials for remote access
• Implement credential vaulting for OT system access
• Establish a formal process for revoking access when vendor contracts end or individuals change roles
• Set password complexity and rotation policies aligned with ISO/IEC 27001 Annex A
Authorization
Authentication confirms who is connecting. Authorization determines what they are permitted to do. These are distinct functions, both necessary. A correctly authenticated user should have access only to the systems and functions their role requires.
A third-party cybersecurity consultant is granted temporary remote access to perform a vulnerability scan of the navigation network. The access granted also gives them visibility into the engine automation network, because network segmentation is not enforced at the jump server policy level.
• Static authorization policies that are never reviewed may grant access no longer necessary
• Authorization policies not systematically documented cannot be audited or verified by third parties
IACS UR E26 addresses access control as a Protection function, requiring that access to CBS be controlled and third-party access managed within defined parameters. IEC 62443-3-3 defines security levels that include requirements for user authorization at each level.
• Require explicit time-bounded approval for all vendor access sessions
• Apply least privilege: start with no access and grant only what is demonstrably necessary
• Review and prune access authorizations when vendor contracts change or systems are reconfigured
• Log authorization decisions — both grants and denials — as part of the audit record
Session Management
Session management determines what happens during the session: how it is initiated, monitored, terminated, and what happens if it goes dormant or behaves anomalously. Correct session management prevents risks that occur during a session, not just at connection establishment.
A vendor connects to an engine automation system for a scheduled diagnostic at 08:00. The diagnostic takes 45 minutes. The vendor forgets to disconnect. The session remains active for 18 hours, during which the vessel transits a congested shipping lane. Anyone with access to the vendor's workstation could have interacted with the ship's engine automation system.
• Sessions established in one time zone and left open can remain active during crew changeover, when oversight is lowest
• Long-lived sessions are harder to monitor in real time; anomalous activity may not be detected until after the session ends
IACS UR E26's Detection requirements include the ability to identify and alert on anomalous network behavior. Unmonitored long-lived sessions are precisely the kind of anomaly that a compliant detection capability should identify.
• Set hard maximum session durations tied to the approved maintenance window
• Provide real-time session dashboards accessible to both shipboard and shore-based security personnel
• Implement automatic session termination if the session deviates from its pre-approved access scope
Audit Logging
Audit logs are the primary evidence base for incident investigation, compliance verification, and insider threat detection. A remote access incident without audit logs is almost impossible to reconstruct. Logs also deter misconduct — users who know their sessions are recorded behave differently.
A ship experiences an unexplained configuration change in its ballast water treatment automation system. Investigation reveals that a third-party vendor had remote access three days before the change was noticed. There are no session logs, no record of which systems the vendor accessed, and no way to determine whether the vendor connection is related.
• Incomplete logs (connection events only, not session content) may identify that access occurred without identifying what happened
• Logs stored exclusively on the ship can be modified or deleted if the jump server is compromised
IACS UR E26 requires that ships maintain records sufficient to support incident investigation. IMO MSC-FAL.1/Circ.3 lists logging as a component of the Detect and Respond functions.
• Forward logs to a shore-based SIEM within each satellite connectivity window
• Implement tamper-evident log storage with cryptographic chaining
• Define and enforce log retention policies of at least 12 months
• Review logs for anomalies at a defined frequency; do not rely solely on automated alerting
Secure Communication
All remote access sessions traverse public or semi-public networks — satellite links, cellular connections, port WiFi. Without encryption, session data is visible to anyone with access to the network path. The details of implementation determine whether encryption provides genuine or only nominal protection.
A vessel in port uses port-side WiFi for a vendor remote diagnostic session while the VSAT link is in economy mode. The port-side WiFi is not secured. Session credentials and command data are transmitted without verifying the encryption configuration of the connection.
• Certificate validation failures (accepting self-signed certificates) reduce encryption effectiveness
• Protocol downgrade attacks force encrypted sessions to use weaker cipher suites
IACS UR E26 requires that connections between shipboard CBS and external networks use secure communication protocols. BIMCO's Guidelines on Cyber Security Onboard Ships recommends encryption as a baseline control for all remote access.
• Validate certificates; prohibit certificate warnings from being bypassed by end users
• Conduct annual cryptographic configuration reviews as part of the IACS E26 assessment
• Document the encryption layer model (VPN outer + session inner) in the SCSRP
Vendor Access
Third-party vendor access is the most operationally complex remote access category. Vendors are legitimate and necessary, but they are outside the ship operator's direct control. Managing vendor access requires balancing operational necessity against security risk.
A propulsion system OEM has negotiated a service contract that includes "24/7 remote access for diagnostic support." This means the OEM has a persistent VPN credential used without notifying the ship operator. The ship master has no visibility into when the connection is active, what the engineer is doing, or how long the session runs.
• Vendors with unrestricted access may, intentionally or accidentally, modify configurations beyond their maintenance scope
• A vendor organization's own cybersecurity practices may be weaker than the ship operator's — a compromised vendor network becomes a pathway into the ship
IACS UR E27 places obligations on equipment manufacturers regarding the remote connectivity features they build into their products. IACS UR E26 requires that ship operators manage third-party access as part of their overall cyber risk management framework.
• Require vendor engineers to authenticate with individual named accounts, not shared service accounts
• Enable full session recording for all vendor sessions; provide session summaries to the ship operator
• Specify remote access security requirements in vendor contracts as binding obligations
File Transfer
File transfer is an often-overlooked attack vector because it bypasses the command-level controls that jump servers apply to interactive sessions. Many remote access sessions include file transfers: configuration files, diagnostic exports, log data, and software packages.
A vendor transfers a configuration file to the ship's power management system during a remote session. The file is not scanned for malware before transfer. The file contains a configuration modification the ship operator did not explicitly authorize and was not aware had been transferred.
• Files exfiltrated from ship systems during a vendor session may contain sensitive operational data
• Uncontrolled file transfer paths that bypass the jump server represent a secondary attack vector
IACS UR E26 requires that the ship maintain control over what connects to CBS. Uncontrolled file transfers to OT systems are a violation of the protection controls required under E26. IEC 62443-3-3 addresses integrity of data communicated between zones.
• Require explicit approval for configuration file transfers to OT systems
• Log all file transfers with cryptographic hash values to enable integrity verification
• Prohibit uncontrolled file transfer paths that bypass the jump server
Software Update
Remote software updates (OTA) are a critical maintenance function for modern shipboard CBS and one of the highest-risk remote access operations. A malicious or corrupted software update can fundamentally compromise a system. The update process must be at least as controlled as any other privileged remote operation.
A navigation equipment manufacturer pushes a firmware update to an onboard ECDIS via a direct connection to the manufacturer's cloud update server. The update is not logged in the ship's maintenance record. The ship master is not notified. The crew cannot verify the integrity of the installed software after the update.
• An update applied without crew awareness cannot be correlated with subsequent system anomalies during investigation
• Software version control is impossible if updates are applied outside a managed process
IACS UR E27 requires that on-board equipment manufacturers provide mechanisms for secure software updates, including integrity verification and version management. UR E26 requires that the ship maintain a software inventory for all CBS.
• Require explicit crew approval before applying updates to safety-critical CBS
• Log all software update events with version, hash, and authorization trail
• Maintain a current software inventory for all shipboard CBS
Cybersecurity of the Jump Server Itself
The jump server itself is a high-value target. If an attacker compromises the jump server, they gain access to everything the jump server controls. The security of the jump server platform is therefore as important as the security it provides.
A jump server is deployed on a standard server running a general-purpose Linux distribution. It is configured correctly at deployment. Over 18 months, OS security patches are not applied because the procedure requires taking it offline, which is operationally inconvenient. A publicly known vulnerability in the OS is exploited.
• Unpatched jump servers accumulate known vulnerabilities that are actively exploited in the wild
• A compromised jump server can be used to modify audit logs, concealing the attacker's activity
IACS UR E26 requires that protection controls are applied to the systems that provide protection — a jump server that is itself insecure undermines the entire remote access security model. CIS Benchmarks provide a practical hardening baseline.
• Establish a patch management schedule with a target patch latency of ≤30 days for critical patches
• Implement file integrity monitoring on the jump server
• Include the jump server in the scope of annual or biannual penetration testing
Maritime Environment
Ship systems operate in an environment fundamentally different from shore-based IT infrastructure: intermittent connectivity, harsh physical conditions, a constrained crew skill base, and operational priority that places safety of navigation above all else. A jump server not designed for this environment will fail in ways that matter.
During a voyage through a remote area with poor satellite coverage, the ship experiences an extended period of satellite connectivity loss. A planned OEM remote diagnostic session cannot be established. The crew has no documented fallback procedure and no way to notify the OEM that the session cannot proceed.
• Hardware not rated for maritime environmental conditions may fail due to vibration, humidity, or temperature extremes in the engine room
• Interfaces too complex for non-specialist crew will be misused, bypassed, or ignored
IEC 60945 defines environmental and EMC requirements for maritime navigation and communication equipment. IEC 62443 addresses security controls in industrial environments with reliability and availability constraints comparable to maritime OT.
• Design for satellite connectivity intermittency; ensure no critical function depends on always-on connectivity
• Test usability with representative crew members; simplify interfaces based on findings
• Document and train crew on jump server failure procedures and fallback processes
Compliance
Compliance is not a substitute for genuine security, but it is the mechanism by which security requirements are made enforceable and verifiable. Understanding which standards apply, what they require, and how the jump server architecture addresses those requirements is essential for vessels subject to IACS UR E26/E27 classification.
A ship operator schedules their first IACS UR E26 cyber survey. During preparation, they discover the jump server generates access logs but they have never been forwarded to a SIEM, have never been reviewed, and the retention period is 30 days. The surveyor requests 12 months of access records for a specific vendor session referenced in an incident report.
• An undocumented gap between the jump server capabilities and regulatory requirements cannot be tracked or remediated
• Audit evidence that cannot be produced on demand undermines the ship operator's position in an incident investigation
| Standard | Key Relevant Requirements | Jump Server Design Touchpoints |
|---|---|---|
| IACS UR E26 | Access control; audit trails; third-party access management | Authentication, Authorization, Audit Logging, Vendor Access |
| IACS UR E27 | Remote connectivity in CBS equipment; software update integrity | Software Update, Vendor Access, Secure Communication |
| IMO MSC.428(98) | Cyber risk management in SMS | Architecture, Vendor Access, Compliance documentation |
| IEC 62443-3-3 | Zone segmentation, access control, logging | Architecture, Session Management, Audit Logging |
| NIST SP 800-207 | Zero Trust principles | Authentication, Authorization, Session Management |
| ISO/IEC 27001 | Access control (A.9), cryptography (A.10), operations (A.12) | All domains |
Vessels contracted on or after 1 July 2024 are subject to IACS UR E26. Equipment installed on those vessels is subject to UR E27. All vessels subject to ISM Code are covered by IMO MSC.428(98). IEC 62443 is referenced as a technical standard by IACS.
• Generate compliance reports from jump server audit data at defined intervals (quarterly minimum)
• Include jump server review in the agenda for IACS annual cyber resilience assessments
• Document gaps with remediation timelines when capabilities do not yet meet all requirements
Lifecycle Management
A jump server deployed correctly in 2025 will face a different threat landscape in 2030. The security controls adequate today may not be adequate in five years. Lifecycle management ensures that the jump server continues to deliver protection throughout the vessel's operational life.
A jump server deployed during a vessel's new construction enters end-of-life for its underlying platform software three years after delivery. The vendor announces that no further security patches will be issued. The ship operator has no technology refresh plan and no alternative. The ship will operate for another 17 years.
• Access policies, user accounts, and authorization rules that are never reviewed accumulate stale and excessive access grants
• A decommissioned jump server that is not securely wiped contains configuration data, credential vault contents, and session recordings — all sensitive
IACS UR E26 requires that the SCSRP be maintained as a living document, implying that controls including the jump server must be reviewed and updated. ISO/IEC 27001 addresses asset management and security in the context of system lifecycle.
• Conduct quarterly access policy reviews at minimum
• Apply formal change management to all jump server configuration changes
• Include jump server lifecycle management in the ship's Planned Maintenance System (PMS)
• Document and execute a secure decommissioning procedure when replacing the platform
Secure remote access is a multi-domain problem. A jump server without correct authentication is a choke point without a lock. Each of the thirteen domains is necessary; none is sufficient alone.
The principle of least privilege must be applied at every layer: access scope (which systems), temporal scope (which time windows), and functional scope (which operations).
Audit logs are the security control that continues to work after an incident. Every other control attempts to prevent harm; logs enable understanding and recovery when prevention fails.
The maritime environment imposes real constraints on how remote access controls must be designed — connectivity intermittency, crew skill base, and operational priority require engineering decisions that pure IT security frameworks do not address.
Compliance documents what must be done; engineering determines whether it actually works. Treat regulatory requirements as minimum thresholds, not design targets.
Continue to Part 3 — a structured vendor evaluation framework with 55 technical evaluation items across 11 domains, designed for RFP processes, vendor demonstrations, and pre-contract technical due diligence.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment