When the Bridge Goes Haywire
Passive scans reveal Rockwell and Modbus PLCs controlling America's movable bridges and navigation locks answering on the public internet.
Jeff Gray · August 11, 2026 · 8 min read
OT Architecture · Control Systems Security
Movable bridge control systems should be invisible from the public internet. Passive search results suggest otherwise.
Imagine a hurricane pressing the coast. Emergency planners are ready. Roads are reversed. Shelters are staged. Then a key bridge or a set of bridges goes haywire.
The movable bridge, a bascule, swing, or vertical lift span, is meant to open for marine traffic and close for vehicles on demand. When it works, it is an elegant piece of electromechanical choreography. PLCs read position sensors, interlocks verify clearance, drives rotate counterweights, and signal lights tell drivers when it is safe to cross.
When it does not work, or worse, when it works in ways nobody intended, that choreography becomes a hazard. And the first sign that someone might not be working with the intended script is this:
What We Found
Using passive Shodan searches, no active scanning, no probing, we queried for devices responding to industrial protocol banners on known ports. The results were not theoretical.
Rockwell PLCs (EtherNet/IP, port 44818)
- 37 devices in Alabama
- 49 devices in the New Orleans metro area
- 6 devices globally with "lock" in their banner — a small count, but it confirms that devices at navigation lock infrastructure are present in the public index. This is an existence signal, not a volume estimate.
Source: Passive Shodan search, developer tier. Query: port:44818 with geographic and keyword filters.
Modbus Devices (port 502)
- 91 devices in Alabama
- 218 devices in the New Orleans metro area
- 12 devices globally with "lock" in their banner — again, a small number. It tells us this type of infrastructure is represented in the searchable surface. Do not treat it as a full inventory.
Source: Passive Shodan search, developer tier. Query: port:502 with geographic and keyword filters.
We did not inspect any of these devices, confirm what each one controls, or attempt to identify specific hardware models or operators. The point is not to catalog individual assets. It is to paint the broader picture: industrial protocol hardware, of the same families used in movable bridges, navigation locks, and related control systems across the country, is present in publicly reachable search indexes. That is the observation, and it is enough to ask the architectural questions that follow.
These numbers sit in the same corridor as some of the most heavily trafficked movable spans in the country, many of which carry structurally deficient ratings, and alongside navigation locks that run continuously to keep commercial barges moving through the Mississippi and Intracoastal Waterway. The physical infrastructure is already under strain. The OT surface sitting behind it should not be making that strain harder to manage.
These are devices that answered. They are publicly reachable. That does not mean every one is exploitable, unsegmented, or unauthenticated. It means that from the open internet, a query reaches a PLC at a location that controls physical movement, and the PLC answers.
How This Should Be Designed
In a properly designed high assurance OT architecture, the control path for a movable bridge, or any navigation lock or dam, should not have a bidirectional path from the public internet or even from lower trust networks.
The ideal design looks like this:
- The control network, which means the PLCs, drives, interlocks, position sensors, and traffic signals, sits behind a unidirectional gateway or equivalent one way transfer mechanism.
- Monitoring and status data can flow out. Operators can see what is happening.
- Commands, firmware updates, and configuration changes cannot flow in without deliberate, human mediated, or highly controlled break glass procedures.
This follows the spirit of IEC 62443 zones and conduits, NIST SP 800-82, and the higher assurance patterns used in nuclear, some water, and certain critical infrastructure sectors. The principle is simple: information can leave, commands cannot enter, not without someone looking at it first.
How This Actually Exists Today
Most existing movable bridge installations were never built that way. The typical reality is conventional firewalls with rules that accumulate over years, VPNs for vendor access and remote diagnostics, jump hosts and remote desktop for operational convenience, and in the worst cases, direct exposure of industrial protocols on interfaces reachable from the public internet.
Remote operation capability, which AASHTO has been formalizing guidance around, almost always requires some form of bidirectional connectivity. Pure unidirectional designs make remote command and control much harder, so operators and vendors often prioritize operational convenience over strict one way enforcement.
Why the Gap Exists
None of this is malicious or careless by design. The gap is structural.
Age
Many movable bridges are decades old and have been incrementally modernized. A network port was added for a vendor diagnostic tool. A firewall rule was created for remote monitoring. A router was replaced during a hurricane recovery project. Each change made sense at the time.
Value of Remote Access
Remote monitoring and diagnostics are valuable and sometimes contractually required. Being able to check a PLC status without dispatching a technician saves time, money, and in emergencies, may be the difference between an informed response and a blind one.
Cost and Complexity
Full unidirectional architecture with mediated control adds cost, complexity, and operational friction. Until relatively recently, cybersecurity was not a primary design driver for highway movable bridges.
Convenience Wins
When a vendor needs access to troubleshoot a failed span at 2 AM, the path of least resistance is the one that gets the bridge open. The path of maximum security is the one that requires three approvals and a data diode. Guess which one gets built at 2 AM.
What This Means
The fact that Rockwell and Modbus devices are answering on the public internet at navigation infrastructure sites is not, by itself, proof of imminent compromise. It is proof of architectural divergence, the gap between what high assurance design recommends and what the current installed base actually implements.
In a properly segmented high assurance design, those Shodan queries would return nothing. The PLCs would not answer. The protocols would not be visible. The control network would be a dark zone, visible from the inside, invisible from the outside.
That is the standard. And by that standard, the current state of America's movable bridge and navigation lock infrastructure has significant work ahead.
Assessing Your Own Exposure
If your organization operates OT assets that move physical things, bridges, locks, dams, gates, barriers, the questions to ask are not theoretical:
- What protocols are running on your control network? If Modbus, EtherNet/IP, or proprietary industrial protocols are visible from outside your control zone, the exposure is real.
- Is your control path unidirectional? Can monitoring data flow out without command data flowing in? If not, you do not have a boundary, you have a door.
- What happens during an emergency? When the hurricane hits and everyone needs remote access, does your architecture hold or does it collapse under operational pressure?
Further reading and the OT Risk Readiness framework 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. This research does not attribute specific devices to specific facilities.