The Crane That No One Can See
You can't distinguish a crane PLC from any other PLC remotely. That's the point.
Jeff Gray · August 13, 2026
Maritime OT · Control Systems Security
The S.S. Uh Oh. What happens when crane control systems go wrong is the question. The harder question is: who can see those control systems from the outside?
In March 2024, a joint congressional investigation raised alarms about Chinese-made ZPMC cranes at US ports. Unauthorized cellular modems. Repeated remote-access requests. West Coast terminal operators were on edge. The story was everywhere: foreign hardware, foreign access, foreign risk.
Then the Coast Guard assessed 92-plus ZPMC cranes and reported back: no unique vulnerabilities specific to foreign cranes.
The Coast Guard's finding wasn't that the cranes were secure. It was that the cranes were insecure the same way everything else is insecure — weak passwords, missing segmentation, unpatched systems, exposed services. The problem wasn't China. The problem was OT.
What the Data Actually Shows
Passive searches for industrial protocols (EtherNet/IP and Modbus TCP) return devices answering from the same metropolitan areas that contain major container terminals. Device banners almost never contain functional labels such as "crane," "gantry," or "terminal." They identify vendor, product family, and firmware — not the physical process the controller operates.
Occasionally an integrator- or owner-set hostname appears that may hint at a site or role. These are ambiguous signals at best and cannot support attribution.
The observation is therefore limited but still meaningful: industrial protocol devices of the same families used to control ship-to-shore and yard equipment are publicly reachable in the same cities that operate those systems. Reachability is the first prerequisite for everything that follows. Attribution is not possible from passive data alone, and that limitation is itself part of the finding.
This matches the broader pattern documented by the Coast Guard in its assessments of ZPMC cranes: the problems observed were not unique foreign backdoors, but the same common OT hygiene and architecture issues found across industrial systems — weak segmentation, remote access paths, and exposed services.
The Regulatory Window Is Open Right Now
In July 2025, the Coast Guard's Maritime Transportation Security Act cybersecurity rule took effect. Ports with automated cranes fall under 33 CFR Part 101, Subpart F — a phased compliance framework that requires cybersecurity plans, designated cybersecurity officers, assessments, training, and incident reporting to the National Response Center.
The rule exists. The question is what the installed base actually looks like, and whether the compliance paperwork maps to the physical reality of a terminal where a 20-year-old PLC is running crane motions that nobody has documented, connected to a network that nobody has mapped, accessible through a firewall rule that nobody remembers creating.
The PEMA (Pacific Maritime Association) guidance for container terminals recommends IEC 62443-aligned vendor selection, incident response planning, security audits, penetration testing, network isolation, MFA-backed remote access, and — critically — asset inventory for legacy crane PLCs. That last point is telling. The industry knows the legacy controllers are the blind spot.
Why the ZPMC Debate Misses the Point
The congressional focus on ZPMC cranes — where they're made, who makes them, what backdoors they might have — is a distraction from the architectural reality that applies to every crane at every port, regardless of manufacturer.
A ZPMC crane, a Liebherr crane, a Kalmar crane, a Konecranes crane — they all use industrial control systems. They all run PLCs. Those PLCs speak EtherNet/IP, Modbus, Profinet, or proprietary protocols. And those protocols, by design, do not announce what physical system they control.
The question isn't whether a Chinese-made crane has a vulnerability that a European-made crane doesn't. The question is whether the crane's control network is segmented from the public internet, whether remote access is authenticated and mediated, and whether the terminal operator has a unidirectional data flow design that allows monitoring information to leave the control zone without allowing commands to enter it.
That design question is the same for every crane. Foreign or domestic, new or legacy, ZPMC or Liebherr — the architecture either holds or it doesn't.
How Crane Control Should Be Designed
The high-assurance pattern for any OT system that moves physical things is the same pattern we discussed for movable bridges and navigation locks:
- The control network — PLCs, drives, interlocks, position sensors, limit switches, anti-sway systems — sits behind a unidirectional gateway or equivalent one-way transfer mechanism.
- Monitoring and status data can flow out. Terminal operators can see crane position, load weight, cycle time, and fault status.
- Commands, firmware updates, and configuration changes cannot flow in without deliberate, human-mediated, or highly controlled break-glass procedures.
This follows IEC 62443 zones and conduits, NIST SP 800-82, and the MTSA cybersecurity rule's requirements for network and data security controls. The principle: information can leave, commands cannot enter, not without someone looking at it first.
Most existing port crane installations were never built that way. The typical reality looks like conventional firewalls with rules that accumulate over years, VPNs for vendor access and remote diagnostics, cellular modems for remote monitoring (the very thing that triggered the ZPMC investigation), and in some cases, direct exposure of industrial protocols on interfaces reachable from the terminal network — or worse, from the internet.
The Operational Reality at 2 AM
When a crane stalls during a vessel operation
Every minute a ship-to-shore crane is down costs the terminal thousands of dollars in vessel delay, truck queuing, and contractual penalties. The vendor needs remote access now. The path of least resistance is the one that gets the crane moving. The path of maximum security requires approvals, mediated access, and audit logging. Guess which one gets built at 2 AM during a live vessel operation.
When a cellular modem provides remote monitoring
The cellular modem was installed for operational convenience — someone wanted to check crane status from home. It wasn't in the security architecture. It wasn't in the asset inventory. It wasn't in the cybersecurity plan required by the MTSA rule. But it was there, answering, and it became the story.
When the legacy PLC has no documentation
A crane commissioned in 2008 had its control system upgraded in 2012 with a new HMI and a network connection for data logging. The PLC still runs the same ladder logic, but nobody has the source. Nobody knows what the interlock logic does. Nobody has tested the safety chain. The crane moves containers every day. The PLC answers queries from the terminal network. Nobody knows what else it answers to.
What This Means
The Coast Guard was right: there's nothing unique about foreign cranes. The problem is universal. Industrial protocols don't identify their purpose. Port operators don't have complete inventories of crane PLCs. The regulatory framework assumes visibility that doesn't exist. And the operational pressure at 2 AM will always favor convenience over architecture.
Passive Shodan searches return thousands of industrial protocol devices in port cities. We found zero that identified themselves as crane controllers. Not because crane PLCs aren't there. Because they don't say what they are.
That's the design problem. Not the manufacturing problem. Not the supply chain problem. The design problem.
Assessing Your Own Exposure
If your organization operates port infrastructure with automated material handling equipment — cranes, conveyors, gates, stacking systems — the questions to ask are practical:
- Do you have a verified inventory of every PLC that controls physical movement? Not the network devices. The ones that actually move things. If you can't answer this with documentation, testing, and physical verification, you have a gap.
- Can you distinguish your crane controllers from your other industrial devices through passive observation? If not, neither can an attacker. And neither can your security team.
- Is your crane control path unidirectional? Can monitoring data flow out without command data flowing in? If remote access is bidirectional by design, you don't have a boundary — you have a door.
- What happens when a crane stalls during a live vessel operation? Does your architecture support mediated emergency access, or does it collapse under operational pressure?
The OT Risk Readiness framework and maritime assessment guidance are available at controlsystemssecurity.com.
All data in this article was collected through passive Shodan search queries. No active scanning, no probing, no interaction with target systems was performed. Findings represent publicly indexed device banners, not vulnerability assessments. Device function was not determined — only protocol response. This research does not attribute specific devices to specific facilities or operators.