Contrarian take: If your maritime OT strategy starts with patch cadence and endpoint agents, you’re already behind.

Ships, offshore platforms, and port equipment don’t behave like always-on plants.
They run with:
– Long offline windows between port calls and stable links
– Satellite bandwidth constraints and high latency
– Third-party vendor access across multiple owners and charterers
– Safety-critical systems where “just patch it” is not a plan

That combination creates invisible exposure: configuration drift, unverified vendor actions, and monitoring gaps that only surface after the vessel reconnects.

What to design for instead:
1) Disconnected-by-default controls
Local logging, local detection, local time sync, and store-and-forward telemetry
2) Vendor trust boundaries
Brokered access, least privilege by task, session recording, and break-glass workflows
3) Provable state while offline
Baselines, signed change packages, asset identity, and tamper-evident logs
4) Risk-based maintenance windows
Patch only when it’s safe, testable, and operationally feasible; compensate with segmentation and allowlisting

Maritime OT security is less about perfect visibility and more about maintaining safety and assurance when connectivity disappears.

If you’re building a maritime OT program, start with: What must still be true when the vessel is offline?