Secure Yacht Wi-Fi and Guest Device Policy

Guest Wi-Fi is often the busiest network onboard, but it should be the least trusted. It carries guest phones, tablets, laptops, streaming boxes, games consoles, smart watches, personal assistants and sometimes devices the yacht has never seen before.

Those devices may be perfectly normal from a guest-service point of view and completely untrusted from a vessel-infrastructure point of view. They should not provide a path into crew admin, owner office, CCTV, AV control, bridge data, SatCom management or engineering OT.

A secure yacht Wi-Fi policy starts with a simple rule: a device is not trusted because it is physically onboard.

The policy cannot simply say "lock everything down." Guests expect fast internet, streaming, casting, business calls and simple onboarding. The goal is to make that experience work without turning the yacht into one flat network.

That means designing guest services intentionally. If guests need to cast to a screen, print a document or join a video call, build those use cases through controlled routes. Do not solve them by giving the guest the internal SSID.

Most yachts need more than one wireless network. A practical model might include:

• Guest internet.
• Crew welfare internet.
• Owner office or family devices.
• Yacht admin devices.
• AV/control devices.
• IoT or smart devices.
• Temporary contractor access.

Each network should have a purpose, owner and allowed destination list. Guest devices should normally reach the internet only. Crew welfare devices should not reach management systems. Contractor devices should receive temporary, limited access. AV and IoT devices should not casually bridge into owner, crew or OT networks.

The useful test is simple: if a guest device is infected, curious or misconfigured, what can it see? The answer should be "internet access and approved guest services," not the yacht's working infrastructure.

Where supported, use current Wi-Fi security modes such as WPA3. WPA3 is not a complete security architecture by itself, but it improves wireless protection compared with older approaches. Some environments still need WPA2/WPA3 transition modes for compatibility, so the yacht should document where legacy support is allowed and why.

For owner office or management networks, consider enterprise authentication or certificate-based onboarding where practical. Shared Wi-Fi passwords become hard to control on yachts with rotating crew and frequent guests.

For guest networks, manage the lifecycle of credentials. A password used across seasons, charters and refits is no longer a meaningful control.

Guest isolation should prevent guest devices from discovering or talking to each other unless there is a clear reason. This reduces casual scanning, file-sharing exposure and infected-device spread.

Also isolate guest networks from:

• Crew admin.
• Owner office.
• NAS and servers.
• CCTV and access control.
• AV processors and control panels.
• SatCom management interfaces.
• Bridge-adjacent systems.
• Engineering and OT networks.

The firewall should enforce this. VLAN names alone do not prove isolation.

Ask for a firewall rule review, not just a list of SSIDs. The question is what traffic is allowed between networks, who approved it, and whether it is still needed.

Smart TVs and streaming boxes are often treated as harmless because they are entertainment devices. They may still store accounts, connect to cloud services, advertise services on the network and receive updates from vendors. Place them in an AV or media zone, not the core network.

If guests cast to TVs, design that service intentionally. Do not open broad network paths just so one device can find another.

This is especially important where AV, lighting, blinds or cabin controls share infrastructure. Convenience features should not create routes into owner, security, bridge-adjacent or engineering systems.

The purser, captain or AV/IT contact should have a simple procedure:

• Provide the correct SSID.
• Avoid sharing internal passwords by message threads where possible.
• Give guests only the network intended for them.
• Remove charter-specific credentials after the trip.
• Do not connect unknown guest devices to crew or owner networks.
• Escalate requests for printers, file shares, casting or business support.

For high-profile guests, privacy and device confidentiality may matter as much as bandwidth.

The procedure should also say who handles exceptions. If a guest needs business-device support, the purser should not have to guess whether to ask the ETO, AV/IT officer, captain or management company.

Contractors should not use guest Wi-Fi when they need technical access, and they should not use unrestricted internal Wi-Fi. Create a temporary contractor network with limited routes, time limits and logging. Remove access after the job.

During refit, this becomes especially important because many devices and laptops appear onboard quickly.

Contractor access should be treated like a temporary pass: specific purpose, specific route, known expiry and removal at closeout.

• Guest Wi-Fi is internet-only by default.
• Crew welfare is separate from yacht admin.
• Owner office is separate from guest and crew welfare.
• AV/media devices are contained in their own zone.
• Contractor access is temporary and approved.
• No guest or personal device connects to OT, bridge or security networks.
• WPA3 or strongest supported security mode is preferred.
• Shared passwords are rotated after charters, crew changes or exposure.
• Unknown devices are reviewed.
• Wi-Fi configuration is backed up.

• Running one flat yacht Wi-Fi network.
• Giving guests the crew or owner SSID for convenience.
• Letting smart TVs sit on the same network as servers.
• Assuming VLANs are enough without firewall policy.
• Keeping the same guest password across seasons.
• Forgetting contractor devices after refit.