HomeStarlink Changed Ship Connectivity. Zero Trust Could Change Who Gets Into the Engine Room

Starlink Changed Ship Connectivity. Zero Trust Could Change Who Gets Into the Engine Room

September 16, 2026

🔔 Subscribe to ShipUniverse Weekly →

Maritime Tech • Remote OT Access

Beyond the VPN: Zero-Trust Remote Access for Ships in the Starlink Era

There was a time when remote access to a ship meant a slow connection opened because somebody had a problem. An engineer ashore logged in, fixed the equipment and got back out. LEO connectivity has changed that equation. Ships can now maintain fast, persistent links to shore, which is excellent for machinery support, software updates and fleet operations, but it also means the route into the engine room network can be available twenty-four hours a day. The serious question now is not whether remote support should exist. It is how much of the ship a technician should be trusted to see after logging in.

⚓
The distinction matters: Zero Trust does not mean encryption or VPN technology suddenly becomes useless. Secure tunnels can still carry traffic. The change is that successfully entering a tunnel should not automatically create broad trust inside the ship's network.
94.7 Mbps Average Starlink downlink measured during vessel testing
38.2 ms Average round-trip latency in the vessel experiment
8.4 sec Zero Trust architecture mean time to detect in testing
1.3 min Mean response time under the tested SRA architecture
2.6% Measured throughput cost of the added access mediation

The connection changed faster than the access model

Satellite bandwidth is no longer the same constraint it once was. Remote diagnostics, software support and OEM troubleshooting can now feel almost like working across a shore-side network. That convenience puts more pressure on the architecture behind the login.

Traditional approach

Authenticate the user, then enter the network

  • VPN establishes a protected tunnel.
  • Network rules decide which internal ranges are reachable.
  • Privileges can remain broad for the session.
  • Activity may be visible primarily at the connection or gateway level.
  • Compromised credentials can create a path for lateral movement if segmentation is weak.
→
Zero Trust approach

Authorize the identity, device and requested resource

  • User identity is checked before the resource is exposed.
  • Device and session context can become part of the decision.
  • Access is limited to the specific application or system required.
  • Policies can be evaluated throughout the session.
  • The technician does not need general visibility of the surrounding OT network.

The ship becomes its own trust boundary

The September 2026 research used a two-boundary design: identity was checked on the shore side, then access was enforced again at the shipboard access point. The architecture was tied to IEC 62443 zones and conduits rather than treating the vessel as one trusted network.

A practical remote-support path

Remote access is mediated from the technician to the exact onboard resource rather than simply opening a route into OT.

External
OEM / Shore Technician Named user, managed device, support request and defined work scope.
→
Trust Boundary 1
Identity & Access Manager MFA, identity verification, authorization policy and session request.
→
Trust Boundary 2
Shipboard Access Point Resource policy, session enforcement, logging and vessel-side control.
→
OT Zone
Approved Ship System Engine HMI, PMS, cargo system or other specifically authorized target.
Shore-side question: Is this really the engineer, on an acceptable device, asking for a permitted job?
Ship-side question: Should this session reach this specific OT resource right now?

The September vessel trial put numbers on it

Researchers Jeoungkyu Lim and Yunja Yoo tested a Zero Trust Secure Remote Access architecture aboard a crude-oil tanker under construction, using Starlink as the shore connection and two onboard OT systems as targets.

2026 Full-Scale Validation

Not a desktop-office VPN test

The experiment was designed around shipboard OT, satellite connectivity and maritime cyber requirements rather than normal corporate remote work.

Platform Crude-oil tanker
Connection Starlink LEO satellite
Targets Two onboard OT systems
Testing 10 functional + 4 adversarial scenarios
Frameworks IACS E26/E27, IEC 62443, NIST Zero Trust

Measured results

100% Unauthorized access attempts blocked in the reported testing
8.4 sec Mean time to detect versus 37.2 minutes in the study's VPN baseline
1.3 min Mean time to respond versus 22.5 minutes in the baseline
+2.5 sec Additional session-establishment time from SRA mediation
2.6% Measured throughput overhead
80–100% Initial automated blocking across the adversarial scenarios
Important comparison limit: the study compared the architecture with a manually monitored VPN baseline, not a hardened VPN environment with modern IDS, SIEM, strong segmentation and automated response. One privilege-escalation case initially exposed an incomplete policy rule; the researchers report that policy refinement closed the gap.

VPN, jump server and Zero Trust solve different parts of the problem

None of these terms alone tells an owner whether a vessel is secure. A tightly segmented VPN with MFA and monitoring can be considerably stronger than a poorly configured Zero Trust product. The architectural difference is where trust is granted and how narrow the permitted path can become.

Control Conventional VPN VPN + Jump Server Zero Trust SRA Owner concern
Encrypted transport Strong capability Strong capability Strong capability Encryption is necessary, but does not determine the permitted reach after authentication.
User identity Depends on deployment Can be centralized Identity-centric Shared vendor accounts should disappear from critical OT support workflows.
Device posture Optional Optional Can become policy input A valid engineer using a compromised laptop can still create risk.
Resource-level access Often network/range based Improved chokepoint Core design objective Technician access to one HMI should not automatically reveal adjacent OT systems.
Lateral movement resistance Relies heavily on segmentation Better if jump host is isolated Can remove broad network reach The blast radius after stolen credentials matters more than the login screen.
Session-level authorization Usually limited Possible with tooling Policy-driven Access can be tied to user, system, timing, device and requested action.
Central session logging Tunnel logs common Strong potential Designed for granular audit Owners need to answer who entered, which resource they reached and when.
Onboard approval Must be engineered Must be engineered Can be built into policy flow IACS E26 requires remote access to be explicitly accepted by a responsible onboard role.
Immediate vessel-side termination Depends on implementation Can be centralized Natural enforcement point The ship must retain authority to end a remote session.
Third-party scale Can become credential-heavy Manageable Strong fit for many identities Modern vessels may have many OEMs requiring occasional access to different systems.

IACS is already asking the questions owners should be asking

UR E26 does not require a product with “Zero Trust” written on the box. It does, however, describe a remote-access posture that pushes owners toward tighter identity, segmentation, approval and session control.

No exposed CBS IP address In-scope computer-based systems should not expose their IP address directly to untrusted networks.
Secure connection Communications across untrusted networks require protected connections, authentication and integrity protection.
MFA for human remote access Human remote-maintenance users connecting from an untrusted network require multi-factor authentication.
Explicit onboard acceptance A responsible role onboard must accept the remote connection before access begins.
Vessel-side termination The onboard endpoint must be able to terminate access rather than relying entirely on the remote technician.
Remote-session logging Remote-access events need records suitable for later review and cyber-incident investigation.
Failure-safe disconnect A disrupted remote-maintenance connection should automatically terminate access.
Abort and roll back Authorized personnel need the ability to interrupt maintenance and return the system to a previous safe configuration.

The buying opportunity sits between connectivity and OT

Shipowners already pay for satellite capacity and they already pay OEMs to support critical equipment. Secure remote access creates a third layer between those two services, and that layer can become a meaningful fleet-wide technology category.

High-Value Products & Services

The strongest commercial opportunities are products that control, observe or document the route from shore identity to a specific onboard asset.

01

Maritime Secure Access Gateways

Vessel-side enforcement appliances or software gateways that mediate every remote connection into OT.

Hardware + Software
02

Industrial Firewalls & OT Segmentation

Zones, conduits, VLAN architecture, firewall policy and hardened boundaries around machinery and navigation networks.

Fleet Retrofit
03

Identity & Privileged Access Management

Named identities, MFA, short-lived privileges, vendor onboarding and immediate access revocation.

Platform / SaaS
04

OEM Remote-Support Platforms

Controlled diagnostic access for engine, automation, cargo, propulsion and navigation equipment suppliers.

Recurring Service
05

OT Network Monitoring

Passive detection of unexpected devices, connections, traffic changes and suspicious behavior inside shipboard OT.

Monitoring Platform
06

Fleet SOC / MDR

Shore-based teams that correlate vessel access events, alerts and endpoint activity across the fleet.

Managed Service
07

Endpoint Security & Device Posture

Controls that decide whether a vendor laptop or engineering workstation is healthy enough to reach the requested system.

Endpoint + Identity
08

IACS / IEC 62443 Integration Consulting

Architecture reviews, zones and conduits, remote-access procedures, evidence packages and ship-specific testing.

Engineering Advisory

Six questions worth asking every OEM

1. Can you see anything beyond your equipment? If the answer is yes, the remote-access scope may already be wider than necessary.
2. Does every technician have an individual identity? Shared support credentials make accountability and rapid revocation difficult.
3. Can the vessel approve each connection? Remote access should not silently appear because an OEM decided to connect from shore.
4. Can the ship terminate the session instantly? Vessel personnel should retain control when maintenance affects critical OT.
5. Can you prove exactly what happened? Login time alone is less useful than resource, identity, policy and session activity records.
6. What happens when Starlink drops? Lost connectivity should produce a predictable safe state, not an orphaned privileged session.
Research basis: Lim & Yoo, International Journal of Critical Infrastructure Protection, September 2026, “Design and experimental validation of a secure remote access architecture for cyber-resilient smart ships”; IACS UR E26 Rev.1, Cyber Resilience of Ships; IACS UR E27 Rev.1, Cyber Resilience of On-Board Systems and Equipment; IEC 62443-3-2 and IEC 62443-3-3; NIST SP 800-207 Zero Trust Architecture. Study performance figures are reported results from the specific experimental setup and should not be treated as guaranteed fleet performance.
Interactive Comparison

Ship Cyber Exposure Score

Compare a conventional VPN, a controlled jump-server design and a Zero Trust secure-access architecture under the same vessel operating conditions.

Estimated Remote-Access Exposure
Ship Universe illustrative score. Lower is better. This is not an IACS, class or IEC 62443 compliance assessment.
VPN + MFA 72/100
VPN + Controlled Jump Server 49/100
Zero Trust Secure Remote Access 27/100
Largest remaining gap: onboard approval and session monitoring are not enabled in this scenario.
    Feedback Welcome

    We welcome your feedback, suggestions, corrections, and ideas for enhancements.

    Please click here to get in touch
    By the ShipUniverse Editorial Team — About Us | Contact