Last fall, a captain on a 60-meter charter yacht in the Western Mediterranean called me because his entertainment system was behaving strangely. Channels were switching on their own. The onboard media server was sending traffic to an IP address in Eastern Europe that nobody on the crew recognized. When I walked through the network topology with the vessel's IT contractor, the answer was straightforward and familiar: the guest Wi-Fi, the crew network, the entertainment system, and the navigation ECDIS all sat on the same flat Layer 2 network. One VLAN. No segmentation. A compromised guest device had reached the media server, and from there, it could reach everything else on the vessel.
This is not an unusual network architecture for a superyacht. It is, in my experience, the most common one. And it is exactly the architecture that zero trust was designed to replace.
The Flat Network Problem
Most vessel networks were built by marine electronics integrators, not cybersecurity architects. The design priority was connectivity, not containment. Make the ECDIS talk to the chart plotter. Let the VSAT terminal serve internet to both crew and guests. Wire the entertainment system into the same switch that carries navigation data. It worked, in the sense that everything connected. But it created an architecture where any device on any port can, in principle, reach any other device on the vessel network.
Pen Test Partners demonstrated this problem in their maritime OT research. They found that Ethernet and serial networks on vessels are frequently bridged at multiple points, including GPS receivers, satcom terminals, ECDIS displays, and serial-to-IP converters. An attacker who gains access to any one of those bridge points can reach engine controls, navigation systems, and communication equipment. The three CVEs disclosed in the NAVTOR NavBox last year, which I analyzed in detail, illustrate this perfectly: authentication-free API endpoints on a device designed to bridge shore-side services and onboard navigation, sitting on a network with no segmentation between zones.
The assumption that physical access to the vessel was the security boundary was reasonable in 2010. It is not reasonable when the same network carries guest smartphones, crew personal devices, IoT sensors, and always-on satellite uplinks.
What Zero Trust Actually Requires
NIST Special Publication 800-207, published in August 2020, defines zero trust architecture through seven tenets. The core principle is straightforward: no device, user, or network segment is trusted by default, regardless of its physical location. Every access request is authenticated, authorized, and continuously validated.
Three of those tenets matter most on a vessel.
All communication is secured regardless of network location. Being on the vessel's physical network does not imply trust. A crew device connected to the crew switch gets the same scrutiny as a shore-side vendor connecting over the satellite link. Network location is not a credential.
Access to resources is granted on a per-session basis with least privilege. The chief engineer's tablet can reach the engine monitoring dashboard. It cannot reach the guest booking system, the owner's personal network, or the AI compute stack. Access is scoped to what the user needs for their current role, and it expires when the session ends.
The enterprise monitors and measures the integrity and security posture of all assets. Every device on the network is continuously assessed. A crewmember's phone that has not been patched in six months gets quarantined or placed in a restricted VLAN until it is brought into compliance.
These principles are not exotic. They are the same principles that drove enterprise network architecture away from castle-and-moat designs over the past decade. What is different on a vessel is the enforcement environment: no full-time IT staff, rotating crew, vendor technicians coming aboard at every port, and connectivity that drops to zero when the satellite link goes down.
Eight Zones on a Modern Superyacht
A zero-trust vessel network starts with a zone map. Every system on the vessel belongs to exactly one security zone, and traffic between zones is denied by default. Based on the deployments I have worked on and the guidance from IACS Unified Requirement E26, here is the zone model I recommend:
-
Navigation and bridge OT. ECDIS, GPS/GNSS receivers, radar, AIS, autopilot, GMDSS. This zone accepts no inbound connections from any other zone. Outbound data flows (position reports, AIS broadcasts) go through a strictly filtered firewall rule.
-
Engine room and machinery OT. Propulsion controls, power management, ballast, HVAC, generators. Same principle: no inbound connections from IT zones. Monitoring data can flow out through a read-only interface. Control commands originate only from authenticated bridge consoles within this zone.
-
Crew network. Operational IT, vessel management systems, crew communications. Crew devices authenticate via 802.1X and receive VLAN assignment based on role.
-
Guest and owner Wi-Fi. Isolated internet access for guests. This zone has no path to any other zone. It reaches the internet through the satellite uplink and nothing else.
-
Entertainment and AV. Audio-visual systems, smart cabin controls, lighting automation. Separated from guest Wi-Fi because these systems often run embedded operating systems that cannot be patched on the same cadence as consumer devices.
-
CCTV and physical security. Surveillance cameras, access control systems. Isolated to prevent an attacker from disabling monitoring as part of a broader compromise.
-
AI compute stack. The on-vessel GPU cluster, inference serving layer, embedding models, and any agentic workflows. This zone communicates with the vessel management system through a controlled API gateway with request validation. It never touches the guest network. As I covered in my CMMC compliance analysis, the AI stack processes data that may include guest PII, crew records, and operational telemetry. Treating it as an extension of the crew network is a compliance failure waiting to happen.
-
Satellite communications (WAN gateway). The VSAT terminal, Starlink, or LEO constellation uplink. This is the boundary between the vessel and the outside world. All outbound traffic from every zone transits through a next-generation firewall at this boundary. Inbound connections are blocked by default.
IACS UR E26 requires that wireless devices reside in dedicated security zones and that only explicitly allowed traffic may cross zone boundaries. The architecture above satisfies that requirement and goes further by isolating the AI compute stack, which carries the same data-sensitivity characteristics as any system processing personal or operational information.
Deny All, Allow by Exception
NIST SP 800-171 Rev 3 control 03.13.06 specifies a "deny all, allow by exception" traffic policy at system boundaries and identified internal enforcement points. On a vessel, this translates to firewall rules between every pair of zones that start from a position of blocking everything and add specific, documented exceptions.
In practice, the allow list for a well-designed vessel network is short. The guest Wi-Fi zone talks to the satellite WAN gateway and nothing else. The crew zone can reach the vessel management system API and the internet (through the WAN gateway) but not the OT zones. The AI compute zone can pull data from the vessel management system and push inference results back, but it cannot initiate connections to the crew zone, the guest zone, or directly to the internet.
The ransomware trend targeting engine rooms and ballast systems follows exactly this lateral movement pattern: IT breach to OT compromise, through flat network segments that should never have been connected. A deny-all architecture between zones eliminates that traversal path entirely.
The exceptions are documented, versioned, and reviewed. When a vendor comes aboard to service the entertainment system, they get a temporary credential that places their device in the entertainment zone. When the work is done, the credential expires. If the vendor needs to reach a shore-side diagnostic server, that connection is explicitly allowed for the duration of the maintenance window and then revoked. This is what NIST 800-171 Rev 3 control 03.01.03 (Information Flow Enforcement) looks like in practice: approved authorizations for controlling the flow of information within the system and between connected systems, enforced at boundary protection devices using rule sets.
Identity Over Location: 802.1X on a Vessel
The traditional approach to network access on a vessel is port-based: plug into a switch port in the crew mess and you are on the crew network. Plug into a port in the engine room and you are on the OT network. This is location-based trust, and it is exactly what zero trust eliminates.
IEEE 802.1X with RADIUS authentication replaces location with identity. Every device that connects to the vessel network, wired or wireless, must authenticate before it receives any network access. The RADIUS server assigns the device to a VLAN based on the authenticated identity: a crewmember's managed laptop goes to the crew VLAN, a guest's phone goes to the guest VLAN, an unrecognized device goes to a quarantine VLAN with no access to anything except a captive portal.
The practical benefit on a vessel with rotating crew is significant. When a new crewmember joins, their credentials are provisioned and they automatically land on the correct network segment regardless of which physical port or access point they use. When they depart, their credentials are revoked and any device they leave behind is automatically quarantined. No manual VLAN reconfiguration. No port-level access control lists that nobody updates.
The centralized authentication logs also give you something that port-based access never will: a complete record of which device connected to which network segment, when, and with whose credentials. When an incident occurs (and eventually one will), that log is the difference between a forensic investigation that takes hours and one that takes weeks.
Where Sovereign AI Changes the Calculus
Every zone model I have described assumes one thing: the systems running in each zone are physically present on the vessel. That is the sovereignty argument that James has made repeatedly on this site, and from a security architect's perspective, it is the only architecture that allows a zero-trust design to function when the satellite link drops.
A cloud-dependent AI system breaks the zone model in two ways. First, it requires a persistent outbound connection from the vessel to a cloud endpoint, which means the WAN gateway firewall must maintain an always-open rule for that traffic. That rule is an attack surface. As I wrote in my analysis of the LiteLLM vulnerability, a compromised cloud gateway hands an attacker every API key the proxy stores. Second, a cloud system processes vessel data (guest preferences, crew records, operational telemetry) outside the hull, which means your data sovereignty controls end at the satellite uplink.
A sovereign AI stack, running locally on the vessel within its own dedicated security zone, keeps data processing inside the hull and inside your zero-trust perimeter. When the link goes down, the AI keeps working. When the link is up, the AI compute zone syncs on a schedule through authenticated, time-bounded connections. No persistent tunnels. No always-open firewall rules. The zone architecture holds.
This is not just a resilience argument. It is a compliance argument. NIST 800-171 control 03.13.01 (Boundary Protection) requires monitoring and control of communications at external boundaries. If your AI workload runs in the cloud, the external boundary is the API endpoint of a provider whose security posture you do not control. If it runs on the vessel, the external boundary is your WAN gateway firewall, and you control every rule on it.
The Regulatory Clock Is Running
The regulatory environment is converging on mandatory network segmentation for vessels. The USCG's final maritime cybersecurity rule, effective July 16, 2025, explicitly requires owners and operators to segment IT and OT networks and log connections between them. The rule's preamble describes network segmentation as "a logical starting point because it underpins nearly every other requirement in the regulation." Full compliance plans are due by July 2027.
IACS Unified Requirements E26 and E27 became mandatory for newbuilds contracted after July 1, 2024. E26 defines ship-level security zones and requires that only explicitly allowed traffic traverse zone boundaries. E27 mandates 30 core security capabilities for all computer-based onboard systems. DNV's Cyber Secure class notation, aligned with these requirements, is now mandatory for all newbuilds in DNV class.
BIMCO published version 5 of its "Guidelines on Cyber Security Onboard Ships" in November 2024, emphasizing regularly updated risk assessments and network architecture reviews. The IMO issued MSC-FAL.1/Circ.3 Rev.3 in April 2025, its latest update to the guidelines on maritime cyber risk management.
For existing vessels, none of these mandates require a zero-trust architecture by name. But read the actual requirements: network segmentation, deny-by-default traffic policies, identity-based access control, continuous monitoring, and documented zone boundaries. That is zero trust. The label does not matter. The architecture does.
The NotPetya attack on Maersk in 2017 cost between $250 million and $300 million and required rebuilding 45,000 PCs, 4,000 servers, and 2,500 applications in ten days. Maritime cyber incidents rose 103% in 2025. Building a zero-trust architecture now, before a surveyor flags it or an incident exposes its absence, is the least expensive option available.
If your vessel network was not designed with security zones, identity-based access, or deny-by-default traffic policies, that is a solvable problem. Talk to us. We design vessel network architectures that hold up under audit, under attack, and when the link drops.