A cargo terminal is an unusually clear example of a problem security teams see everywhere: digital records tell people what to do, and software failure can stop physical work without anyone touching the machinery. The same boundary exists in factories, warehouses and hospitals. Three documented port and shipping incidents show different ways it can fail: stolen data, destructive malware in a software supply chain, and ransomware against a coordinating system.
First, the terms matter. IT stores and moves business information. OT monitors or controls physical processes. IoT describes connected devices that sense, report or sometimes act on the physical world. These categories overlap; what matters to defenders is which connections can turn an IT incident into a bad physical decision.
Antwerp: the systems stayed up, but the data were stolen
Between roughly 2011 and 2013, a trafficking group allegedly recruited hackers to gain access to the systems of at least two companies at Belgium’s Port of Antwerp. Prosecutors said the group used container-location and security data to collect drug shipments before their legitimate owners could. Workers noticed containers disappearing. The BBC’s account cites police and prosecutors; the suspects were awaiting trial when it was published, so this is an allegation reported by investigators, not a claimed conviction or attribution to a named cyber gang.
Technical point: this was an attack on data confidentiality, with a physical payoff. A logistics application might be operating normally while a legitimate-looking account queries more container records than its role requires. For a general SOC, think of an employee directory or warehouse inventory system used to identify valuable targets. Protect sensitive records with role-scoped access, strong authentication and audit logs; correlate unusual searches with actual release or collection events. Business email compromise and forged pickup instructions are related risks, but they are not what the public Antwerp account establishes.
Maersk: the supplier update that crossed a business boundary
In June 2017, NotPetya reached Maersk through compromised M.E.Doc accounting software and spread across its corporate network. Booking systems failed, and WIRED’s reconstruction describes serious disruption at 17 APM terminals. It also says computers aboard Maersk’s ships were not infected. The company’s chair estimated losses of $250 million–$300 million. A port-economics case study records the knock-on disruption to cargo operations.
Technical point: a trusted software-update route into IT can become a business-continuity incident far beyond that application’s intended use. NotPetya displayed a ransom demand, but was destructive rather than a recoverable encryption-and-payment scheme. Even a crane that remains operational is of little use if the booking and coordination systems it relies on are unavailable. The United States attributed the wider campaign to the Russian military; WIRED associates it with Sandworm. That does not establish Maersk as the intended target. Defenses here are restricted trust between business segments, tested offline recovery and a plan for operating when a critical IT service is unavailable—not the fiction that every machine at the port was hacked.
Nagoya: ransomware hits the coordination layer
At Japan’s Port of Nagoya in July 2023, ransomware affected the Nagoya Port Unified Terminal System, the software used to coordinate container-terminal work. Contemporaneous reporting drawing on the port’s notice and its operating association says container operations stopped for about two and a half days. The association reported a ransom demand carrying the LockBit name; that is not independent confirmation of the humans behind the intrusion. The initial access route is not established in the cited account.
Technical point: a terminal operating system sits between enterprise records and physical work. It tracks containers and coordinates moves; the cranes’ controllers handle machinery. If the coordinating system is unavailable, equipment can be mechanically sound while staff cannot safely execute the planned workflow. This is an IT-to-operations dependency, not evidence that ransomware took control of a crane. Model the dependency, keep a recoverable copy of the relevant data, and rehearse how operators verify its integrity before restarting.
Where IT, OT and IoT actually meet
IT is the instruction and record layer. Think email, identity systems, databases, shipping manifests, billing and the terminal operating system. Data flows among the shipping company, the terminal and truck operators. A phishing-led account takeover can change a payment instruction or cargo-release request; ransomware can make bookings unreadable; a compromised software supplier can distribute malicious code through a channel administrators normally trust. The Antwerp, Maersk and Nagoya cases each illustrate one of these failure modes, though none establishes a bridge-system compromise.
OT is the physical control layer. A crane, for example, has sensors and controllers that report position and enforce its intended movements; operators use human-machine interfaces to supervise the process. A vessel has different OT: machinery control, alarms and bridge equipment subject to safety procedures. OT networks often connect to management systems for work orders, maintenance or telemetry. An attacker who gains access to those management paths might disrupt visibility, issue unauthorized commands or interfere with operations if control paths and safeguards allow it. That is a risk model, not a claim about the three incidents. OT differs from ordinary IT because availability, equipment damage and human safety matter immediately; a routine scan, patch or emergency reboot can itself interrupt a process. NIST’s OT guide and Australia’s OT security principles make that distinction explicit.
IoT is the connected-device layer. A refrigerated container may report temperature through a sensor and wireless gateway to a dashboard. A ship’s connected tracking or condition-monitoring device may send status through a cellular or satellite link. These devices often run embedded firmware, use vendor cloud services and remain deployed long after someone has forgotten the original account. Weak device credentials, vulnerable firmware or a compromised cloud account can make telemetry unavailable or untrustworthy: a dashboard says the cargo is cold when the sensor reading cannot be trusted. A separate control interface could create a bigger problem, but a bad reading alone does not prove that the refrigeration controller was changed. Likewise, a suspect GNSS position or AIS broadcast is not proof that anyone broke into a vessel; interference and equipment faults are alternative explanations.
The boundary to investigate is device → gateway → application → human decision → physical action. Which side can initiate connections? Who can change a setpoint? Does the dashboard label stale data? Can the operator verify an anomalous reading independently? The same questions apply to smart-building sensors, factory telemetry and medical-device fleets. Avoid treating every connected sensor as a controller—or every IT outage as an OT intrusion.
A compact defense plan for non-maritime teams
Start with a dependency diagram for one critical workflow, not a giant asset spreadsheet. Identify the IT service that issues work, the OT process that performs it and the IoT data people use to decide whether it worked. Record supplier-operated accounts and remote-support paths. Segment business IT from control networks; limit traffic across the boundary to documented needs. Require named accounts, multifactor authentication, time-limited sessions and logging for remote maintenance; ensure an operator can disconnect that path. UK NCSC guidance on OT connectivity addresses the trade-off between remote access and isolation.
Patching and visibility also need different rules. Patch exposed IT quickly, but schedule controller and embedded-device firmware changes with engineers and vendors, with a test and rollback plan. Prefer passive OT discovery unless active probing is approved. Back up business records and controller configurations; verify that staff can restore both and reconcile what happened while systems were down. In monitoring, join identity alerts, vendor sessions and application audit trails with whatever passive device/OT telemetry is safely available. Train staff to verify exceptional payments, release requests and changed sensor readings through a second trusted channel.
To exercise this without pretending to run a port, use a familiar scenario: a supplier account is compromised, a business application becomes unavailable, and a sensor dashboard still shows apparently normal values. Ask the security team, service owner and engineers what they can trust, what must stop, and what evidence permits restart. CISA’s tabletop packages are a starting point; a cyber range can add synthetic logs and simulated equipment. MITRE ATT&CK for ICS can help choose detection questions, and Apache Caldera can emulate selected behavior on lab IT hosts. Neither a tabletop nor a generic range certifies the safety of real machinery. Technical testing must be explicitly authorized and confined to an isolated lab or approved environment, never improvised on live OT or vessel systems.
The transferable lesson is not that every cargo ship is hackable. It is that security boundaries must be designed around how information becomes physical work. Antwerp lost control of information; Maersk lost a critical business network through a supplier; Nagoya lost the software that coordinated operations. Each failure called for a different detection and recovery plan.
Sources
- BBC News, “Police warning after drug traffickers’ cyber-attack,” 16 October 2013. https://www.bbc.com/news/world-europe-24539417
- WIRED, “The Untold Story of NotPetya, the Most Devastating Cyberattack in History,” 22 August 2018. https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/
- Port Economics, Management and Policy, “Petya Ransomware Cyber-Attack on Maersk,” date not stated. https://porteconomicsmanagement.org/pemp/contents/part11/safety-security-and-cybersecurity/petya-ransomware-cyber-attack-maersk/
- Industrial Cyber, “Operations at Japan’s Port of Nagoya resume, after probable LockBit ransomware attack,” 6 July 2023. https://industrialcyber.co/transport/operations-at-japans-port-of-nagoya-resume-after-probable-lockbit-ransomware-attack/
- NIST, Guide to Operational Technology (OT) Security, 28 September 2023. https://www.nist.gov/publications/guide-operational-technology-ot-security
- Australian Cyber Security Centre, Principles of operational technology cyber security, 2 October 2024. https://www.cyber.gov.au/publication/principles-of-operational-technology-cyber-security
- UK National Cyber Security Centre, Secure connectivity principles for operational technology, reviewed 18 March 2024. https://www.ncsc.gov.uk/collection/operational-technology/secure-connectivity
- CISA, “CISA Tabletop Exercise Packages,” date not stated. https://www.cisa.gov/resources-tools/services/cisa-tabletop-exercise-packages
- MITRE, “ATT&CK Matrix for ICS,” accessed 27 October 2026. https://attack.mitre.org/matrices/ics/
- Apache Software Foundation, “Apache Caldera,” accessed 27 October 2026. https://caldera.apache.org/
Marco Fazio
Author
