Treat remote access as a set of paths, not one feature
A vessel may have a main VPN and still expose several other support paths. AV controllers, CCTV platforms, automation gateways, storage appliances and vendor laptops can each introduce cloud relays, outbound tunnels, forwarded ports or persistent remote-support agents.
The review should begin with the installed state rather than a supplier list. A company may no longer support the vessel while its account or appliance remains active. Another company may have legitimate access through a path that is not represented in the current network diagram.
Build an access register that supports decisions
A useful register explains why the path exists and how it is controlled. It should be possible for the authorised onboard person to decide whether the access is still required without first reverse-engineering the system.
Do not put passwords, recovery codes or private keys in the general register. Record custody and storage location instead, using the vessel’s approved credential process.
- System and service reached
- Connection method and originating party
- Named onboard owner and external owner
- Authentication and approval method
- Operational purpose and expected duration
- Logging or review evidence
- Removal, expiry or emergency-disable action
Verify the path from both ends
Configuration alone does not prove whether a path is usable. Review the relevant gateway, firewall, controller or cloud portal, and compare that state with recent connection records where available. Confirm that the named external party still recognises the account and purpose.
For temporary work, agree who opens the path, when it may be used and who closes it. Named accounts and multi-factor authentication are preferable where the supported platform allows them, but the final control must still match the vessel’s operating process.
Close the job with an explicit final state
Post-work closure should remove temporary accounts, sessions, forwarding rules and support agents that are no longer required. Persistent paths should have a continuing owner and a reason to remain.
The handover should state what was removed, what remains, who approved it and what residual limitations could not be resolved within the scope. This is more useful than a generic statement that remote access is secure.
The objective is not to remove every remote path. It is to ensure that every retained path is intentional, attributable and recoverable by the authorised onboard team.
All field notes