Vendor Remote Access Minimum Controls

Remote support is normal on modern yachts. The problem is not the engineer in another country helping fix a firewall, SatCom terminal, AV processor, CCTV recorder, PMS server, automation panel or bridge-adjacent gateway. The problem is the remote door that stays open after the job is done.

Every yacht eventually inherits access paths from refits, urgent guest-trip fixes, supplier demos, temporary shipyard networks and "just leave it enabled in case we need it" decisions. Months later, nobody can say which vendor can still connect, what they can reach, or whether the connection is logged.

That is the risk: unmanaged, permanent, shared, invisible access into vessel systems.

The first rule is classification. Access to a guest Wi-Fi controller is not the same as access to a firewall, automation server, PMS controller, CCTV recorder, access-control system or bridge data gateway. The closer the access path is to vessel operation, safety, security, privacy or OT, the tighter the controls should be.

For each vendor, identify the entry point. It may be a VPN account, firewall rule, cloud relay, remote desktop tool, vendor portal, cellular modem, support laptop, shipyard Wi-Fi route, AV cloud controller or temporary admin account.

Do not describe it only as "vendor support." Record the real path:

• Where does the vendor enter?
• What account do they use?
• Which network zone can they reach?
• Which system can they change?
• Who approves the session?
• Who checks the result?

If the yacht cannot answer those questions, it does not yet control the access.

Every vendor remote session should have an approved purpose, approved window and named onboard or management contact. Emergency access can exist, but it still needs a record after the event.

The access register should show vendor name, system, access method, approving person, date and time, reason, account used, change made, and whether backup or rollback was captured before the work.

Approval should be tied to consequence. A cosmetic AV setting change is not the same as a firewall change, automation edit, PMS adjustment, access-control change or bridge-data gateway update. Higher-consequence work should have a named technical supervisor and a closeout test.

Shared vendor accounts are weak evidence and weak security. Each vendor user should have a named account where practical, with MFA enabled for VPN, cloud portal, remote desktop, firewall management and support platforms. If a vendor insists on a shared account, the yacht should record that exception and compensate with session approval, password rotation, monitoring and time limits.

Departing crew, replaced contractors and old shipyard accounts should be removed. A seasonal yacht can accumulate years of access debt if nobody reviews it.

Permanent vendor tunnels should be avoided unless there is a clear operational reason and monitoring in place. A better model is disable-by-default access that is enabled for an approved support window, then closed when work is complete.

For critical systems, the yacht should be able to isolate vendor access quickly. That means someone onboard must know where the VPN, cloud relay, cellular modem, remote desktop agent or firewall rule is controlled.

Disable-by-default should be the normal expectation for AV/IT, CCTV, access control, SatCom management, automation, PMS and bridge-adjacent support unless there is a documented reason for continuous monitoring. Convenience is not a control.

Remote access should land only where it needs to land. A vendor supporting an AV processor should not have broad visibility of crew admin systems, owner office files, CCTV, bridge data or engineering OT. A vendor supporting OT should normally use a controlled jump host or support workstation, not a direct route from the internet into PLC/HMI networks.

Segmentation should be visible in the network diagram. If the diagram cannot show where the vendor enters and what they can reach, the control is not mature.

At minimum, keep VPN logs, firewall logs, cloud admin logs and change notes. For higher consequence systems, consider session recording, command logs, ticket references and before/after configuration snapshots.

Evidence matters after a fault. If an automation issue appears after remote support, the yacht needs to know who connected, when, what changed, and whether the change affected adjacent systems.

For higher-consequence systems, logs should not be held only by the vendor. The yacht, management company or appointed IT provider should retain enough evidence to reconstruct the support session.

Remote support often becomes remote change. Before firmware updates, firewall-rule changes, controller edits, HMI modifications, cloud-controller changes or AV matrix updates, capture a backup or export. For OT, save PLC/HMI project files and confirm rollback options with the vendor.

Backups should not sit only in the vendor's laptop. The yacht or management company should hold a recoverable copy of critical configurations.

Every remote session should end with closeout. What changed? What was tested? Did alarms, network connectivity, backups, dashboards or user access behave as expected? Has remote access been disabled again? Are there follow-up risks?

This is especially important before charters, guest trips and departures from a yard.

• Vendor and named user.
• System supported.
• Access method and entry point.
• Approval person.
• Time opened and closed.
• MFA status.
• Network zone reached.
• Changes made.
• Backup or export captured.
• Test result.
• Follow-up actions.

• Leaving old VPNs active because they are convenient.
• Giving AV or IT vendors access across multiple zones.
• Allowing remote support into OT without onboard supervision.
• Forgetting cloud portals are remote access.
• Not checking access after refit, crew change or supplier change.
• Treating supplier trust as a substitute for evidence.