Jump Server (Bastion Host) for Ships
What is a Jump Server and Why Ships Need One
A jump server (also called a bastion host or privileged access workstation) is a hardened, dedicated server that functions as the single controlled gateway through which all remote users must pass to reach internal shipboard systems. Rather than connecting directly from a shore office laptop to an ECDIS workstation or engine room AMS console — a path with no audit trail and no authentication enforcement — all remote access flows through the jump server, which enforces MFA, records sessions, and logs every command executed.
The core security principle of a jump server is the "single choke point" — by ensuring that all remote access must pass through one controlled system, the vessel operator gains complete visibility and control over who is accessing what, when, from where, and what they are doing. Without a jump server, each OT system or IT server may have its own access method (VPN, modem, RDP, SSH) with its own credentials and no centralised logging — creating an access management problem that scales linearly with the number of systems on board.
Maritime jump servers are particularly important for controlling OEM vendor access. Vendors such as Wärtsilä, MAN Energy, Kongsberg, and Furuno often require remote access to their equipment for maintenance, diagnostics, and software updates. Without a jump server, these vendors typically connect via permanent VPN accounts or direct modems — pathways that persist indefinitely, are rarely audited, and have been implicated in several documented maritime cyber incidents.
| Security Control | Direct VPN/RDP | Jump Server |
|---|---|---|
| Centralised Authentication | ✗ Per-system credentials | ✓ Single MFA gateway |
| Session Recording | ✗ No audit trail | ✓ Full video + keystroke log |
| Vendor Access Time-Limiting | ✗ Permanent credentials | ✓ Time-bounded, auto-expire |
| Access Scope Control | ✗ Full network access | ✓ System-specific access only |
| Forensic Investigation Support | ✗ No evidence available | ✓ Complete session replay |
Regulatory Framework
IACS UR E26 Clause 6.3 requires that remote access to computer-based systems supporting ship operations be authenticated, authorised, and logged. A jump server is the principal technical implementation of this requirement — providing centralised authentication (with MFA), authorisation (scope-limited system access), and logging (session recording) for all remote connections. Class surveyors will request evidence of jump server deployment or equivalent remote access controls during cyber notation audits.
Jump servers directly implement the privileged access logging requirement in E26 Clause 4.3. All sessions that pass through the jump server — by definition involving users with sufficient privilege to be accessing shipboard systems remotely — are recorded with sufficient detail for forensic investigation. The 90-day log retention requirement applies to jump server session logs.
BIMCO/ICS Maritime Cyber Security Guidelines explicitly require that third-party vendor access to shipboard systems be controlled, time-limited, and monitored. The guidelines recommend that all vendor remote access pass through a controlled access mechanism — a jump server being the primary technical implementation. This is now a standard requirement in many charterers' cybersecurity questionnaires (TMSA3, RightShip).
IMO cyber risk management guidelines require identification of all access pathways to ship systems and implementation of protection measures for those pathways. A jump server consolidates remote access into a single, protected pathway — satisfying the Identify requirement by making all remote access visible through one system, and the Protect requirement by enforcing authentication and monitoring on that pathway.
Architecture & Performance Standards
A maritime jump server is typically a hardened server or virtual machine in the ship's IT DMZ, positioned between the external access point (VSAT/Starlink gateway) and the internal OT and IT networks. All remote protocol sessions — RDP, SSH, VNC, web-based console — terminate on the jump server and are proxied through to the target system, never establishing a direct connection between the remote user and the OT device.
RDP (Windows OT/IT workstations), SSH (Linux/network devices), VNC (HMI graphical consoles), HTTPS (web management interfaces), Telnet bridging for legacy OT devices
Minimal OS footprint, no unnecessary services, MFA mandatory for all access, no direct internet access, automatic session timeout after inactivity, OS patching on defined schedule
Screen video recording at defined interval, keystroke logging, command-level audit for SSH sessions, database query logging for DB access, indexed and searchable archive with 90-day minimum retention
Time-bounded access windows, system-scoped access lists per user/vendor, approval workflow integration, automatic credential expiry, concurrent session limiting, geographic access restrictions
| Performance Metric | Minimum | Target | Note |
|---|---|---|---|
| Session Establishment Time | <30 sec | <10 sec | Operational responsiveness |
| Availability | 99.5% | 99.9% with HA | Required for vendor maintenance |
| Session Recording Storage | 90-day local | 12 months with shore archive | IACS E26 log retention |
| Concurrent Sessions | 10 simultaneous | 50+ (fleet sizing) | Per vessel requirement |
Maritime Implementation Constraints
Remote desktop sessions proxied through a jump server over VSAT satellite links experience 600–800ms round-trip latency — making graphical sessions (RDP, VNC) sluggish and difficult to operate for complex tasks. Protocols with high screen update rates are particularly affected. Text-based protocols (SSH) are more tolerant of latency. Session optimisation (display compression, protocol optimisation) can reduce the impact but cannot eliminate it for high-latency links.
If the jump server fails and there is no alternative access pathway, legitimate remote access for vendor maintenance or superintendent oversight is blocked. Maritime jump servers must either be deployed in HA (high availability) pairs or have a documented, controlled emergency bypass procedure that is only usable with explicit authorisation and post-event logging. A jump server failure should never block safety-critical maintenance access.
Some legacy OT systems communicate only via Telnet, serial-over-TCP, or proprietary vendor protocols that standard jump server products do not support as proxied session types. Custom protocol bridges or direct hardware serial access may be required for these systems — reducing the security benefit of the jump server for those specific access paths and requiring compensating controls.
Major OEMs may resist routing their remote access through a third-party jump server, citing warranty terms, SLA requirements, or proprietary tool dependencies. Shipowners must negotiate updated vendor access clauses in maintenance contracts that require compliance with jump server access policies. This is a commercial and legal process that must run in parallel with technical deployment — often taking longer than the technical implementation itself.
Trends & Market Developments
Purpose-built maritime remote access platforms (Cydome, OneSeaConnect, Secomea) combine jump server, PAM, and session management in appliances pre-configured for shipboard deployment — reducing implementation complexity for operators without dedicated OT security teams.
ZTNA is replacing traditional jump server + VPN architectures for shore-to-ship access. ZTNA provides per-application access control rather than network-level access, eliminating the lateral movement risk of VPN connections while maintaining the controlled gateway principle of the jump server. Maritime ZTNA vendors are emerging with solutions validated for shipboard OT environments.
Jump server session recordings are increasingly being analysed in real-time by ML models that detect anomalous behaviour — a technician accessing files outside the expected scope, command patterns inconsistent with the stated maintenance purpose, or evidence of data exfiltration during a vendor session. This transforms session recording from passive forensic evidence to active security monitoring.
Rather than deploying individual jump servers on each vessel, some operators are deploying centralised shore-side jump infrastructure that provides remote access services for entire fleets — reducing the per-vessel cost and management overhead while concentrating security monitoring at the shore. Starlink connectivity is making this architecture viable for the first time at acceptable latency levels.
A jump server is the single highest-impact control for remote access security on ships. It converts an uncontrolled, invisible attack surface (multiple VPNs, direct modems, shared credentials) into a single, audited, MFA-enforced gateway — directly satisfying IACS UR E26 Clause 6.3 remote access requirements.
Vendor access control is the primary use case. Eliminate permanent vendor VPN credentials as the first step. Routing all OEM remote access through the jump server with time-limited, approval-gated sessions is the most impactful maritime remote access security improvement most operators can make.
Design for HA and emergency bypass. A jump server that becomes a single point of failure for critical maintenance access is operationally unacceptable. Redundant deployment and a documented emergency bypass procedure with post-event reporting are mandatory requirements, not optional additions.
Continue the Remote Access series with SVRA and OTRAA deep-dives for vendor-specific and OT-native authentication solutions.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment