Autonomous Ship Cybersecurity: Unmanned Vessel Protection

What Changes When You Take the Crew Off the Bridge

Maritime Autonomous Surface Ships (MASS) are usually described by the IMO's four degrees of autonomy, ranging from a conventional vessel with some automated decision support (Degree 1), through a remotely controlled vessel with crew aboard (Degree 2) and a remotely controlled vessel with no crew aboard (Degree 3), to a fully autonomous vessel that makes its own decisions (Degree 4). The cyber threat model intensifies sharply at Degree 3 and above, because the human who could detect and contain a problem on a conventional bridge is no longer on board.

On a conventional vessel, a cyber incident on ECDIS or the autopilot is serious but survivable: the master reverts to paper charts and hand steering, the chief engineer watch-keeps the plant manually. On an unmanned MASS vessel, those manual fallbacks do not exist on board. Containment and recovery depend entirely on a remote operator who may be thousands of nautical miles away, reachable only through a satellite link that the incident may itself have degraded.

This single fact reframes everything. For an autonomous vessel, availability and integrity of the control path are safety-critical in a way they never were when a human stood watch. The cyber programme has to assume that the most dangerous failure is not data theft but loss of trustworthy control.

Securing the Onboard Autonomy and OT Stack

The onboard side of a MASS vessel is a dense operational technology (OT) environment. It includes the autonomy controller that fuses sensor data and issues steering and propulsion commands, the perception sensors (GNSS, radar, lidar, optical and infrared cameras, AIS), the conventional bridge OT it supersedes or supervises (ECDIS data, autopilot actuators), engine and machinery automation, and the communications equipment that links all of it to shore.

Segmentation is the foundational control, applied through the IEC 62443 zones-and-conduits model. The autonomy controller and the safety-critical actuators (steering, propulsion) belong in the most restrictive zone. Perception sensors feed into that zone through tightly defined conduits with integrity checking. Communications equipment sits in its own zone so that a compromised satcom terminal cannot reach straight into the control plane. Any maintenance or diagnostic access is gated through hardened, logged, time-bound paths rather than always-on vendor connections.

Beyond segmentation, the onboard stack needs secure boot and signed firmware so that the autonomy software cannot be silently replaced; hardened, supported operating systems with a defined patch and exception process; least-privilege accounts and no shared credentials; and comprehensive logging that survives a loss-of-link so that a post-incident investigation is possible even if the vessel was out of contact when the event occurred. IACS Unified Requirements E26 (cyber resilience of ships) and E27 (cyber resilience of onboard systems and equipment) drive many of these controls into newbuild design from delivery.

The Ship-to-Shore Data Link: The Critical Dependency

For a remotely controlled or supervised autonomous vessel, the data link between ship and the Remote Operations Centre is the single most critical dependency in the entire system. It carries control commands outbound, sensor and status telemetry inbound, and the video and situational data the remote operator relies on. Its failure modes map directly onto safety scenarios: high latency degrades the operator's ability to react, intermittent loss of signal creates blind windows, and a compromised link could allow command injection or telemetry falsification.

Resilience starts with diversity. A serious MASS design does not depend on a single VSAT path. It combines geostationary and low-earth-orbit satellite services, adds cellular (4G/5G) coverage in coastal waters, and defines deterministic behaviour for loss-of-link: the vessel must have a safe, pre-agreed fallback (hold station, reduce speed, proceed on last validated plan, or stop) that it executes autonomously when the operator goes dark. That fallback logic is itself safety-critical software and a high-value target.

Security of the link rests on strong mutual authentication between vessel and ROC, end-to-end encryption of the command and telemetry channels, message integrity and anti-replay protection so that a captured command cannot be re-injected, and monitoring that detects anomalies in command timing, source or content. The principle is that the vessel should accept control input only from a cryptographically verified ROC, and the ROC should trust telemetry only when its integrity is verified, never on the basis of the link being open.

The Remote Operations Centre as a Single Point of Failure

On an unmanned vessel, the Remote Operations Centre (ROC) concentrates risk that was previously distributed across many independent bridges. A single ROC may supervise a fleet of vessels. Compromise of that centre, its operator workstations, its networks or its credentials is therefore a fleet-level event, not a single-vessel event. The ROC deserves the security rigour of a critical national infrastructure control room, not that of a back office.

ROC controls follow enterprise and OT best practice combined: strict network segmentation between the operator control plane and corporate IT, multi-factor authentication and role-based access for operators, privileged-access management for any administrative function, hardened operator workstations that cannot browse the open internet or run arbitrary software, continuous monitoring with a SOC tuned to maritime control traffic, and physical security controlling who can enter the operating floor.

Human factors matter as much as technical controls. Remote operators must be trained to recognise the signature of a cyber incident as distinct from a mechanical or environmental problem, because the on-screen symptoms can look similar. Procedures must define when an operator escalates, how supervision transfers between operators or sites, and what the chain of authority is for taking a vessel to its safe fallback. A resilient design also avoids a single ROC being an absolute single point of failure, providing for supervised handover to an alternate site.

Sensor and Perception Spoofing: An Autonomy-Specific Risk

Autonomous navigation depends on sensors, and sensors can be deceived. On a crewed vessel, a spoofed GNSS position or a false AIS target is filtered through human judgement: the officer of the watch notices that the chart and the window disagree. On an autonomous vessel, the machine acts on the sensor picture directly, so a successful spoof can translate straight into a wrong manoeuvre.

The relevant attacks are familiar individually but more dangerous in combination. GNSS spoofing can feed the autonomy controller a false position. AIS spoofing can inject phantom or misrepresented vessels into the collision-avoidance logic. Radar can be jammed or presented with false returns. Optical and lidar perception can be degraded or, in research settings, fooled with crafted patterns. An attacker who can make several sensors agree on a false reality is the worst case, because cross-checking depends on sensor disagreement to detect the lie.

Defences are about diversity, plausibility and authentication. Use multiple independent sensing modalities so that compromising one does not compromise the picture, and run plausibility checks that reject sensor inputs that contradict physics or the other sensors. Prefer authenticated position sources (multi-constellation GNSS with anti-spoofing, authenticated signals such as Galileo OS-NMA, inertial reference for short-term continuity). Build the autonomy stack so that low-confidence or contradictory perception triggers a conservative fallback rather than a confident wrong action.

• GNSS spoofing: false position fed straight into autonomous navigation, countered by multi-constellation, authenticated and inertial sources
• AIS spoofing: phantom targets injected into collision-avoidance logic, countered by radar correlation and plausibility checks
• Radar jamming or false returns: degraded or deceptive picture, countered by sensor diversity
• Optical and lidar deception: degraded perception, countered by cross-modality agreement and conservative fallback on low confidence

Regulation, Class and Programme Governance

The regulatory frame for MASS is still maturing. The IMO has been developing a goal-based MASS Code, expected to move from a non-mandatory to a mandatory instrument over the coming years, and existing instruments (SOLAS, COLREGs, STCW, the ISM Code) are being assessed for how they apply when there is no master on board. Cyber risk management under IMO Resolution MSC.428(98) and the MSC-FAL.1/Circ.3 guidance applies to autonomous operations just as it does to conventional ones, with the difference that the safety stakes of cyber failure are higher.

Classification societies are ahead of the regulator in practice. The IACS Unified Requirements E26 and E27, applicable to newbuild and significantly retrofitted vessels, push secure-by-design controls (segmentation, secure update, equipment-level security) into exactly the systems autonomous vessels depend on. Several class societies also publish their own autonomous and remote-control notations with cyber requirements attached.

For an owner or technology developer building toward autonomy, the practical governance message is to treat cyber as a safety case input from the start of design, not a bolt-on before trials. The autonomy stack, the data link and the ROC should each carry a documented threat model, a set of controls traceable to IEC 62443 and the IACS requirements, and an independent assessment before the vessel carries real risk. Codesecure supports MASS developers and operators with exactly this work: threat modelling, OT and ROC penetration testing, data-link hardening review and IMO-aligned cyber risk documentation.