Zero Trust Maritime Network Security: Why Ships Need It
Most shipboard networks were designed around a single assumption: there's one connection to the outside world — the satellite link — so putting a firewall at that one point and trusting everything behind it is good enough. That assumption made a certain kind of sense when the satellite link itself was slow, expensive, and intermittent enough to act as a natural brake on how much could go wrong through it. It stops making sense once that link is an always-on broadband connection and the ship's operational systems are tethered to the same network as crew Wi-Fi and the corporate office. A zero trust maritime network starts from a different premise: no device or system is trusted just because it's already inside the perimeter, satellite link included.
What zero trust actually means (it isn't a product you buy)
NIST's formal definition, published in Special Publication 800-207, describes zero trust as a set of principles that move cybersecurity away from static, network-based perimeters and toward individual users, devices, and resources. Under this model, there is no implicit trust granted to an asset or account simply because of its physical or network location — every request for access is authenticated and authorized as its own event, not inherited from "being on the right side of the firewall" (source: NIST SP 800-207). That's a direct rejection of the castle-and-moat model most shipboard networks were actually built on: one gate at the edge, broad trust for everything already inside.
Why the maritime perimeter model is already broken
The U.S. Coast Guard's Cyber Command made this concrete in its 2024 Cyber Trends and Insights in the Marine Environment report, noting that vessels and facilities increasingly rely on networked systems and satellite communications, and that operational technology is often tethered directly to the company's enterprise network — with network segmentation audits among its core recommendations (source: USCG Cyber Command, 2024 CTIME report). A separate maritime cyber threat-intelligence vendor's 2026 report counted 828 maritime cyber incidents in 2025, up 103 percent from 408 the year before, and specifically pointed to the integration of satellite communications with onboard operational technology as having significantly widened the industry's attack surface — including the satellite link itself becoming a single point of failure that can affect multiple vessels through one piece of compromised management software (source: CYTUR 2026 maritime cyber threat report, as reported by Cyprus Mail). We touched on the broader zero-day exposure this creates in an earlier post, Understanding Zero-Day Security in Networks; a zero trust maritime network is the architectural response to that exposure, not a separate topic.
The regulatory push: IMO, the ISM Code, and class societies catching up
Maritime regulation has been moving in this direction, even without naming zero trust specifically. Under IMO Resolution MSC.428(98), shipping companies have been required to address cyber risk within their Safety Management Systems since the first annual verification of their Document of Compliance after 1 January 2021 — treating cyber risk the same way the ISM Code already treats any other risk to the ship, crew, or environment (source: Norwegian Maritime Authority summary of the ISM Code amendment). Classification societies have followed with harder technical requirements: IACS Unified Requirements E26 and E27, covering cyber resilience of onboard systems and the hardening expected from equipment suppliers, become mandatory for ships contracted for construction from January 2024 onward (source: summary of IACS UR E26/E27). None of this legislates zero trust by name, but a flat network where a single compromised terminal can reach navigation, propulsion, and crew systems alike is an increasingly difficult position to defend under any of these frameworks.
Why OT and IT keep ending up on the same network in the first place
This convergence usually isn't a mistake made all at once — it accumulates. A ballast water management system gets a remote-diagnostics feed so the manufacturer can troubleshoot it from shore, and the easiest way to wire that in is onto the same switch already carrying crew internet traffic. An engine room sensor package gets added for predictive maintenance and lands on whatever network segment happened to have a free port nearby. Crew entertainment systems and the ship's ECDIS or voyage data recorder end up a few hops apart on paper, but with no firewall rule actually separating them in practice. None of these decisions look reckless in isolation; they're each a reasonable shortcut made by whoever installed that one system, with no one responsible for looking at the cumulative picture across every vendor that has ever touched the network.
What a zero trust shipboard network actually looks like
This doesn't require ripping out existing infrastructure. In the engagements we run, it comes down to a small number of concrete architectural decisions:
- Segment OT from IT as an enforced boundary, not a VLAN label: navigation, propulsion, and ballast systems sit on a segment that crew Wi-Fi, the PMS, and entertainment systems cannot reach by default, with explicit, logged exceptions rather than a broad allow rule.
- Authenticate every session to operational systems individually: access from the bridge, from a shoreside engineer, or from a vendor's remote support tool is authenticated and authorized per session, not implicitly trusted because it originated inside the ship's network.
- Treat the satellite terminal as untrusted infrastructure, not a boundary: a compromised VSAT or Starlink terminal should have no default path to anything beyond the network segment it serves, the same way a compromised office laptop shouldn't have a default path to a factory floor.
- Log and monitor cross-segment access attempts: the difference between a contained incident and a fleet-wide one is usually whether anyone can see lateral movement happening, not whether the first compromise was preventable.
Why this matters more at sea than on land
A land-based network can call in a specialist the same afternoon something looks wrong. A ship days from the nearest port with a satellite link that costs real money per gigabyte cannot. We covered the broader list of ways maritime networks differ from their land-based counterparts in Maritime Networking Isn't Land Networking on Water; zero trust segmentation matters more at sea specifically because the usual fallback — a quick remote fix or an on-site visit — isn't available on the same timeline. Maersk's 2017 NotPetya incident is the clearest large-scale illustration of what a flat internal network costs once something gets a foothold: the malware didn't need to touch a single ship's navigation system to cost the company an estimated $200-300 million, because it spread through internal systems that trusted each other by default once inside the perimeter (source: Maersk's own Q2 2017 disclosure, as reported by Computer Weekly).
"A zero trust maritime network doesn't assume the satellite link is a trustworthy boundary. It assumes nothing is, and verifies everything, every time."
Fleets that get this right treat the satellite uplink, the crew network, and every operational system on board as separate trust zones from the start, not as one network with a single gate. Our maritime network solutions team designs this kind of segmentation into both new-build specifications and retrofits on existing vessels, and our network infrastructure services cover the broader assessment and implementation work behind it.
If your fleet's network still relies on a single firewall at the satellite gateway to protect everything behind it, contact our team — the assessment that finds out how exposed that design actually is takes less time than most operators expect.