Taking inventory of port and shipboard systems

This article is also available in French.

Cellular modems were fitted to ship-to-shore cranes bound for US ports while those cranes were being built in China. Port technicians saw them, assumed they were there for remote maintenance, and moved on. Yet the modems appeared in no contract: the remote diagnostics option they corresponded to had been declined at purchase. A joint report by two committees of the US House of Representatives documented the case in September 2024 [1]. Connected to Linux computers inside the cranes, the modems “created an obscure method to collect information, and bypass firewalls in a manner that could potentially disrupt port operations”, the committees wrote. At another port, a modem turned up in the server room hosting the cranes’ firewall and networking equipment, and port officials could not say why it was there [2].

Underneath the geopolitical reading of the affair sits something more mundane and far more general: those ports did not know exactly what was plugged in on their own premises. That is the starting point of any cybersecurity effort, and also the step most readily skipped, because it is tedious and produces no visible result. In ports and aboard ships, it is considerably harder than elsewhere. The file is not closed either: in 2026 the US Maritime Administration renewed its advisory on Chinese-made port equipment, ZPMC cranes included.

No two ports are alike

ENISA says so itself in its 2019 reference report on port cybersecurity [3]: the asset taxonomy it proposes “should not be considered as comprehensive” and “doesn’t reflect the diversity and the specificities of different ports”. The French DGITM guide “Ports cybersécurisés”, which built on that foundation in 2022, is blunter still: from one port to the next, IT and industrial systems are not the same, are not operated and managed by the same kinds of stakeholders, and are not implemented in the same way [4].

Community systems make the point on their own. In France, the Port Community System (PCS) and the Cargo Community System (CCS) are two separate systems under separate governance, the latter run by private companies. In the Netherlands, the PCS of Amsterdam and Rotterdam merged, and the CCS there is the same system as the PCS. The same three letters therefore cover scopes, owners and exposure surfaces that have nothing in common. An asset list copied from a neighbouring port yields a false inventory, and a false inventory is worse than none, because it reassures.

I covered the ENISA report when it came out, and the European framework has grown since, with the EU ports strategy placing the agency at the centre of cooperation. The documentary foundation, though, is still the one laid in 2019 and 2020.

Ten families of assets

The ENISA taxonomy distinguishes ten categories: fixed infrastructure, mobile infrastructure, OT systems and networks, associated OT end devices, IT systems, associated IT end devices, networks and communication components, safety and security systems, information and data, and finally people. The structure has one great merit: it forbids reducing the inventory to whatever an antivirus console can see. Tugs and pilot boats, floating barriers, FAL declarations, container release codes and temporarily authorised contractors all belong in it, just as servers do. That list is what the major risk scenarios are then built on.

The business systems: PCS, CCS, TOS, VTS

The PCS is the single window for port calls: arrival and departure dates, crew lists, dangerous goods declarations, service bookings. The CCS carries the information about cargo and containers. The Terminal Operating System (TOS) optimises logistics, transhipment and storage for the terminal operator. The Vessel Traffic Service (VTS), and its VTMIS extension, monitors traffic. To these add berth management systems, port corporate systems, and, in fishing ports, fisheries information management systems.

Counting those building blocks is easy. Their dependencies are what catches people out. On 4 July 2023 the port of Nagoya was hit by ransomware attributed to LockBit, which brought down the Nagoya United Terminal System, the platform shared by the port’s five container terminals. Cargo handling resumed two days later [5]. One line in the inventory, five terminals behind it.

These systems also belong to the security domain, on the same footing as the fence and the badges. Europol has documented container release PIN code fraud in the ports of Antwerp, Rotterdam and Hamburg [6], and the NarcoFiles investigation showed how a Dutch IT specialist accessed container management systems in Rotterdam and Antwerp to tell traffickers which containers to target [7]. A poorly recorded CCS is a fence with a hole in it.

Industrial systems, from the crane to the pumps

On the OT side, ENISA groups into one family the industrial control systems that handle access and berthing (bridges, locks, gates), port infrastructure and terminal operations: PLCs and RTUs, historians and MES, supervisory systems such as SCADA or DCS, programming consoles and engineering workstations, maintenance systems and safety instrumented systems. Then come the end devices: cranes and gantries, passenger ramps, belts and conveyors, silos and hoppers, barcode readers, liquid meters, RFID, electronic seals, weighbridges, automatic plate readers, and fault detectors on automated handling lines.

Pumping deserves a mention of its own, because it is almost always missing from diagrams of port information systems. The DGITM guide lists it twice among port services: in vessel loading and unloading, and in temporary storage, as “pumping of bulk liquids and tank filling”. In early February 2022, a ransomware attack against Oiltanking and Mabanaft in Germany, SEA-Invest in Belgium and Evos in the Netherlands disrupted barge loading and unloading across seventeen oil terminals, including those in Hamburg, Ghent, Antwerp-Zeebrugge and Rotterdam [8]. Those terminals are run by companies that are not the port authority, so they fall outside the port’s own inventory scope while remaining part of it operationally. The ecosystem always extends beyond the port authority, as the wave of denial of service attacks against forty Romanian maritime entities in the summer of 2026 showed in its own way.

Add to this the electrical network, high voltage in the larger ports, onshore power supply for berthed vessels, lighting, reefer cooling, water and waste treatment.

CCTV and access control, caught between two chairs

ENISA files video surveillance, incident management systems, automatic gates, smart fencing, badging systems, radar and electro-optical monitoring, X-ray scanners, biometrics and facial recognition, sirens and evacuation guidance under a separate family: safety and security systems. This equipment sits neither quite in IT nor quite in OT, and the classification choice reflects an organisational reality. It is ordered by the security department, fitted by an installer, maintained remotely by the vendor, and rarely shows up in the inventory kept by the IT department.

A modern CCTV installation is a network of Linux computers, with a recorder, a management server, usually a remote access path for the maintainer, and its own update cycle. In France, the port security order of 29 June 2026 started to address this by subjecting automatic plate readers to ANSSI recommendations, while leaving surveillance drones outside the scheme. The affair of the Chinese-origin cameras on Royal Navy drones was a reminder, a few weeks later, that the supply chain behind such equipment deserves a line in the inventory, with the name of the actual manufacturer next to that of the integrator.

Telecoms, which nobody claims

VHF radio, TETRA networks, RFID, quayside Wi-Fi, private 4G and 5G, microwave links, fibre, satellite links, and GNSS receivers that double as the time source synchronising other equipment. ENISA notes that these networks “can be managed by different stakeholders at different levels”. That is a diplomatic way of saying that in many ports, nobody can name the owner of a given fibre strand or the administrator of an access point installed by a concession holder eight years ago.

Aboard: the inventory becomes a written requirement

Ships raise the same problem with one added constraint: the system was assembled by a yard, often from equipment whose configuration and maintenance remain in the hands of the suppliers. A penetration test on board turns up the same findings every time: forgotten boxes on the bridge, an undocumented remote access path for a maintainer, NMEA traffic on the ship’s network.

IACS settled the matter by mandating the inventory. Its unified requirement UR E26, applicable to ships contracted for construction on or after 1 July 2024, requires “an inventory of hardware and software (including application programs, operating systems, if any, firmware and other software components) of the CBSs in the scope of applicability of this UR and of the networks connecting such systems to each other and to other CBSs onboard or ashore” [9]. The scope covers propulsion, steering, anchoring and mooring, electrical power generation and distribution, fire detection and extinguishing, bilge and ballast systems together with the loading computer, watertight integrity and flooding detection, lighting, and required safety systems, plus statutory navigation and communication systems.

The text requires the inventory to be kept up to date throughout the life of the ship, and every hardware or software change liable to introduce a vulnerability or alter dependencies between systems to be recorded in it. It adds a point that is often forgotten: where the inventory holds IP addresses, protocols or port numbers, access to that information must be restricted. The inventory is itself a sensitive document.

UR E27, addressed to equipment suppliers, sets the level of detail expected for each computer based system: list of hardware components, brand and manufacturer, model and type, a short description of the function, physical interfaces, name and type of the system software, version and patch level, supported communication protocols, and for each software component the hardware it is installed on [10]. It also requires two topology diagrams, one physical and one logical, the latter showing data flows, communication paths and protocols.

These requirements only reach newbuildings, though. The existing fleet depends on IMO guidance, and there a quiet change occurred. Revision 3 of circular MSC-FAL.1/Circ.3, issued on 4 April 2025, adds to the “Identify” element a requirement absent from the previous version: “Establish and maintain an inventory of digital systems on board the ship” and “Identify internal and external systems dependencies and network connections” [11]. The list of systems to consider explicitly mentions cargo, bunkering, lubrication, ballast and other pumping handling and management systems. These are recommendations, but they are the ones ISM audits refer to now that resolution MSC.428(98) has folded cyber risk into the safety management system.

On the US side, the Coast Guard rule that took effect on 16 July 2025 binds US-flagged vessels and MTSA-regulated facilities directly. 33 CFR 101.650 requires owners and operators to “maintain an accurate inventory of network-connected systems, including designation of critical IT and OT systems”, to “develop and maintain a list of approved hardware, firmware, and software that may be installed on IT or OT systems”, and to keep accurate documentation of the network map and OT device configuration [12]. Segmentation between IT and OT networks appears separately, alongside an obligation to log and monitor every connection between the two. I have looked elsewhere at the waiver and equivalency regime that goes with this rule.

Why the exercise resists

ENISA devoted a chapter of its 2020 guidelines on cyber risk management for ports to this very question [13]. The obstacles it lists are the ones actually met in the field: difficulty evaluating assets and services managed by third parties; difficulty attributing every asset, application and staff member to the service it helps deliver; configuration management of OT systems, whose vendors do not expose settings interfaces, shifting the dependency onto their support; the impossibility of running an automated discovery tool without risking disruption to legacy or segmented industrial equipment, and legacy is no small matter when Windows XP is still in service in places; and scattered procurement across groups operating several terminals, each entity with its own channels.

The DGITM adds the structural reason: port systems are developed, managed and maintained by different teams or entities, in house or contracted, on different technologies, with separate IT and OT security teams, which makes mapping all port systems hard to define and hard to maintain over time.

Maintaining it over time is the real difficulty, and it is the one point on which IACS insists as much as on the content of the inventory itself.

Where to start

ENISA recommends choosing the angle explicitly: an asset-based inventory, or a service-based one. For an organisation starting out, enumerating assets is the necessary first pass. For a more mature one, it is better to start from the service delivered, loading and unloading a container for instance, and work back to the applications and equipment that support it. The second approach surfaces dependencies on third parties.

Each asset is worth recording three times over: by the system it belongs to, by the service it supports, and by the information it handles. Dependencies deserve description at the level of technical interfaces and data exchanges, with third party software, with vendors, and between the IT and OT worlds.

On the industrial side, discovery has to be adapted: the DGITM explicitly recommends passive monitoring for industrial systems, and centralised tooling to detect unauthorised assets. A policy on permitted devices and software completes the picture, which is exactly what the US rule codifies.

That leaves the part no tool covers. ENISA recommends involving the cybersecurity function in the review of procurement contracts. That is the only mechanism which, in the crane affair, would have allowed the modems to be refused outright, or at least provided a contractual basis for demanding their removal. And the modems came to light because port teams went to inspect the cranes at the Chinese factory. An inventory, in the end, is the discipline of going to look, and writing down what you found.

For a broader introduction to the families of maritime information systems, the articles on maritime information systems and their peculiarities set out the general frame this exercise fits into.

Sources

• [1] House Committee on Homeland Security and Select Committee on the Chinese Communist Party, joint investigative report on US port infrastructure security (12 September 2024)
• [2] House Committee on Homeland Security, statement on the joint investigation findings (12 March 2024)
• [3] ENISA, “Port Cybersecurity - Good practices for cybersecurity in the maritime sector” (November 2019)
• [4] DGITM, “Ports cybersécurisés - Guide de bonnes pratiques pour la cybersécurité dans le secteur portuaire” (2022, in French)
• [5] Industrial Cyber, resumption of operations at the port of Nagoya after the ransomware attack (July 2023)
• [6] Europol, “Criminal networks in EU ports - Risks and challenges for law enforcement” (2023)
• [7] OCCRP, NarcoFiles investigation, “Inside Job: How a Hacker Helped Cocaine Traffickers Infiltrate Europe’s Biggest Ports”
• [8] The Maritime Executive, cyberattack disrupting northern European oil hubs (February 2022)
• [9] IACS, unified requirement UR E26 Rev.1, “Cyber resilience of ships” (November 2023)
• [10] IACS, unified requirement UR E27 Rev.1, “Cyber resilience of on-board systems and equipment” (September 2023)
• [11] IMO, circular MSC-FAL.1/Circ.3/Rev.3, “Guidelines on maritime cyber risk management” (4 April 2025)
• [12] 33 CFR 101.650, “Cybersecurity measures”, from the US Coast Guard final rule published in the Federal Register on 17 January 2025 and effective 16 July 2025
• [13] ENISA, “Guidelines - Cyber Risk Management for Ports” (December 2020)