Part 3. How to Evaluate a Maritime Jump Server Solution
Selecting a maritime jump server solution is an engineering and procurement decision with long-term operational consequences. A solution marketed as maritime-ready but lacking the specific capabilities required by IACS UR E26/E27 will leave compliance gaps and security exposures that are difficult to remediate after deployment.
The goal of this article is not to recommend a specific product. The goal is to equip evaluators with the questions that distinguish solutions that genuinely meet maritime requirements from those that do not. For each evaluation domain: questions to ask, why they matter, what a good answer looks like vs. a weak one, and the operational risk if the answer is weak.
Ask the questions during vendor demonstration, written RFP response, or technical reference check.
Score the response against Good Answer / Weak Answer criteria.
Assess the operational risk if the answer is weak and remediation is not feasible.
Apply the recommended best practice as a design or contractual requirement.
This framework is intended to be used alongside — not instead of — technical proof-of-concept testing in a representative environment.
Architecture
Architecture is the foundation on which all other security controls rest. If the solution cannot enforce a single ingress point, or if it requires constant cloud connectivity to function (which satellite links cannot always guarantee), the security model breaks down at sea.
The solution enforces a mandatory transit policy at the network layer, not only at the application layer. Direct connections to internal systems are blocked by firewall rules configured as part of the deployment architecture. The solution can operate in degraded-but-functional mode during satellite outages, queuing access requests and logs until connectivity is restored. High-availability configurations are available and tested.
The solution relies on policy documentation and crew compliance (not technical enforcement) to prevent bypassing. Cloud connectivity is required for license verification or access policy lookups. Redundancy is described as "achievable with additional configuration" but is not part of the standard deployment.
A solution that can be bypassed will be bypassed, particularly when operational pressure creates incentives to shortcut the access request process. Cloud-dependent solutions create single points of failure in environments where connectivity is intermittent by nature.
Require the vendor to demonstrate enforcement of single-ingress-point architecture in a lab environment that simulates satellite connectivity interruption. Include architecture enforcement as a testable acceptance criterion.
Authentication
Authentication is the first control that must succeed for any security model to function. MFA that is optional in practice will not be used consistently. Shared accounts that are technically possible will be used, particularly by vendors who find individual account provisioning inconvenient.
MFA is mandatory and cannot be disabled for any user class. Individual accounts are the only supported access model — the system does not provide a "group" or "shared" account type. Credential vaulting is built in and can inject OT system credentials into sessions without exposing the credential to the end user. Emergency access procedures exist but require multi-party approval and generate an automatic alert.
MFA is available but can be disabled by administrators. Shared accounts are technically supported, with guidance that they "should not be used." Credential vaulting is described as a planned feature or a third-party integration. Emergency bypass is available to a single administrator without notification.
Optional MFA will be disabled under operational pressure. Shared accounts make audit trails meaningless for individual attribution. An uncontrolled emergency bypass is effectively a persistent backdoor.
Require a technical demonstration that shared accounts cannot be created and that MFA cannot be disabled at the user level. Test the emergency access procedure and verify that it generates an auditable alert.
Authorization
Authorization determines the blast radius of a compromised session. A solution that grants access to a network segment rather than a specific system means a compromised OEM session could reach systems far beyond the vendor's legitimate scope.
Access policies are defined at the level of individual target systems, not network segments. Role-based access control allows creation of vendor-specific roles with tightly scoped access. Time-bounded access windows expire automatically without requiring the vendor to initiate disconnection. All authorization changes are logged with the identity of the administrator who made them and a timestamp.
Access policies are defined at the VLAN or network segment level. There is no time-bounding feature; sessions remain valid until manually revoked. Authorization change logs exist but are not tamper-evident.
Segment-level access allows lateral movement within the segment during a vendor session. Access that does not expire requires active management; in practice, vendor access credentials often remain valid long after the maintenance event that created them.
Require a demonstration of system-level access scoping. Test that a session with a deliberately restricted scope cannot reach a system outside that scope, even if the target system is on the same network segment.
Session Management
Session management controls prevent the security risks that occur during a session, not just at connection establishment. A session that is not monitored in real time can be the vehicle for extended unauthorized activity that goes undetected until after the session ends.
Idle timeout is configurable per access role and per target system type, with defaults for OT access set at ≤15 minutes. Active sessions are visible to both the on-board responsible officer and the shore-based SOC simultaneously, with a real-time command stream view. Any authorized party can terminate a session with a single action, and termination takes effect within seconds.
Idle timeout is a global setting, not configurable per session type. Session monitoring is available only to the party that initiated the session (the vendor). Termination requires contacting the shore-based administrator by a separate channel.
Sessions that the ship cannot monitor or terminate in real time effectively transfer control of the ship's systems to an external party for the duration of the session. Undefined behavior during satellite outages may leave sessions in an indeterminate state.
Test session termination from both the shipboard and shore-based interfaces during a live vendor session. Test behavior during a simulated satellite outage during an active session.
Audit Logging
Logs are the primary forensic resource after an incident and the primary evidence for compliance audits. A solution that logs only connection metadata without logging session content is insufficient for either purpose.
Full session recording includes keystrokes, screen capture at configurable intervals, and file transfer metadata. Logs are forwarded to a shore-based SIEM in near real-time during satellite connectivity windows. Log entries are cryptographically chained; any modification is detectable. Retention is configurable and defaults to 12 months.
Only connection events (login/logout) are logged. Logs are stored solely on the ship's local server. There is no tamper-detection mechanism. Log export requires manual intervention by an administrator. Retention is fixed at 90 days.
Connection-only logs cannot support incident investigation. Knowing that a vendor connected does not determine what they did during the session. Ship-side-only log storage means logs may be modified or destroyed if the jump server is compromised.
Request a sample session recording from the vendor's test environment. Verify that it captures sufficient detail to reconstruct a complete account of the session without requiring additional sources.
Secure Communication
Encryption is non-negotiable for remote access over satellite links. However, the details of implementation — which cipher suites, how certificates are managed, whether validation errors can be bypassed — determine whether the encryption provides genuine protection or only nominal protection.
TLS 1.3 is supported and preferred; TLS 1.0 and 1.1 are disabled. Cipher suites follow NIST SP 800-52 guidance. Certificate management integrates with common enterprise PKI systems. Certificate validation errors are not bypassable by end users; they are logged and generate an alert. The solution documentation explicitly addresses layering with VSAT link encryption.
TLS version and cipher suite configuration requires manual intervention post-deployment. Self-signed certificates are used by default for internal components. Users can bypass certificate warnings with a checkbox. The solution documentation does not address satellite connectivity layering.
Weak cipher suites or bypassable certificate validation means encryption may be present in form but ineffective against a determined adversary with network access to the satellite link path.
Conduct a TLS configuration audit using a tool such as testssl.sh against the jump server's exposed interfaces before accepting the solution.
Vendor Access
Vendor access management is operationally the most complex and most commonly mishandled remote access category. Solutions that require significant administrative overhead for every vendor access event will face pressure to simplify by creating persistent vendor credentials.
The solution provides a vendor self-service portal where access requests are submitted, specifying the target system, purpose, and requested time window. The ship-side responsible officer receives a notification and can approve or deny with a single action. When approved, credentials are automatically provisioned for the specified window and automatically expired when the window closes. A session summary is delivered at session end.
Each vendor access event requires manual account creation by an administrator. There is no self-service portal. Notifications are described as "available via SIEM integration" but are not native. Session summaries must be manually exported from logs.
High administrative overhead creates incentive to maintain persistent vendor credentials, which is the practice the JIT model is designed to replace.
Simulate the complete vendor access lifecycle — request, approval, session, and expiry — with the vendor before purchase. Evaluate the time required from access request to session establishment.
File Transfer
File transfer to ship systems — particularly to OT systems — is a high-risk operation that deserves independent authorization controls, not just session-level authorization. A vendor authorized to run diagnostics is not necessarily authorized to transfer configuration files.
File transfer uses a controlled protocol (SFTP through the jump server, not a separate direct channel). Inline malware scanning is available. All transfers are logged with filename, size, SHA-256 hash, direction, and timestamp. File transfers to OT systems require separate authorization. A separate approval step is triggered for executable files, archives, and scripts.
File transfer uses whatever protocol the vendor's client supports, including direct SCP or FTP that may bypass the jump server. No malware scanning is available. File transfer logging records only the occurrence of a transfer, not the file metadata.
Files transferred to OT systems without inspection are an uncontrolled malware introduction vector. Without hash logging, there is no way to verify after the fact that a transferred file is the file the vendor claims to have transferred.
Test file transfer inspection by attempting to transfer a known-malicious test file (EICAR test signature) through the jump server. Verify that the transfer is blocked and that the attempt is logged and alerted.
Software Update
Software updates to shipboard CBS are among the highest-consequence operations performable via remote access. A corrupt or malicious update can disable a safety system or introduce persistent malware. The update process must be at least as controlled as any other privileged remote operation.
Software updates are delivered as a distinct workflow with mandatory signature verification before deployment. The solution can be configured to prevent deployment of unsigned or signature-invalid packages. Update events are logged with package metadata (name, version, hash, signature status) and integrated with the ship's maintenance system via API. Staging environments are supported. Crew approval is required before update deployment to critical systems.
Software updates are treated as file transfers with no distinct controls. Signature verification is described as "supported by the target system" and is outside the jump server's scope. Maintenance system integration is not available.
Software updates without signature verification are a supply chain attack vector. An attacker who can intercept or redirect the update channel can deliver malware packaged as a legitimate update.
Test OTA update delivery with an intentionally tampered package and verify that the signature check fails and blocks deployment.
Cybersecurity of the Jump Server Platform
The jump server is the highest-privilege component in the remote access architecture. An attacker who compromises the jump server gains control of all access paths it manages. The jump server's own security posture must be as strong as — ideally stronger than — the systems it protects.
The platform is hardened to a documented standard (CIS Benchmark, DISA STIG). The vendor publishes a security advisory feed and commits to patch availability within defined timeframes (e.g., critical patches within 14 days of CVE publication). Annual penetration testing is performed by an independent third party; reports are available to customers under NDA. Platform integrity is monitored with file integrity monitoring.
Hardening is described as "standard server security practices" without reference to a documented standard. Patch timelines are not committed to in writing. Penetration testing reports are not available. Platform monitoring is limited to uptime monitoring.
A poorly secured jump server is a high-value target. Attackers who compromise a jump server gain access to all systems it protects, with full audit capability to conceal their activities.
Request the vendor's CVE history for the past 24 months and assess the average time from CVE publication to patch availability. Request the most recent penetration test report abstract.
Lifecycle Management
A jump server deployed today will be maintained for the life of the vessel — potentially 20 years or more. A vendor that drops the product or changes licensing terms mid-lifecycle creates a significant operational risk.
The vendor commits to a minimum 5-year support lifecycle per major platform version. Major version upgrades are available through a documented upgrade path with migration tooling. Integration APIs support connection to common asset management and SIEM platforms. Decommissioning includes a documented data retention and secure deletion process.
Support lifecycle is described as "ongoing" without committed timelines. Major version upgrades require a fresh deployment. There is no integration with external systems. Decommissioning is not addressed in vendor documentation.
An EOL platform receives no security patches, leaving the highest-privilege component in the remote access architecture permanently vulnerable.
Require a contractual commitment to a minimum support lifecycle and defined patch response timelines. Include a technology refresh clause in the procurement contract.
55-Item Vendor Evaluation Checklist
Structured for use in RFP evaluation, vendor demonstrations, and pre-contract technical due diligence. Score each item Y (Yes / fully met), N (No / not met), or P (Partial / partially met).
| Item | Evaluation Criterion | Score | Notes |
|---|---|---|---|
| A-01 | Solution enforces single-ingress-point at the network layer (not policy-only) | Y / N / P | |
| A-02 | Solution operates in degraded mode during satellite connectivity loss | Y / N / P | |
| A-03 | High-availability configuration is available and tested | Y / N / P | |
| A-04 | OT and IT zone separation is supported in deployment architecture | Y / N / P | |
| A-05 | No cloud dependency for core access control functions | Y / N / P |
| Item | Evaluation Criterion | Score | Notes |
|---|---|---|---|
| B-01 | MFA is mandatory and cannot be disabled for end users | Y / N / P | |
| B-02 | Shared / group accounts are not technically supported | Y / N / P | |
| B-03 | Credential vaulting for OT system accounts is available | Y / N / P | |
| B-04 | Emergency bypass requires multi-party approval and generates alert | Y / N / P | |
| B-05 | Certificate-based authentication is supported for system-to-system access | Y / N / P |
| Item | Evaluation Criterion | Score | Notes |
|---|---|---|---|
| C-01 | Access policies are definable at the individual target system level | Y / N / P | |
| C-02 | Time-bounded access windows are enforced automatically (not manually revoked) | Y / N / P | |
| C-03 | Role-based access control (RBAC) is supported | Y / N / P | |
| C-04 | Authorization change events are logged with identity and timestamp | Y / N / P | |
| C-05 | Deny-all default with explicit permit model is supported | Y / N / P |
| Item | Evaluation Criterion | Score | Notes |
|---|---|---|---|
| D-01 | Idle timeout is configurable per session type / target system | Y / N / P | |
| D-02 | Maximum session duration can be enforced independent of idle state | Y / N / P | |
| D-03 | Active sessions visible simultaneously to ship and shore personnel | Y / N / P | |
| D-04 | Session termination executable by ship-side officer (single action) | Y / N / P | |
| D-05 | Concurrent session limits per user account are enforced | Y / N / P |
| Item | Evaluation Criterion | Score | Notes |
|---|---|---|---|
| E-01 | Full session recording (keystrokes, screen, file metadata) is available | Y / N / P | |
| E-02 | Logs are forwarded to shore-based SIEM during connectivity windows | Y / N / P | |
| E-03 | Logs are tamper-evident (cryptographic chaining or equivalent) | Y / N / P | |
| E-04 | Log retention is configurable to ≥12 months | Y / N / P | |
| E-05 | Logs are accessible via API for compliance management integration | Y / N / P |
| Item | Evaluation Criterion | Score | Notes |
|---|---|---|---|
| F-01 | TLS 1.3 supported; TLS 1.0/1.1 disabled by default | Y / N / P | |
| F-02 | Cipher suites follow current NIST SP 800-52 guidance | Y / N / P | |
| F-03 | Certificate validation errors cannot be bypassed by end users | Y / N / P | |
| F-04 | Certificate management integrates with enterprise PKI | Y / N / P | |
| F-05 | All internal inter-component communications are encrypted | Y / N / P |
| Item | Evaluation Criterion | Score | Notes |
|---|---|---|---|
| G-01 | Just-in-time access provisioning is supported | Y / N / P | |
| G-02 | Vendor self-service access request portal is available | Y / N / P | |
| G-03 | Ship-side approval workflow (approve/deny) is native functionality | Y / N / P | |
| G-04 | Automatic session summary is generated at session end | Y / N / P | |
| G-05 | Automatic credential expiry at end of approved time window is enforced | Y / N / P |
| Item | Evaluation Criterion | Score | Notes |
|---|---|---|---|
| H-01 | File transfers are routed through the jump server (no out-of-band paths) | Y / N / P | |
| H-02 | Inline malware scanning is available for transferred files | Y / N / P | |
| H-03 | File transfers logged with filename, size, hash, direction, timestamp | Y / N / P | |
| H-04 | Elevated authorization required for executable files and scripts | Y / N / P | |
| H-05 | File transfer to OT systems requires separate authorization from session | Y / N / P |
| Item | Evaluation Criterion | Score | Notes |
|---|---|---|---|
| I-01 | OTA update delivery is supported as a distinct controlled workflow | Y / N / P | |
| I-02 | Cryptographic signature verification is performed before deployment | Y / N / P | |
| I-03 | Update events are logged with package metadata and signature status | Y / N / P | |
| I-04 | Staging/testing environment support is available before production deployment | Y / N / P | |
| I-05 | Crew approval workflow for critical system updates is supported | Y / N / P |
| Item | Evaluation Criterion | Score | Notes |
|---|---|---|---|
| J-01 | Platform hardening follows a documented standard (CIS, DISA STIG, or equivalent) | Y / N / P | |
| J-02 | Vendor commits to critical patch availability within 14 days of CVE | Y / N / P | |
| J-03 | Annual third-party penetration testing is performed; reports available under NDA | Y / N / P | |
| J-04 | File integrity monitoring is implemented on the platform | Y / N / P | |
| J-05 | Platform health monitoring and alerting is available | Y / N / P |
| Item | Evaluation Criterion | Score | Notes |
|---|---|---|---|
| K-01 | Minimum 5-year support lifecycle per major version is contractually committed | Y / N / P | |
| K-02 | Documented upgrade path from current version to future major versions | Y / N / P | |
| K-03 | Integration with asset management and SIEM platforms is available | Y / N / P | |
| K-04 | Decommissioning process includes documented data deletion procedure | Y / N / P | |
| K-05 | Technology refresh clause is acceptable in procurement contract | Y / N / P |
| Score | Interpretation | Recommended Action |
|---|---|---|
| All items Y | Meets evaluation criteria | Proceed to PoC testing |
| ≤3 items N or P | Minor gaps | Request remediation plan before contract |
| 4–8 items N or P | Significant gaps | Do not proceed without written gap remediation commitment |
| >8 items N or P | Fundamental capability deficiencies | Disqualify or re-scope to different solution category |
Evaluate solutions against documented requirements, not marketing claims. Every vendor will describe their solution as "maritime-ready" and "IACS UR E26-aligned." These claims must be verified through technical demonstration.
Operational usability is a security property. A solution that is too complex for crew to operate correctly will be bypassed or misconfigured. The jump server must be designed for the maritime operational environment, not just the maritime network environment.
Test the failure modes as well as the success modes. Simulate satellite outages, credential failures, session anomalies, and certificate errors during evaluation. How a solution fails is as important as how it succeeds.
Lifecycle commitment is as important as current capability. A solution that is excellent today but unsupported in three years creates a worse long-term risk posture than a solution that is adequate today with a strong support roadmap.
Contractual requirements are the enforcement mechanism for technical requirements. Every capability required from the vendor should be stated in the contract, with remediation timelines and service level commitments.
This concludes the Jump Servers for Modern Ships series. For architecture design, return to Part 2. For the conceptual foundation, see Part 1. Use the 55-item checklist in your next procurement evaluation.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment