Maritime Cyber Threat Briefing #6
What if attackers don’t just manipulate what your vessel sees, but begin influencing how it moves?
The previous briefings in this series have documented the pathways through which adversaries reach maritime organizations: SSL-VPN Gateway exploitation targeting shore-based networks, VSAT supply chain compromise disabling vessel communications at fleet scale, AIS manipulation feeding false positions to tracking systems, and electronic warfare degrading navigational trust across entire maritime zones. Each of those attack vectors represents a different entry point into the same destination, the operational systems aboard the vessel itself.
This briefing addresses what happens when the attacker arrives. When the target is no longer data, visibility, or communications but the systems that determine where the vessel goes, how it behaves, and whether the crew can trust what they are seeing on the bridge.
Section 1 – The Bridge as an OT Environment
The modern ship’s bridge is not an IT environment with maritime branding. It is an Operational Technology environment, a network of industrial control systems, sensors, actuators, and supervisory platforms whose outputs have direct physical consequences. When an office network is compromised, the consequence is data loss. When a bridge OT environment is compromised, the consequence can be a vessel that does not go where the crew intends.
The core systems that constitute the bridge OT environment include:
- ECDIS — the Electronic Chart Display and Information System, which has replaced paper charts as the primary navigation platform on most commercial vessels. ECDIS integrates position data from GNSS receivers, depth data from echo sounders, AIS traffic from surrounding vessels, and chart data from electronic navigational chart libraries. AIS acts as a downstream propagation layer for GNSS-derived position data. Critically, on many vessels ECDIS operates in track control mode, directly feeding course commands to the autopilot. A compromised ECDIS is not merely a display problem. It is a steering problem.
- Autopilot and integrated heading control — systems that receive course inputs from ECDIS and execute them through the steering gear. Autopilot systems range from basic models that maintain speed and course to advanced tracking systems capable of following pre-planned routes with speed adjustments, receiving input from ECDIS and integrating data from GPS and other sensors. The connection between ECDIS, autopilot, and steering gear means that manipulation anywhere in this chain can produce course deviations without any direct intervention in steering systems themselves.
- Radar and ARPA — the primary independent source of collision avoidance data. Radar-derived targets feed into the bridge situational awareness picture. Penetration testing has demonstrated that ECDIS and radar can be hacked, with security researchers able to change a vessel’s displayed position, depth information on ECDIS, and meddle with targets on radar placing a ship in jeopardy of grounding.
- Integrated Automation Systems (IAS) — the IAS consolidates sensor input from various ship systems including the power management system and navigation systems into a centralized platform, managing alarm signals and transmitting relevant data to the Voyage Data Recorder. The IAS is the connective tissue of shipboard OT and its central role makes it a high-value target for attackers seeking to suppress alarms, manipulate sensor readings, or disrupt automated responses.
- Engine control, propulsion, and ballast systems — physically separate from the bridge but increasingly networked into the same integrated architecture. Remote diagnostics, predictive maintenance platforms, and OEM vendor access pathways all create connections between engineering OT and the rest of the vessel network.
The air gap theory: the idea that critical shipboard systems were safe because they were not directly connected to the internet, is now a dangerous myth. The convergence of IT and OT has created a vast, porous attack surface. Systems like ECDIS often run on outdated operating systems such as Windows 7 or even Windows XP, that no longer receive security patches.
Section 2 – How Attackers Reach the Bridge
The bridge OT environment does not exist in isolation. It is connected — to the vessel’s satellite communications, to shore-based fleet management platforms, to vendor remote access pathways, and to the crew’s own devices. Each of these connections is a potential entry point.
As documented in Briefing #3, unpatched SSL-VPN Gateways in shore-based networks provide Iranian-linked and other threat actors with authenticated access to corporate environments that frequently include remote access pathways to fleet management systems. Once inside the corporate network, lateral movement toward vessel-connected systems is well within the documented capability of groups such as Lemon Sandstorm.
As documented in Briefing #4, VSAT satellite communications infrastructure represents both an independent attack surface and the primary connectivity pathway between vessel networks and the internet. ECDIS systems are increasingly being connected to vessel networks to facilitate online chart updates, integration with other bridge systems, and remote maintenance. Relevant security flaws that did not matter in the past through lack of connectivity are now becoming critical.
The most direct documented pathway to bridge OT, however, is physical. In December 2025, a RAT [Remote Access Trojan] was discovered on the ferry Fantastic after a crew member, acting on external instructions, inserted a malware-laden USB drive directly into a bridge workstation. By exploiting vulnerabilities including outdated operating systems such as Windows XP and inadequate network segmentation, this type of attack can manipulate ECDIS chart data or remotely take over key engineering systems, resulting in total loss of vessel control.
The Fantastic case highlighted a critical physical-access and insider-risk vector. Two sailors were accused of attempting to deploy trojans or specialized hardware directly onto the ship’s closed-loop navigation systems, in what specialists assessed as physical-access-based cyber-espionage against European maritime assets linked to foreign power interests.
The vendor remote access pathway is equally significant and substantially less discussed. The remote access communications protocols embedded in OT equipment electronics used by OEM troubleshooting teams to remotely diagnose errors and make changes, remain a persistent vulnerability. If a threat actor could leverage these pathways to remotely control engine output or ballasting, the results could be catastrophic.
Section 3 – What Can Be Manipulated: The Technical Reality
This is where the threat moves from abstract to operational. The following represents the documented attack surface of bridge and engineering OT systems. Not theoretical scenarios, but demonstrated capabilities confirmed through penetration testing, incident investigation, and published vulnerability research.
- ECDIS chart data manipulation. Naval Dome security researchers demonstrated live manipulation of ECDIS depth data and position display through malware introduced via an infected electronic navigational chart update. Once inside the ECDIS, the malware manipulated depth data and altered the vessel’s displayed position, creating a direct grounding risk. The attack vector was an infected ENC update file, the routine weekly chart update that every vessel receives.
- Autopilot influence via ECDIS track control. If ECDIS is in track control mode directing the autopilot, an attacker can fool it through GPS data tampering and cause the vessel to change direction. It is also technically possible to insert identical position errors into synthetic radar, removing the crew’s ability to verify position by cross-checking. This allows presenting the bridge team with exactly the same tampered data as the automated systems.
- Engine and propulsion control via serial-to-IP convertor vulnerabilities. Serial-to-IP convertors translate legacy serial OT protocols [used by engine control], steering gear, and ballast pump systems, into network-addressable communications. A compromised serial-to-IP converter can give an attacker the ability to intercept, alter, or inject serial traffic destined for engine control, steering gear, or ballast pump systems. On inadequately segmented vessels, that creates a credible pathway to physical process manipulation. The “CVE-2016-9361” demonstrated that admin credentials could be recovered from these devices even after being changed from default making the vessels running unpatched firmware remain exposed.
- Siemens SIMATIC S7-1200 PLC vulnerabilities. CISA has issued urgent advisories on critical “Siemens SIMATIC S7-1200 PLC” vulnerabilities. Where these controllers are deployed in marine applications [including auxiliary automation], ballast-related processes, or other industrial control functions, exploitable flaws can have direct operational consequences. The vulnerabilities include an unauthenticated remote Denial-of-Service flaw rated “CVSS 8.7” and a Capture-Replay flaw rated “CVSS 8.3” that can remotely force the controller into a STOP state, directly jeopardizing physical vessel operations.
- Emerson ValveLink — ballast and fuel system control. Emerson’s ValveLink software, used for diagnostics and configuration of FIELDVUE-related control environments, has also been the subject of high-severity vulnerability “CVE-2025-52579” disclosures. While not every such flaw directly enables process manipulation, compromises affecting diagnostic and configuration tooling create security exposure around systems tied to ballast, fuel, and other vessel-critical processes.
- Alarm suppression via IAS. The Integrated Automation System manages alarm signals across the vessel. A threat actor with access to the IAS can selectively suppress or delay alarms, creating a window in which degraded system states go undetected and bridge teams receive no indication that something is wrong. This is not a theoretical capability. It is a documented objective of nation-state actors targeting OT environments across critical infrastructure sectors globally, now confirmed in the maritime context.
- Furuno ransomware incident — disruption of support and update pathways. In October 2025, Furuno, a major manufacturer of radar and ECDIS systems, was hit by the Rhysida ransomware group. The attack disrupted internal operations, service, updates, and parts shipments This illustrated how cyber incidents at a manufacturer can affect the support and maintenance ecosystem relied upon by vessels worldwide.
A compromised serial-to-IP converter provides the ability to intercept, modify, or inject serial communications destined for engine control, steering gear, or ballast systems.
It is important to distinguish between theoretical full-system takeover and the more realistic operational scenarios seen in maritime cyber risk: subtle route influence, corrupted chart or sensor data, delayed alarms, degraded support pathways, and control-layer exposure created by insecure connectivity. In practice, these lower-visibility manipulations are often more dangerous than dramatic “all systems down” scenarios because crews may continue operating while trusting compromised interfaces.
Section 4 – Realistic Scenarios: The Subtle Is More Dangerous
- Hollywood-style attacks: sudden loss of all propulsion, total navigation blackout, vessel immediately grounding, are not the most dangerous scenarios. They are immediately detectable and trigger immediate response. The scenarios that should concern operators most are the ones that are subtle, incremental, and designed not to be noticed.
- A two-metre depth offset in ECDIS. The actual seabed is two metres shallower than the chart display shows. In open water, irrelevant. At a port approach in low visibility, potentially catastrophic. The bridge team has no reason to question the displayed depth. The chart looks normal. The route looks clear.
- A slight northward course bias injected via autopilot. One degree of course deviation accumulates to significant positional error over time. In a traffic separation scheme or a narrow channel, one degree can move a vessel from the safe lane into oncoming traffic. The bridge team sees the autopilot holding course as instructed. The heading displayed is the heading commanded. The vessel is not where it appears to be on the chart.
- Delayed engine alarm. A developing fault in the propulsion system generates alerts in the IAS. Those alerts are suppressed for forty minutes. By the time the alarm reaches the bridge, the fault has progressed to the point where emergency response is required rather than routine maintenance intervention. The delay was not accidental.
- False radar target insertion. A vessel that does not exist appears on the ECDIS and radar display on a collision course. The bridge team initiates an avoidance manoeuvre. The avoidance manoeuvre takes the vessel into genuinely hazardous water. The collision was not with the false target. It was with the hazard that the false target drove the vessel toward.
These scenarios share a common characteristic: systems look normal, there are no alarms, and the bridge team is working with trusted interfaces presenting data that has been subtly corrupted upstream.
Section 5 – Why This Is Hard to Detect
The detection challenge for bridge OT compromise is fundamentally different from IT security. In IT environments, anomaly detection looks for unusual network traffic, unexpected process execution, or unauthorised access events. In OT environments, the attacker’s goal is specifically to avoid generating any of these signals.
A manipulated depth reading does not generate unusual network traffic. A suppressed alarm does not generate an unexpected process. A position offset introduced through a trusted chart update file is indistinguishable from a legitimate update. The bridge team is trained to trust the systems they are working with and those systems appear to be functioning normally.
Ethical hackers have shown that shipboard systems often operate with default passwords shared across users, outdated software, and inadequate segmentation. In one documented demonstration, a researcher accessed a vessel’s satellite terminal remotely and reconfigured the ECDIS to subtly shift GPS coordinates. A minor offset in theory but potentially catastrophic in narrow channels or poor visibility.
The absence of independent validation mechanisms, cross-checking ECDIS position against radar-derived bearing and distance, depth against echo sounder directly, course against gyrocompass heading: means that corrupted data can persist undetected for as long as the corruption remains within plausible operational parameters. An attacker who understands the vessel’s operational context can calibrate the manipulation to stay within those parameters.
Section 6 – What Operators Must Change
- Treat bridge OT as a separate security domain. Navigation systems, radar, and autopilot must be on a dedicated, segmented network that does not share a path with crew internet, administrative IT, or VSAT satellite communications traffic. A compromise of the satellite link or a crew member’s device must not be a route to ECDIS. Network architecture reviews must include the bridge OT environment explicitly, not as an afterthought.
- Audit and eliminate vendor remote access pathways. Every OEM that has installed remote diagnostic or maintenance access to bridge or engineering OT systems must be formally assessed. Access credentials must be managed, access must be logged, and standing always-on connectivity must be replaced with session-based access that is explicitly authorised for each maintenance event.
- Establish independent cross-validation as a watch-keeping standard. Bridge teams must be drilled to cross-validate ECDIS position against radar, echo sounder, and visual observation at defined intervals. Not as an exceptional measure, but as a normal watch-keeping discipline. When three independent sources agree, the position is trustworthy. When they diverge, the discrepancy must be investigated before it is normalised.
- Address the firmware and OS legacy problem systematically. ECDIS and radar systems running Windows XP or Windows 7 are running operating systems for which no security patches have been available for years. Compromised [hacked] ECDIS chart systems and remote control of ballast valves are no longer worst-case scenarios. They are documented outcomes from 2025 incidents. A fleet-wide audit of OT operating system versions must produce a time-bound remediation plan that vendors and operators execute together.
- Implement OT-specific monitoring. Standard IT security monitoring tools do not understand OT protocols. Dedicated maritime OT monitoring platforms that baseline normal operational behavior, expected ECDIS position update frequencies, normal autopilot command patterns, routine IAS alarm volumes, can detect deviations from that baseline. In a different integration scenario they would be invisible to generic network monitoring.
- Control the physical attack surface rigorously. USB ports on bridge workstations should be physically blocked except under controlled conditions. Chart updates should transit through isolated, air-gapped scanning workstations before introduction to ECDIS. Technicians and surveyors bringing devices aboard must follow a documented device hygiene procedure before any connection to bridge systems.
Regulatory Context
IACS Unified Requirements E26 and E27 require cyber resilience to be embedded at the design stage for new builds contracted after July 2024, including specific requirements for OT system segmentation and access control. 2026 is the first year those requirements will be tested operationally during classification inspections rather than assessed solely on documentation. Industry reporting has described 2026 as the first year in which IACS UR E26/E27 requirements begin moving from design-stage documentation toward practical verification on vessels entering service under the new regime. The U.S. Coast Guard 2025 rule mandates a designated Cybersecurity Officer with explicit responsibility for OT systems and requires incident reporting for any cyber event affecting vessel operational capability.
For operators of existing tonnage, the International Maritime Organization MSC.428(98) resolution requires cyber risk management to be integrated into Safety Management Systems, which must include the identification of bridge and engineering OT systems as critical assets with associated threat assessments and protective measures.
The evolution of maritime cyber threats has followed a clear and now well-documented trajectory. From corporate IT compromise, through VSAT supply chain attacks, through AIS manipulation and GPS warfare. Each progression has moved the threat closer to the vessel itself. Briefing #6 marks the arrival at that destination.
The attack surface being discussed is not abstract. It is the ECDIS on the bridge of every vessel in the global commercial fleet running an unpatched operating system. It is the serial-to-IP convertor translating commands to the steering gear with no authentication. It is the vendor remote access pathway left open between maintenance visits. It is the IAS that can suppress an alarm and leave the bridge team navigating toward a hazard they do not know exists.
The consequence of getting this wrong is not a data breach. It is not a ransom demand. It is a vessel in the wrong place, in the wrong water, with a bridge team looking at displays that tell them everything is fine.
That is the threat. And it is no longer theoretical.
Maritime Cyber Threat Briefing is an independent series covering cyber threats, vulnerabilities, and risk management across the global maritime industry. It is published by Alexandros Engelen, a Cybersecurity Strategist, specializing in maritime cyber risk.
