A vessel’s isolation used to be its own cyber defence — weeks at sea with no meaningful connectivity meant no meaningful remote attack surface, whatever the ship’s onboard systems actually looked like underneath. Low-earth-orbit satellite connectivity has quietly ended that protection for a huge share of the global fleet, and a great deal of maritime cyber governance still assumes the old isolation is holding.
I’ve written about maritime cyber resilience beyond MSC.428(98) generally, and about OT/IT segmentation as the core control. Starlink and comparable low-earth-orbit connectivity is the specific technology shift that makes both pieces urgent in a way they weren’t even three years ago — because the assumption underneath a great deal of existing maritime cyber posture was that a vessel’s remoteness was itself a meaningful control, and that assumption is now simply false for any vessel carrying this connectivity.
Why this connectivity shift is structurally different from previous ones
Vessels have carried some form of satellite connectivity for years — but historically limited, expensive, and low-bandwidth enough that continuous, high-bandwidth remote access to onboard systems was genuinely impractical, which meant a vessel’s operational technology, however poorly secured in the abstract, was protected in practice by the sheer difficulty of reaching it remotely. Low-earth-orbit connectivity changes that calculus entirely: reliable, high-bandwidth, low-latency connectivity, available continuously, mid-ocean, at a cost that makes it genuinely attractive for crew welfare and operational efficiency alike — and, as a direct consequence, makes a vessel’s onboard systems reachable in a way they simply weren’t before, whether or not anyone updated the vessel’s security posture to reflect that change.
Free · 4 minutes
Do you actually know what you are running — and what it is about to cost you?
Fourteen questions on the systems you depend on, the ones nobody owns, and the support dates that turn a routine upgrade into a forced re-platform. Banded finding on screen, full sheet by email.
Where the gap actually shows up
A vessel’s OT network, historically air-gapped or so poorly connected that a genuine remote attack was impractical regardless of the network’s internal security, now frequently sits one misconfigured bridge away from a continuous, high-bandwidth internet connection installed specifically to improve crew welfare — a genuinely good operational decision, made without the corresponding security review that connectivity of this kind actually requires. The segmentation discipline I’ve written about for OT/IT convergence generally becomes the entire ballgame here: a vessel with genuine, tested segmentation between its connectivity infrastructure and its operational systems retains real protection even with continuous connectivity installed. A vessel without it has quietly traded its old, accidental isolation-based protection for a new, much larger attack surface, with nothing built to replace the protection that was lost.
Why this is an urgent gap, not a theoretical one
The pace of low-earth-orbit connectivity adoption across commercial fleets has outpaced, in a great many cases, the corresponding update to onboard cybersecurity posture — an operational and crew-welfare decision, made for genuinely good reasons, installed by teams focused on connectivity and welfare rather than on the security implications the connectivity introduces. This is precisely the compliance-versus-resilience gap I’ve written about for maritime cyber generally, given new and immediate urgency by a specific, rapidly-adopted technology change that most existing Safety Management Systems were never updated to reflect.
What one fleet audit actually found
A shipping operator installing satellite connectivity across its fleet for crew welfare, over an eighteen-month rollout, ran a genuine security review only after the rollout was substantially complete — later than ideal, but still valuable. The review found that on several vessels, the new connectivity hardware had been installed by a third-party contractor with direct physical access to the same network switch handling bridge navigation systems, with no segmentation between the two ever actually implemented despite the vessel’s own documentation asserting segmented networks. The gap wasn’t malicious or even particularly unusual — it was simply a connectivity project executed by people focused on getting crew online, with nobody in the loop specifically responsible for checking what that connectivity now touched.
Assessing whether a vessel’s onboard segmentation genuinely accounts for newly-installed satellite connectivity, or is quietly relying on an isolation assumption the connectivity has already eliminated, is exactly the kind of gap analysis a technology control assessment is built to run for a maritime operator.
The fix, once found, was straightforward — genuine network segmentation, verified physically, not just documented. Finding the gap eighteen months after installation was the expensive part, not fixing it.
A security review run before or during the rollout, rather than eighteen months after, would have caught the same gap in a single conversation with the installing contractor.
The broader pattern is worth naming plainly: any project whose primary goal is connectivity, comfort, or convenience deserves a security review as a genuine, scheduled step in the project plan, not an afterthought added once someone happens to ask.
A security review run before or during the rollout, rather than eighteen months after, would have caught the same gap in a single conversation with the installing contractor.
The broader pattern is worth naming plainly: any project whose primary goal is connectivity, comfort, or convenience deserves a security review as a genuine, scheduled step in the project plan, not an afterthought added once someone happens to ask.
Newbuild vessels are held to a considerably higher bar on exactly this question — see IACS UR E26/E27.
For the broader context of how Sixteen Pillars works across regulated sectors generally, see Sectors.
Fleet-wide rollouts happening right now, across the industry, on the same timeline pressure this operator faced, are worth checking against exactly this pattern before the gap becomes someone else’s expensive discovery too.
Free interactive tool
Website compliance checklist
What your site has to do, based on what it actually does
Answer as much or as little as you like — the list builds as you go. Nothing is stored against your name and no email is required.
Everything that applies
Ordered by what to do first: legal requirements you can close quickly, then larger pieces of work, then what is expected rather than required. Not exhaustive, and not a legal audit.
Dated PDF, yours to keep or circulate.
Free interactive tool
Interactive deadline calculator
Check which regulations apply to you and when
Regulation across the EU, UK, US and Asia-Pacific has moved considerably in the past eighteen months, and several headline dates have shifted more than once. Twelve questions, about three minutes.
Results are shown on screen — no email required. A dated summary is available to download, and can be sent on if that's more useful. What we do with your answers.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.
Full Governance by Sixteen Pillars
Govern your business. Prove your compliance.
A board assurance cockpit for EU-regulated financial firms — tamper-evident, hash-chained proof of governance across DORA, GDPR, NIS2, ISO 27001, the EU AI Act and MiCA. In development.
See what's coming