Contrarian take: if your OT security assumes stable connectivity and on-site admins, it’s not a security program, it’s a lab demo.

Maritime OT lives in the worst possible assumptions:
– Intermittent satellite links and high latency
– Tiny patch windows tied to port calls and class rules
– Vendors doing remote support through shifting handoffs (ship crew, management company, OEM, integrator)
– Physical exposure: shared spaces, swapped laptops, removable media, and “temporary” networks that become permanent

That combination creates remote-by-default attack paths:
A single weak credential, a poorly controlled remote session, or an untracked engineering workstation can outlive the voyage.

A sea-ready baseline looks different:
1) Design for comms failure: local logging, local detection, and store-and-forward telemetry
2) Treat remote access as a product: per-vendor isolation, just-in-time access, recorded sessions, and strong device identity
3) Patch like aviation: plan by voyage/port cycle, pre-stage updates, verify by checksum, and prove rollback
4) Control the engineering toolchain: signed configs, golden images, USB governance, and offline recovery media
5) Clarify accountability at handoff points: who owns credentials, approvals, and emergency access when the link drops

If you build for the ship, you’ll usually harden every remote industrial site.

What’s the biggest OT security failure mode you’ve seen offshore: connectivity, patching, third-party access, or physical exposure?