Maritime OT Security: SCADA and Control System Testing

What Vessel OT and SCADA Actually Control

Operational technology on a vessel is the layer that directly senses and controls physical machinery. Unlike the IoT telemetry layer, which mostly observes and reports, OT acts: it opens valves, adjusts engine parameters, manages electrical load, and sequences machinery. A modern vessel runs several distinct OT domains. Engine control and monitoring handles the main engine and auxiliaries through dedicated controllers and an alarm and monitoring system. Power management systems balance generation and load across the vessel electrical plant. Machinery automation sequences pumps, compressors and auxiliary systems.

Beyond propulsion, cargo control is its own OT environment, especially complex on tankers, gas carriers and chemical carriers where valve sequencing, tank monitoring and inert gas systems must be coordinated precisely. Ballast water management, including treatment systems, is OT. Scrubber and emissions abatement control is OT. Steering gear and its control are safety-critical OT. Each domain typically uses programmable logic controllers, supervisory SCADA-style displays, and industrial fieldbuses to tie sensors and actuators together.

What unites these domains is that they were engineered for reliability and determinism, not for resisting an adversary. Controllers run firmware that updates rarely. Buses carry unauthenticated traffic. Engineering workstations hold the configuration software and the keys to reprogram controllers. The threat model that enterprise IT internalised years ago has only recently reached this equipment, and the in-service fleet still runs designs that predate it.

Why OT Testing Is Not IT Testing With Saltwater

The defining constraint of maritime OT assessment is safety. An IT or web pentest can throw malformed input at a service and watch it crash, because a crashed web server is an inconvenience. A control system is different. Fuzzing a propulsion control loop, scanning a power management bus aggressively, or probing a steering controller while the vessel is underway can cause real physical consequences. Many industrial controllers are fragile to unexpected traffic and can fault or halt when scanned with ordinary IT tools.

This reshapes the entire methodology. At sea, OT work is restricted to passive observation: mirroring traffic on a SPAN port, reviewing controller and switch configurations with the chief engineer, and reading the network rather than poking it. Active testing, constrained scanning, protocol interaction, control-path verification, is reserved for port stay or dry dock, and even then only on systems that are not actively required for a safety function at that moment, with the engineering team fully briefed and a rollback understood in advance.

The tooling differs too. Aggressive IT scanners are replaced with rate-limited, OT-aware discovery, passive protocol analysers, and manual configuration review. The goal is not to break the control system to prove a point, it is to understand the architecture, the protocols, the trust relationships and the conduits well enough to find the exposure without ever risking the machinery. The best maritime OT assessment finds the serious issues without the vessel ever noticing the assessor was there.

Industrial Protocols: Modbus, Serial Buses and Their Weaknesses

The protocols that tie vessel OT together were designed in an era when the network was assumed to be a closed, trusted, physically protected environment. Modbus is the canonical example: widely used across engine, cargo and auxiliary systems, it has no authentication and no encryption in its classic forms. Any device that can reach a Modbus segment can read register values and, in many configurations, write them, which means issuing commands to controllers. The protocol simply trusts whoever is on the wire.

Serial fieldbuses and proprietary vendor buses share the same fundamental property: trust is implied by physical connection. NMEA-derived navigation buses, CAN-based machinery buses and various vendor-specific protocols generally carry unsigned, unencrypted traffic. The security model was the locked engine-control room and the physically isolated cable run, not cryptography. That model breaks the moment the OT network is bridged, even indirectly, to IT, satcom, crew or vendor networks.

In assessment, the practical implications are concrete. We map which protocols are in use on which segments, identify every device that can speak on each bus, and trace whether anything outside the intended OT zone can reach those segments. Where Modbus or similar protocols are reachable from a less-trusted network, that is a serious finding, because the protocol itself offers no defence. The mitigation is rarely to fix the protocol, which the equipment cannot do, but to isolate it: keep the unauthenticated bus inside a tightly controlled zone where only authorised, authenticated systems can reach it.

• Modbus: no authentication, no encryption; read and often write access to controllers for anyone on the segment
• Serial and CAN-based buses: trust implied by physical connection, unsigned traffic, no native access control
• Proprietary vendor buses: often undocumented, frequently unauthenticated, sometimes reachable from engineering workstations on IT networks
• Key risk: any path from a less-trusted network (IT, crew, vendor, satcom) to an unauthenticated OT bus is exploitable by design

Applying IEC 62443 Zones and Conduits to a Vessel

IEC 62443 is the international standard family for industrial automation and control system security, and it maps cleanly onto a vessel. Its central concept is zones and conduits: group assets of similar criticality and trust into zones, define every communication path between zones as a conduit, and apply controls to each conduit so that only required, authorised traffic crosses. Each zone is assigned a target security level based on the consequence of its compromise.

On a vessel, a workable zoning model separates engine and propulsion control OT, power management OT, cargo control OT, navigation and bridge OT, vessel IT, and crew networks into distinct zones, each with its own security level. The most safety-critical zones, propulsion, steering, power management, carry the highest target security levels and the most restrictive conduits. Crossings between OT zones and anything less trusted are reduced to the minimum necessary, each one firewalled, allow-listed and logged.

The conduit discipline is where most of the security value lands. Engineering workstations that hold controller programming software are a particularly sensitive conduit, because they can reprogram PLCs; they should live in a controlled zone with strict access, not on the general vessel IT network. Vendor remote access is another conduit that demands explicit treatment. Assessing a vessel against IEC 62443 means verifying that the zones exist in reality and not just on a diagram, that the conduits are enforced by actual firewall rules, and that the security levels match the consequence of compromise.

Remote Vendor Access: The Highest-Risk Conduit

Engine OEMs, automation vendors and control-system integrators frequently maintain remote access into vessel control systems for diagnostics, tuning and support. This is operationally valuable and genuinely useful, but it is also the single highest-risk conduit on most vessels, because it is a path from outside the vessel directly into safety-critical control equipment. When that access is an always-on, unmonitored, unlogged tunnel, it is effectively a permanent backdoor into the machinery.

The findings here are consistent. Vendor tunnels that are permanently established rather than opened on request. Shared vendor credentials used across an entire fleet. No logging of what the vendor did during a session. No time limit, so access granted for one job persists indefinitely. Remote-access endpoints placed on the IT network with a direct path to the OT zone, collapsing the segmentation that protects everything else.

The correct pattern is a brokered, hardened jump host. Vendor access is requested and approved per session, opened for a defined window, routed through a hardened intermediary that authenticates the vendor and records the session, and closed afterwards. The jump host sits in a controlled conduit between the vendor and the OT zone, never giving the vendor a direct route. Session recording gives the operator an audit trail. Time-limiting ensures access does not outlive its purpose. This single change closes one of the most dangerous exposures on the vessel.

A Safe OT Assessment Methodology and Reporting

A defensible maritime OT assessment follows a staged methodology that puts safety first throughout. It begins with scoping and a safety briefing alongside the chief engineer and master, agreeing what may be tested, when, and what is strictly off limits while the vessel is operational. Passive discovery follows: traffic capture on OT segments, configuration review of controllers, switches and firewalls, and a corrected network map built from what actually exists rather than what the documentation claims.

Active testing, where it happens at all, is constrained, OT-aware and conducted at port or dock on systems not currently performing a safety function, with the engineering team present. The emphasis is on verifying segmentation and conduit enforcement, confirming whether unauthenticated buses are reachable from less-trusted zones, and checking the security of engineering workstations and vendor-access paths, not on stressing controllers. At every step the assessor errs toward observation over interaction when a control system is involved.

Reporting is built for the maritime audience. Findings are mapped against IEC 62443 zones, conduits and security levels, against IMO cyber risk management expectations, and given a maritime severity overlay that distinguishes safety-impacting from operations-impacting from IT-only issues, so the chief engineer, the technical superintendent and the company cyber lead can all read it. Each finding carries a practical, vessel-aware remediation that respects the operational realities of the equipment. Codesecure provides fixed-price proposals after a scoping call, with a free retest within 90 days.