Maritime IoT Security: Connected Ship Systems Protection

The Connected Ship: What Maritime IoT Actually Looks Like

Maritime IoT is not a single product. It is the steady accumulation of connected sensing and telemetry that has spread across vessels over the last decade. A vessel built or retrofitted recently typically carries engine condition monitoring sensors (vibration, temperature, pressure, oil quality), fuel consumption and bunker monitoring, hull stress and structural monitoring, ballast and trim sensors, reefer container monitoring for refrigerated cargo, environmental and emissions monitoring for scrubber and exhaust compliance, and a growing volume of crew welfare and connectivity devices.

Each of these sensor families feeds an IoT gateway or data concentrator on board. The gateway aggregates the readings, applies some local processing, and forwards the data over the vessel satcom link to a shore-side platform where the operator, the OEM and sometimes a class society or insurer can view it. That telemetry stream is the backbone of condition-based maintenance, voyage optimisation and remote diagnostics. It is also a continuous, outbound network path from inside the vessel to the public internet.

The security problem is structural. These sensors and gateways were specified by naval architects, engine OEMs and digital-services vendors who were solving an operational problem, not a security one. They were rarely designed with a hostile network in mind, they are rarely patched on a vessel-friendly cadence, and they are rarely inventoried in one coherent place. The result is a large, poorly mapped attack surface that has grown faster than the governance around it.

Where the Maritime IoT Attack Surface Lives

Understanding the attack surface means following the data from sensor to shore and asking what an attacker could do at each hop. The first layer is the sensors and field devices themselves. Many speak unauthenticated industrial protocols (Modbus, CAN-derived buses, proprietary serial) where any device on the same segment can read or inject values. A spoofed temperature or pressure reading can mislead a maintenance decision or mask a developing fault.

The second layer is the IoT gateway or data concentrator. This is the highest-value target on the vessel IoT estate. The gateway often runs embedded Linux, exposes a web or SSH management interface, holds credentials for the shore platform, and bridges the OT-side sensor network to the IT-side satcom network. Compromise the gateway and an attacker can read every reading the vessel reports, alter the data the operator trusts, or pivot toward other vessel networks.

The third layer is the satcom path and the shore platform. The telemetry travels over the same VSAT or L-band link discussed in our companion guide on maritime satellite communication security, and lands in a cloud platform that often serves an entire fleet. A weakness in that platform, broken object-level authorisation between vessels, weak API authentication, exposed admin interfaces, can expose every connected vessel at once, which is a far larger blast radius than any single ship.

• Field sensors: unauthenticated industrial protocols, clear-text telemetry, no integrity checking on readings
• IoT gateways: embedded OS with default credentials, exposed management interfaces, shore-platform credentials stored locally
• Satcom path: outbound telemetry that doubles as an inbound route if the terminal or gateway is compromised
• Shore platform: multi-tenant fleet cloud where one authorisation flaw can expose every connected vessel
• OEM remote access: vendor diagnostic tunnels into the gateway, frequently unmonitored and rarely time-limited

Common Findings in Connected Ship Assessments

Across vessel IoT assessments the findings cluster around a small set of recurring weaknesses. Default and shared credentials are the most common: gateways and sensor controllers retain the documented vendor login long after commissioning, and where credentials were changed they are often shared across an entire fleet so one leak compromises all.

Flat networks are the second recurring theme. The IoT gateway frequently sits on the same network segment as vessel IT, crew welfare, and sometimes the bridge, with no firewall enforcing what may talk to what. SSID separation on the wireless side is often mistaken for network segmentation when it provides none. Unencrypted telemetry is the third: sensor-to-gateway and sometimes gateway-to-shore traffic travels in clear text, allowing both eavesdropping and injection.

Patching is the fourth and hardest. IoT firmware updates depend on the OEM releasing them and a technician applying them at a port visit, so devices accumulate known vulnerabilities over years. Many operators cannot answer the basic question of which firmware version runs on which device, which means they cannot reason about exposure at all. Finally, OEM remote-access tunnels into gateways are frequently always-on, unmonitored, and unlogged, giving a permanent third-party path into the vessel that the operator has little visibility over.

Segmentation and Zones for Vessel IoT

The single highest-ROI control for maritime IoT is network segmentation built on the IEC 62443 zones and conduits model. The principle is to group systems of similar trust and criticality into zones, and to allow traffic between zones only through defined conduits with explicit, monitored rules. Applied to a connected vessel, the IoT estate should sit in its own zone, separated from bridge OT, engine control OT, vessel IT and crew networks.

A pragmatic model places sensor field networks in a low-level acquisition zone, the IoT gateways in a controlled aggregation zone, and the satcom egress in a tightly firewalled conduit that permits only the specific outbound destinations the telemetry needs. Bridge navigation systems and engine control systems remain in their own restrictive zones with no direct path to or from the IoT zone. Where vessel IoT data legitimately needs to reach a shore platform, that path is a single defined conduit, not an open route.

Conduit rules should be allow-listed and logged. The gateway should be permitted to reach only its shore platform endpoints on the required ports, nothing else. Crew and vendor networks should have no path to the IoT or OT zones. Every firewall-permitted connection should be logged for periodic review so that anomalous outbound behaviour, a sign of a compromised gateway, becomes visible rather than invisible.

Protecting Telemetry Integrity and the Shore Platform

Confidentiality matters, but for operational IoT the bigger risk is integrity. Decisions about maintenance, voyage optimisation, emissions reporting and cargo condition are made on the data the sensors report. If an attacker can alter that data, they can cause a wrong decision without ever causing an obvious outage. A spoofed reefer temperature can spoil a container of cargo; a manipulated engine vibration reading can hide a developing bearing failure until it becomes a casualty.

Protecting integrity means authenticating devices so the gateway knows the reading came from the genuine sensor, signing or checksumming telemetry where the equipment supports it, and cross-checking critical readings against independent sources where they exist. It also means treating the shore platform as a first-class part of the security boundary. The platform should enforce strong per-vessel authentication, robust object-level authorisation so one vessel's credentials cannot read or alter another vessel's data, and monitoring for anomalous data patterns that suggest tampering.

Encryption of the telemetry channel protects against eavesdropping and reduces injection opportunities, and should be applied end to end from gateway to platform where the equipment allows. Where legacy sensors cannot be authenticated or encrypted, the compensating control is segmentation plus monitoring: keep them isolated, and watch the gateway and conduit for behaviour that does not match the expected baseline.

Governance: IMO, IEC 62443 and Vendor Assurance

Maritime IoT does not sit outside the cyber regime; it sits squarely inside it. IMO Resolution MSC.428(98) requires cyber risk to be managed within the vessel safety regime, and connected ship systems are part of that risk picture. Class society requirements such as the IACS unified requirements on cyber resilience of ships and onboard systems push secure-by-design expectations onto newbuild and significantly retrofitted equipment, including connected sensors and gateways. IEC 62443 supplies the technical framework for zoning, conduits and security levels that the IoT estate should be designed and assessed against.

Vendor and supply-chain assurance is the part operators most often neglect. The OEMs and digital-service vendors who supply condition monitoring, voyage optimisation and reefer telemetry are deeply embedded in the vessel, often with remote access and shore-platform control. Their security posture is effectively the vessel's security posture for those systems. Cyber clauses in service agreements, evidence of secure development, a defined patch and advisory process, and time-limited monitored remote access should all be in scope.

Bringing it together is a governance loop: maintain the IoT asset inventory, assess it in the vessel cyber risk assessment, design segmentation per IEC 62443, gate and monitor vendor access, and review periodically as new sensors are added. The digital programme and the security programme are not opposites. Done well, security is what lets the connected ship scale safely rather than accumulate silent risk.