How connectivity architecture creates attack surface — and how to design around it

Maritime cybersecurity coverage tends to focus on the vessel as an IT/OT environment — bridge systems, engine management, navigation. This is correct as far as it goes. What it underweights is the connectivity infrastructure that links those systems to the shore, and how the architecture of that infrastructure determines what an attacker can reach.

The VSAT terminal on your vessel is not just a communications device. It is a network node with its own operating system, remote management interfaces, and documented vulnerability history. How you design the connectivity architecture around it determines whether it is an entry point or a contained component.

How VSAT terminals create exposure

VSAT terminals have been shipped with factory-set administrative credentials that are identical across units and not required to be changed on installation. Where those credentials remain unchanged — which is common on vessels where the integrator who commissioned the system is no longer involved — anyone with network access to the terminal's management interface has administrative control.

Research by IOActive, published at Black Hat in 2014 and expanded in a 2018 follow-up, identified backdoors, hardcoded credentials, undocumented protocols, and weak password reset mechanisms across VSAT and satellite communications terminals from multiple major vendors. These were not theoretical vulnerabilities. They were exploitable against deployed equipment, and the 2022 NSA advisory on VSAT security specifically cited IOActive's research in its guidance to operators. The underlying vulnerability classes remain present in legacy equipment that has not been updated or replaced.

Password reset mechanisms on some legacy terminals allow administrative access to be obtained without knowledge of the current credential — under conditions that should require physical access but do not.

What happened when these weaknesses were exploited at scale

In March 2025, the hacktivist group Lab Dookhtegan disrupted satellite communications across 116 vessels belonging to Iran's National Iranian Tanker Company and Islamic Republic of Iran Shipping Lines. The attack vector was not a direct assault on individual vessel terminals. It was a supply-chain compromise of Fanava Group, an Iranian satellite communications provider serving both fleets. By compromising Fanava's hub infrastructure, the attackers gained root-level access to the Linux systems running VSAT terminals across the entire fleet simultaneously — one provider breach, 116 vessels affected.

The attackers disabled Falcon, the software controlling the ships' satellite communications, and conducted systematic data destruction — overwriting storage partitions, wiping navigation logs, message archives, system configurations, and recovery partitions. Restoring communications required technicians to physically board each vessel.

In August 2025 the same group executed a second wave against 64 further vessels from the same operators, with evidence that they had maintained persistent access since at least May — months before either attack was launched.

The lesson for operators outside Iran is not that Iranian vessels are uniquely vulnerable. It is that connectivity infrastructure managed through a shared provider creates a single point of failure across an entire fleet, and that the attack required no sophisticated exploitation of novel vulnerabilities. It required access to a provider with inadequate segmentation and vessels with no independent protection at the terminal layer.

The DNV ShipManager incident

The DNV ShipManager ransomware attack in January 2023 affected approximately 1,000 vessels across 70 customers when DNV was forced to shut down its server infrastructure. The entry vector was ashore. The incident is instructive because it demonstrated that the connection between shore and vessel is a bidirectional exposure path — an attack on shore-side infrastructure propagates to vessel-side systems. Segmentation between connectivity layers and vessel management systems matters in both directions.

How Starlink changes the threat model

Starlink introduces a different terminal type with a different vulnerability profile. Firmware update cadence is faster and the credential architecture differs from legacy VSAT. The out-of-the-box security posture is different — not necessarily better or worse in every dimension, but different in ways that require fresh assessment rather than assumption.

In a multi-bearer environment — VSAT plus Starlink plus LTE plus L-band — the attack surface is additive. Each bearer is a network entry point with its own routing, update mechanisms, and remote diagnostics pathway. An operator who understands their VSAT security model cannot assume that understanding carries over to a Starlink deployment.

Designing around the exposure

The architecture decisions that reduce attack surface are not primarily about terminal hardware — they are about the network design around it, and they begin with three questions a fleet manager should be able to answer about every vessel in the fleet.

What governance looks like

The USCG cybersecurity rule in force since July 2025 establishes a named Cyber Security Officer role for vessels calling at US ports. Connectivity architecture governance is a direct subset of that mandate — the connectivity layer is by definition the interface between the vessel and everything outside it.

The starting point is not a new stack. It is an inventory: every terminal, its credential state, its network adjacency, and its firmware version against the current vendor release. Most fleets do not have this. The ones that do are the ones that find out about a problem before it finds them.