Maritime software supplier DNV disclosed a ransomware attack against its ShipManager platform on the evening of January 7, according to securityaffairs.com and an earlier post on keyboard.co.il (originally reported by securityaffairs.com). About 1,000 vessels across roughly 70 customers were affected, based on the same disclosures.
DNV shut down the connected IT servers in response. Onboard offline functionality of the ShipManager software remained available. The Norwegian company also reported the incident to the Norwegian authorities and brought in global IT security partners to assist with forensic work.
Quick take
- Vendor: DNV (Norwegian), one of the largest maritime software providers.
- Product: ShipManager (fleet management, crewing, planned maintenance).
- Attack date: evening of January 7 (local time at the data center).
- Affected: 70 customers, around 1,000 vessels.
- Status: ShipManager IT servers shut down; onboard offline functions intact.
- Reporting: incident disclosed to the Norwegian authorities.
- Investigation: ongoing with global IT security partners.
- Attribution: ransomware family not yet disclosed as of the report.
- Corporate context: DNV's portfolio covers 13,175 vessels and mobile offshore units, about 21% of global tonnage.
Background: how we got here
The maritime sector has been a soft target for cybercriminals for years. Crewing, planned maintenance, procurement and class-certification work all run on a small number of shared software stacks, which means a single vendor incident can ripple across hundreds of operators. ShipManager sits in that exact category: it is the system a shore-side superintendent opens every morning, the same one a chief engineer reviews on the bridge, and the same one a vetting inspector pulls from during port state control.
DNV is the supplier in question. The Norwegian firm provides solutions and services across the life cycle of any vessel — design, engineering, risk assessment and ship management. Its own figures put the portfolio at 13,175 vessels and mobile offshore units, totaling 265.4 million gross tonnes. That is roughly a 21% global market share by tonnage, which is why an outage at DNV is not a niche event for the industry.
What changed on January 7
In the evening of Saturday January 7, the ShipManager environment was hit by a ransomware attack. DNV's response was to pull the connected IT servers offline. The platform's onboard, offline functionality — the part of the software that lives on a vessel's own network and does not need a live link back to DNV — kept working. The company began daily briefings with the 70 affected customers and brought in external forensic specialists.
At the time of the report, DNV had not named the ransomware family. That matters: some families are associated with double-extortion data leaks, others with encryption-only payloads, and the cleanup playbook is different for each. The "around 1,000 vessels" figure is a customer count — many operators use ShipManager across their entire fleet, so a single impacted shipping line can account for dozens of hulls.
Our analysis
There are three things worth pulling out of this incident.
The first is the offline mode. DNV designed ShipManager so that onboard users can keep working when the data link is dead. That is the right call. Most ransomware at maritime vendors in the last three years has either taken the cloud layer down or corrupted sync jobs, and crews that can keep logging maintenance locally are crews that don't drop out of class.
The second is the supply chain geometry. Even operators who never set up a DNV account can find their safety case under stress if a key data layer is gone. Procurement, dry-docking windows, condition-based maintenance thresholds — all of it routes through a few shared systems. The DNV incident is a textbook case of a low-probability, high-blast-radius event, and it will probably move more operators to ask vendors pointed questions about segmentation and recovery SLAs.
The third is the attribution gap. With no family named, defenders and competitors are guessing. If it turns out to be a financially motivated crew (the usual pattern in this sector), the negotiation posture and the data-leak risk differ from a state-aligned actor. Keep an eye on the next vendor update; the first 72 hours of disclosure usually leak the real shape of the intrusion.
Who benefits, who loses: DNV loses trust and faces remediation cost. Affected shipowners lose a planning tool but keep operations running. The attacker gains use over a single chokepoint that touches thousands of hulls — which is exactly why maritime software is a rising target.
Who should care
- Fleet IT and operations managers running ShipManager.
- Shipowners and operators without ShipManager but with shared vendors.
- Maritime insurers and P&I clubs tracking systemic risk.
- Class societies and port state inspectors relying on vendor data feeds.
A worked example
Say you run a fleet of ten product tankers on ShipManager. Day one: confirm with the master and chief engineer that onboard offline logging is working and that the latest planned maintenance schedules are mirrored locally. Day two: tell procurement to switch to manual purchase orders until the cloud stack is back. Day three: before reconnecting, validate backups on an isolated host and confirm the ransomware did not write into any sync folder that ships might pull from. The temptation is to rush the link back online to clear the backlog. Don't.
Bottom line
Maritime software is critical infrastructure by accident rather than by design, and the DNV ShipManager ransomware incident makes that obvious. Watch the next vendor update for the ransomware family and for any sign of data exfiltration. The structural lesson holds: any vendor serving 21% of global tonnage needs a tested offline mode, a tested re-entry procedure, and a disclosure timeline that customers can actually plan around.
Key takeaways
- Critical operational systems need a tested offline mode and a tested re-entry procedure.
- Maritime vendor incidents are classic supply-chain events with massive blast radius.
- Do not reconnect vessels or shore systems until backups are verified clean.
- Track the next DNV update for ransomware family and any data-leak signal.
Frequently asked questions
How many vessels were affected by the DNV ShipManager ransomware attack?
About 1,000 vessels across roughly 70 customers, per DNV's disclosure reported by securityaffairs.com and an earlier post on keyboard.co.il.
Could ships still operate during the outage?
Yes. DNV stated that onboard, offline functionality of the ShipManager software remained available, which let crews keep working without a live data link.
Which ransomware family hit ShipManager?
DNV had not disclosed the ransomware family at the time of the report, so attribution was still unknown.
Why does an outage at DNV matter beyond its own customers?
DNV's portfolio covers 13,175 vessels and mobile offshore units, around 21% of global tonnage, so an incident at the company has supply-chain effects across a large share of the world's fleet.
What should a ShipManager user do in the short term?
Run on the offline mode, switch procurement and planning to manual processes, validate backups on an isolated host before any reconnect, and wait for DNV's forensic update before pulling live data again.