Yacht Network Zone Model

This article applies to yachts where the onboard network supports more than basic internet access. That usually means guest Wi-Fi, crew admin, owner office work, AV and control systems, cameras, SatCom management, cloud services, bridge-adjacent data, engineering monitoring, and vendor support all share some part of the same infrastructure.

Applicability depends on vessel size, refit history, class and flag expectations, whether bridge or OT systems are connected, whether personal data is processed, and whether vendors can connect remotely.

A yacht network should not be treated as one big digital room.

It is closer to a vessel with compartments. Guests can use guest areas. Crew have crew areas. Engineers have machinery spaces. Contractors may be allowed into a technical space for a specific job. Nobody would give a guest a key to the engine room because they asked for Wi-Fi.

The network needs the same thinking.

A guest phone, crew laptop, AV processor, CCTV recorder, Starlink terminal, owner workstation, bridge-data gateway, and PMS controller may all use Ethernet or Wi-Fi. That does not mean they deserve the same trust.

The zone model is the written answer to a very practical question:

Who, and what, is allowed to talk to what?

On many yachts the network grows in layers. The builder installs a base system. AV gets added. SatCom gets upgraded. Cameras are expanded. A refit adds new access points. A vendor installs a remote-support tool. Crew add a NAS because file sharing is painful. Everything works well enough, so the design is left alone.

Then something happens.

A guest device behaves strangely. A vendor asks for remote access. The owner wants a dashboard with position, fuel, camera, and AV status. A CCTV recorder needs replacement. The bridge team asks why a dashboard still shows old data. A firewall rule added during refit is still open. Nobody is certain what can reach what.

That uncertainty is the problem the zone model solves.

It does not need to be a beautiful diagram. It needs to be accurate enough that the ETO can troubleshoot, the captain can understand risk, and management can ask the right questions.

Most yachts need a version of these zones.

The guest zone is for guest phones, tablets, laptops, consoles, and visiting devices. It should provide internet access and little else. Guests should not be able to browse printers, media servers, camera systems, crew admin shares, or yacht management interfaces.

The crew welfare zone is for personal crew devices. It is useful, but it is still low-trust. A crew phone should not become a route into management systems, AV control, CCTV, bridge-adjacent data, or engineering systems.

The crew admin and management zone is where work happens: documents, procurement, payroll, PMS access, crew records, management portals, and shared admin tools. This zone carries business and personal data, so it needs stronger identity, MFA, backups, and logging.

The owner office zone needs special care. Owner and family office devices may handle sensitive business, privacy, and financial information. Treat it as a managed office network, not as a nicer guest network.

The AV and control zone supports media servers, touch panels, lighting processors, DSPs, smart TVs, room controllers, and automation gateways. These systems often need discovery and local communication, but they should not automatically see the rest of the yacht.

The security zone covers CCTV, NVRs, access control, intercoms, door controllers, and access logs. It is both security infrastructure and personal-data processing. It should not be casually bridged to guest Wi-Fi or AV tablets.

The SatCom and WAN edge zone is where the yacht meets the outside world. LEO, VSAT, cellular, marina Wi-Fi, SD-WAN routers, provider portals, and firewalls sit here. This is an exposure point, so vendor access and management interfaces need tight control.

The bridge-adjacent data zone is for feeds that originate near navigation or radio systems: AIS, GNSS, NMEA gateways, IEC 61162 data, conning information, and owner dashboards fed by navigation data. Read-only gateways should be the default assumption unless there is a documented operational reason to do more.

The engineering OT zone covers PMS, VMS, alarm monitoring, machinery data, PLCs, HMIs, tank systems, HVAC plant, stabilisers, and automation controllers. This is cyber-physical infrastructure. The design should favour control, recovery, and local fallback over convenience.

The infrastructure management zone is for firewalls, switches, wireless controllers, DNS, DHCP, NTP, monitoring, backups, and admin interfaces. If this zone is compromised or misconfigured, many other zones can fail.

VLANs are useful because they separate traffic inside the switching network. A guest VLAN, crew VLAN, AV VLAN, CCTV VLAN, and OT VLAN are normal building blocks.

But a VLAN by itself is not a complete control.

If firewall rules allow every VLAN to talk to every other VLAN, the yacht has labels rather than boundaries. If every switch port accepts any device, the VLAN plan can be bypassed by plugging into the wrong socket. If management interfaces are reachable from too many places, one weak device can become a wider problem.

Think of VLANs as compartments. ACLs, firewall rules, authentication, monitoring, and training are the doors, locks, logs, and procedures.

The zone model becomes real only when access is enforced. There are several practical methods, and each has a different use.

Firewall rules control traffic between zones. They should be written around purpose, not convenience. For example, an AV controller may need to reach a media server, but not the CCTV recorder or PMS controller. A vendor VPN may need to reach one appliance, not the whole technical network.

Switch ACLs can control traffic closer to the edge. They are useful when certain ports, devices, or subnets need simple restrictions before traffic reaches the firewall. On yachts, they can help protect management interfaces, isolate camera traffic, or stop a support device from reaching unrelated networks.

Port VLAN assignment controls where a wired device lands. A labelled port in the AV rack should not drop a laptop into the same zone as switch management or OT controllers. Rack patching discipline matters because the physical patch lead often decides the digital boundary.

802.1X is stronger because the device or user must authenticate before the network grants access. In a more mature yacht network, 802.1X can place known crew laptops, managed devices, or vendor machines into the right VLAN based on identity or policy. It is more work to design, but it is a better long-term answer than trusting whatever plugs into a port.

MAC address filtering can help with known fixed devices, such as printers, NVRs, AV processors, or monitoring appliances. It is simple and useful as an inventory and housekeeping control. But it is not strong security on its own because MAC addresses can be copied or spoofed. Use it to reduce accidents and keep records clean; do not use it as the only lock on an important zone.

DHCP reservations and IP plans help make devices predictable. They do not secure the network by themselves, but they make faults easier to find and make firewall rules easier to understand.

Wireless SSIDs should map clearly to trust zones. A guest SSID, crew welfare SSID, owner SSID, and technical SSID should not all land in the same place behind the access point.

Network segmentation fails when people do not understand the boundaries.

The ETO may understand the VLANs, but the captain, chief engineer, AV/IT support, purser, and regular vendors need enough training to avoid undoing the design. They do not need a switching course. They need to know the operational rules.

Useful training includes:

• Which Wi-Fi networks are for guests, crew, owner, and technical use.
• Why guest devices must not be added to technical networks.
• Who may approve a firewall rule or vendor access.
• What to record when a vendor asks for remote support.
• Why a spare switch from a locker should not be added casually.
• How to report an unknown device or suspicious network behaviour.

For crew, the practical message is simple: do not move cables, share technical Wi-Fi passwords, plug vendor laptops into random ports, or create workarounds without telling the person responsible for the network.

For management, the message is also simple: if the yacht wants reliable service, it has to support some discipline. Good networks are not built only from hardware. They are built from rules people follow.

Imagine an owner dashboard that shows yacht position, selected cameras, fuel status, and AV status.

Without a zone model, the quickest build is to let the dashboard server talk to everything. It works during the demo. It also creates a path between bridge-adjacent data, CCTV, engineering systems, AV, and owner devices.

With a zone model, the design is different. The dashboard receives read-only data through controlled gateways. The camera system exports selected views rather than exposing the whole NVR. Engineering values are published through a monitored interface rather than direct access to controllers. Firewall rules say exactly what the dashboard can reach. Logs show whether it behaves normally.

The owner sees the same polished dashboard. The yacht keeps its boundaries.

Keep the document practical. It should be something the crew can use during a fault or refit, not a diagram nobody trusts.

At minimum, record:

• Zone name and purpose.
• VLAN and subnet.
• Main devices in the zone.
• Switches, SSIDs, and patch areas involved.
• Firewall or ACL rules between zones.
• Vendor access paths.
• Management interfaces.
• Logging or monitoring source.
• Owner of the zone.
• What happens if the zone fails.

Review it after refit, major vendor work, firewall replacement, SatCom change, AV upgrade, bridge integration, or crew handover.

The first mistake is letting the physical rack decide the trust model. A rack can contain guest, AV, CCTV, infrastructure, and OT traffic. Location is not consequence.

The second mistake is trusting SSID names. A Wi-Fi name tells the user what to click. It does not prove where the traffic goes or what it can reach.

The third mistake is using MAC filtering as if it were proper authentication. It is useful for housekeeping, but it should not be the only barrier protecting important systems.

The fourth mistake is allowing "temporary" vendor access to become permanent. Temporary access needs an end time and a closeout step.

The fifth mistake is treating training as optional. A well-designed network can still be defeated by one shared password, one unapproved patch lead, or one vendor laptop plugged into the wrong place.