Shipping and Maritime: A Cyber Incident Is Now a Hazardous Condition

Shipping runs on a different clock from most industries.

When something goes wrong here, the immediate cost is rarely a disclosure notice. It is a terminal that cannot release containers, a vessel that cannot demonstrate seaworthiness, a berth window missed, and a set of downstream customers whose own operations stall behind yours.

The reference point is still Maersk in 2017. NotPetya looked like ransomware, with a ransom demand on every screen, but it was built to destroy. Instead of locking data for payment, it made machines unusable, and paying would not have brought them back. It reached the company through a compromised accounting software update in Ukraine and forced the rebuild of roughly 4,000 servers, 45,000 workstations and 2,500 applications in around ten days. Maersk put its losses at approximately $250–300 million. No customer data was the target. The damage was operational.

That is the gear change. In this sector, security failures are availability and operational continuity failures.

Why the maritime cloud problem has a different shape

Five characteristics compound in ways they do not elsewhere.

IT and OT have converged, and cloud is now attached to physical operations

Fleet management platforms, terminal operating systems, vessel telemetry, predictive maintenance, cargo tracking, port community systems, ERP integrations. Cloud workloads are no longer adjacent to operations; they feed them. A misconfigured storage account holding route data or terminal schedules is an operational asset, not a filing cabinet.

Operations are federated by nature

A shipping group is a collection of entities: flag-state companies, regional offices, terminals, joint ventures, and fleets acquired rather than built, each arriving with its own cloud accounts and its own habits. The central platform team writes the policy, but it can only enforce it in accounts it controls. In the rest, a standard is published, a questionnaire is completed, and the configuration is whatever the local team chose. All of it carries the company’s name.

Third parties are structural, not incidental

Port agents, freight forwarders, customs brokers, chandlers, classification societies, equipment vendors, and systems integrators are embedded in maritime operations. Many have delegated access to internal systems or manage cloud resources on the company's behalf. Unlike the fragmentation across internal entities, these external relationships introduce another layer of risk: security depends on configurations, access permissions, and practices managed by organizations outside your direct control. A misconfiguration or excessive privilege in a supplier-managed environment can create exposure across your operations, even when your own cloud accounts are properly secured.

Security teams are small relative to the estate

Headcount in this sector runs well below what comparable revenue supports elsewhere, and the work does not scale by adding people, because the people are not there to add.

Shipping is a focused target, caught in the crossfire

It sits between nation-states, and between organized criminals and their economic targets. Maersk was collateral damage in NotPetya, a destructive attack aimed at Ukraine. Since then ports themselves have been hit: the LockBit ransomware group took down the Port of Nagoya’s container terminal for two days in July 2023, and a November 2023 attack on DP World Australia shut ports handling around 40% of the country’s freight for about three days. Whatever the motive, the outcome for the operator is the same: the ship waits.

Attacks on shipping also tend to be of a different kind. Shipping is especially exposed to computer network attacks (CNA), operations meant to disrupt, deny or destroy rather than quietly gather information over months. They are one-shot and noisy. NotPetya left Maersk without usable IT for ten days. A ransomware attack stopped the Port of Nagoya’s container terminal for two days. DP World’s Australian ports were shut for about three days. There is no long dwell time in which to find the intruder, and no quiet period in which to remediate. These attacks behave like a missile, not a surveillance campaign. Detecting the missile after it lands helps nobody. The only useful moment is before the hit, and the only useful action is to prevent it.

The question here is not who saw the data. It is whether the ship sails.

The uncomfortable arithmetic

Consider what detection-based security actually delivers in this setting.

A cloud misconfiguration is created. A scan finds it some hours or days later. A finding is raised. It is triaged, an owner is identified across a federated estate that may span a joint venture or a port agent, a fix is agreed, a change window is found - and change windows in operational environments are scarce, because the thing you are changing is attached to something that moves cargo.

Meanwhile the exposure is live, and if it touches an operational system, so is the continuity risk.

ITIC's survey work has consistently found that more than 90% of enterprises put a single hour of downtime above $300,000. Against that, the cost of preventing a misconfiguration is a rounding error - and the cost of a change window in a live terminal is not.

Prevention avoids two costs here, not one: the exposure, and the change window needed to remediate it.

What the regulators and analysts are saying

• The US Coast Guard has made cyber a safety matter, in the legal sense. Its final rule, Cybersecurity in the Marine Transportation System, published 17 January 2025 and effective 16 July 2025, is the first mandatory cybersecurity framework under the Maritime Transportation Security Act. Most significantly, it revises the definition of "hazardous condition" to expressly include cyber incidents - placing them inside the same regime as a fire, a grounding or a structural failure.
• Gartner remains consistent on the cause. Its assessment is that through 2027, 99% of records compromised in cloud environments will be the result of user misconfigurations rather than attacker sophistication or provider failure.
• The Cloud Security Alliance points at scale and third parties. Its Top Threats to Cloud Computing 2026, published in August, ranks Insecure Third-Party Resources at number three, up from fifth in 2024, and observes that the most exposed organisations are those "whose governance, visibility, and change management have not kept pace with the complexity of their environments."

For a federated operator with hundreds of counterparties, that last sentence is not an abstraction. It is a description of the operating model.

The regulatory picture, stated accurately

Three regimes now overlap, and all of them are in force.

• IMO Resolution MSC.428(98) has required cyber risk to be addressed within a ship’s Safety Management System (SMS) since January 2021, for cargo ships of 500 gross tonnage and above. Cyber risk sits inside the SMS, which means it is inspected the way safety management is inspected.
• IACS Unified Requirements E26 and E27 apply to new vessels contracted for construction on or after 1 July 2024. E26 covers cyber resilience of the vessel as a whole, IT and OT. E27 covers onboard systems and equipment. Both draw on IEC 62443 and extend to third-party supplied equipment. They are not retroactive, so a mixed-age fleet carries mixed obligations.
• The USCG final rule took effect 16 July 2025. Reportable cyber incidents must go to the National Response Center immediately on discovery. Personnel training obligations under 33 CFR 101.650 began in January 2026 and recur annually. Later phases require a designated Cybersecurity Officer, a Cybersecurity Assessment and a Cybersecurity Plan.
• In Europe, NIS2 brings transport in scope as an essential sector with its own governance and reporting duties.

What "hazardous condition" actually changes

It is worth sitting with that reclassification, because it changes who cares. A data breach is handled by legal, compliance and communications. A hazardous condition is handled by the Captain of the Port. It touches vessel detention, port state control and the operating licence. It is the same category of problem as a defective fire suppression system. Which means cyber configuration has quietly become a seaworthiness and operability question, subject to inspection regimes designed for physical safety.

Think about how those regimes treat a defective fire suppression system. They work from conditions. A documented remediation plan answers a different question from the one an inspector asks, which is whether the fault is there. A safety regime does not ask how fast you found the fault. It asks whether the fault exists.

For the cloud, that points one way. Detecting a misconfiguration and opening a ticket is a way of managing a condition that already exists. The only approach that answers the inspector’s question is one where the condition never exists, which makes this a prevention problem before it is a detection problem. That is a materially different bar from "we detected it and opened a ticket."

What our shipping customer said

Adoption in this sector is not primarily a technology question. Small teams, federated operations and operational risk mean the vendor relationship carries more weight than the feature list.

“The openness and trying to work together as true partners has been very evident. My team had really nothing but positive things to say about working with your team.”

- IT Security Manager, Shipping, US

That is worth reading for what it does not say. It does not describe a product capability. It describes a working relationship - which, for a team that is thin against a large federated estate and cannot absorb a failed rollout, is the thing that determines whether a security programme actually lands.

How Aryon helps

Aryon enforces cloud security policy at the moment of deployment, at the cloud control plane, so the risky configuration never exists.

Mapped onto the constraints above:

The change window problem disappears

‍A misconfiguration prevented at deployment needs no remediation, so it needs no change window in an operational environment. This is the single largest practical difference in a sector where changing a running system is genuinely hard.

It is safe to switch on in a live estate

‍Enforcement applies to new deployments, and Aryon does not perform auto-remediation on running infrastructure. Nothing already supporting operations is altered.

Federated estates are governed centrally

‍A joint venture, an acquired fleet or a regional office operating in your tenancy passes through the same enforcement as your platform team, without adopting your tooling or completing onboarding.

Third parties get your policy, not their habits

‍An agent, integrator or equipment vendor with delegated access is governed identically to your own engineers - which is CSA's number three threat handled by control rather than by questionnaire.

Evidence suits an inspection regime

‍Rather than assembling a point-in-time gap analysis before an audit, you hold a continuous record of what policy applied and what was prevented - which is closer to how safety management evidence is expected to look.

It suits a small team

‍Enforcement scales by policy, not by headcount. One policy prevents a class of misconfiguration across every account, every region and every cloud.

Where to start

Take the cloud account supporting your most operationally critical system - the terminal operating platform, the fleet management stack, the port community system.

Ask what would happen today if someone deployed a storage account there reachable from any network, or a role with far more access than it needs. If the answer is that a scan would find it and a ticket would be raised, ask the follow-up: how long until a change window opens to fix it?

That interval is your real exposure, and it is longer in this sector than almost any other.