A cyber incident can delay a ship even when there is no visible damage. Owners should judge resilience by the ability to maintain safe control and to provide the evidence needed to resume operations.
The US Coast Guard and FBI had boarded two tankers in August after indications of network compromise. The agencies reported no current operational disruption, danger to crews or environmental impact, and the investigations should not be read as proof of a particular attack method or physical consequence. The episode nonetheless raises a question every shipowner should be able to answer.
Consider a ship approaching port when propulsion control becomes unreliable or cargo tank pressure readings cannot be trusted. Can the master continue the approach? Can the terminal begin discharge? Even without visible damage, uncertainty about essential functions may be enough to suspend operations.
Shipowners should therefore judge cyber resilience by whether a vessel can maintain safe control and demonstrate that it is ready to resume operations after an incident. That ties cybersecurity directly to marine safety and the commercial cost of interrupted voyages.
Identifying the cause is only part of the operational challenge. While investigators establish what happened, the master must know which functions remain dependable and what restrictions are needed. A technical response has to supply the evidence for those decisions.
The stakes are physical. Losing propulsion or steering in a confined channel leaves little time to avoid a collision or grounding. Misleading readings can be just as dangerous. Machinery may still run while the crew lacks reliable information to manage it safely. Cyber risk assessment must therefore examine the physical process, its protective functions and the means of control available.
The International Association of Classification Societies (IACS) reflects this in its Unified Requirement E26, whose scope covers systems supporting propulsion, steering, electrical power, fire protection and watertight integrity. It offers a useful way to organise an assessment around the consequences of losing a ship’s functions.
Uncertainty carries its own cost. A ship may reach its destination yet be unable to show that cargo operations are safe. Additional checks can mean waiting, rebooking pilots and tugs, or losing a berth. Specialist attendance and replacement equipment may also be needed. A prolonged interruption can then ripple into later voyages and cargo delivery commitments.
Replacing damaged computers captures only part of that exposure. Owners should ask how long essential functions may be unavailable and how long it would take to establish that the vessel can safely return to service.
The significance of an assessment lies in what its findings mean for the vessel’s operations. In CYTUR’s September 2026 Threat Brief, 94% of assessed systems fell within the Appropriate or Required risk treatment categories under IACS Recommendation 171, meaning that additional mitigation should be considered or is required. The figure describes the assessed sample and cannot be extrapolated to the world fleet.
The broader lesson is that counting known software vulnerabilities does not provide enough information on its own. Network connections, exposed services and the operational role of equipment shape the consequences of a weakness. Owners need to know which findings could affect safe control and which practical measures should come first.
For ships already trading, large equipment replacements or network changes are difficult to make between port calls. A practical starting point is threat modelling: tracing plausible routes of intrusion and their consequences using network drawings, equipment inventories and available configuration records. It can reveal connections between business computers, remote support arrangements and critical control systems, helping target later onboard checks.
Its limits matter. Incomplete or outdated records leave gaps, and a drawing cannot confirm the condition of equipment or the effectiveness of a safeguard.
The resulting plan should separate work that can be completed safely now from changes that must wait for the next suitable maintenance window. Reviewing remote access permissions may be an immediate priority. More extensive modifications need coordination with equipment suppliers and operational teams, with interim measures where necessary.
Recovery deserves the same attention as prevention. The International Maritime Organization’s cyber risk guidance includes restoring essential systems and addressing underlying causes.
In practice, owners should establish which configurations and software are needed, who can provide technical support, and what checks will show that controls and protective functions work correctly after restoration.
These arrangements should be rehearsed under safe conditions. Crews need to understand the limits of local or alternative control, while shore teams need clear responsibilities for coordinating technical evidence with the master and relevant authorities. A successful software restart alone cannot establish that a cargo operation is safe.
The starting point differs by stage of a ship’s life. For newbuilds, these questions belong in design reviews and commissioning. Connections should limit the spread of an incident, alternative control and protection arrangements need verification, and the information and recovery resources handed over at delivery must remain usable as the ship changes.
For an existing fleet, I would start by asking each vessel team to explain how it would maintain safe control if a critical digital system became untrustworthy, and what evidence it would need before resuming the affected operation. The gaps in those answers can guide the next maintenance budget and exercise.
