A conventional ship's cybersecurity is a systems problem — protect the ECDIS, the OT network, the satellite link. An autonomous ship's is existential: the entire decision chain — sensing, interpretation, manoeuvre — is software, and an attacker who compromises it doesn't just steal data, they steer the ship.
The MASS Code and class rules are converging on cybersecurity as a design requirement for autonomous vessels — not a compliance add-on but the architecture's integrity layer. This article is about what autonomy does to the maritime threat model, and what the requirements are actually asking for.
Key findings
- Autonomy multiplies the attack surface — every sensor, comms link, and model the ship depends on is a point of compromise. Established
- IACS UR E26/E27 (mandatory for ships contracted after 1 July 2024) set the cyber-resilience baseline the MASS context inherits. Established
- The autonomy-specific threats are sensor-level — spoofed GNSS/AIS, adversarial inputs to perception, compromised remote-control links. Established
- The remote-operations link is the highest-consequence channel — compromising it is compromising the ship's command. Established
- Security is architectural, not additive — the safe autonomous ship is designed assuming compromise, not protected as an afterthought. Established
The attack surface autonomy creates
A conventional ship's critical functions — the helm, the engine, the lookout — are human; cyberattack reaches them only indirectly. An autonomous ship's functions are software — and every input it trusts is attackable: the GNSS position it navigates by, the AIS targets it avoids, the camera feed it interprets, the remote link it reports to. Autonomy doesn't just add a digital layer; it replaces the human layer that was the security boundary. Established
The autonomy-specific threats
- <strong>Sensor spoofing.</strong> Falsified GNSS, AIS, or radar returns feeding the autonomy false reality. Established
- <strong>Adversarial perception.</strong> Inputs crafted to fool the vision/detection model — the physical-world adversarial attack. Research demonstration
- <strong>Command-link compromise.</strong> The remote-operations channel as the single point whose compromise takes the ship. Established
- <strong>Supply-chain/model tampering.</strong> The autonomy software itself compromised before deployment. Maritime-GPT analysis
- <strong>Denial-of-service.</strong> Jamming the sensors/links until the autonomy can't function — forcing a fallback the attacker predicts. Established
What the requirements actually ask
The emerging requirement set — IMO's MSC.428(98) cyber-risk framework, IACS UR E26/E27 for newbuilds, and the MASS Code's security expectations — converges on the same architecture: defence-in-depth (segmented networks, authenticated links), sensor cross-validation (don't trust a single input), a degraded-safe mode (the ship's behaviour when its inputs are compromised), and continuous monitoring for the anomalous input. The requirements are architectural — they describe a ship designed to distrust its own sensors, not one protected by a firewall. Established
The fallback is the defence
The most important cyber requirement isn't preventing compromise — it's defining what the ship does when compromise is detected. The degraded-safe mode — come to a safe stop, alert the remote centre, continue on independent sensors — is the design that turns a successful attack into an incident rather than a casualty. An autonomous ship that can't detect its own compromise is a liability; one that can, and has a defined response, is a resilient system. Maritime-GPT analysis
What we know
- Autonomy's attack surface is every trusted input — sensor, link, model.
- IACS UR E26/E27 provide the cyber-resilience baseline for newbuilds.
- The degraded-safe fallback is the core defensive requirement.
What we don't
- Whether current requirements are sufficient for fully-unmanned operations.
- How adversarial-ML threats will be tested under certification.
- The liability allocation for a cyber-caused autonomous casualty.
Being tested
- Sensor-fusion cross-validation against spoofed inputs.
- Degraded-safe-mode certification for autonomous vessels.
- Adversarial-attack red-teaming of maritime perception systems.
Maritime-GPT analysis
Autonomy's cybersecurity isn't a module — it's the design premise. A ship that decides by software must assume its inputs can be lied to, its links jammed, and its models probed — and must have a defined safe behaviour when they are. The regulation's real requirement isn't 'be secure'; it's 'be honest about compromise' — detect it, degrade safely, and let a human know. The autonomous ship's safety case is inseparable from its security case. Maritime-GPT analysis
This is a research feature, not operational guidance. Simulation results are reported as simulation; demonstrations are not deployments; company claims are attributed as such. Verify safety-critical decisions against official nautical publications and flag-state requirements.
Sources & evidence
The IMO cyber-risk framework the MASS context builds on.
The mandatory cyber-resilience baseline for newbuilds.