Maritime Cybersecurity

What Protocols Are Used Onboard Ships? A Cybersecurity Perspective

Published 23/8/2026· OT Cyber Defence

Ships use a wide range of operational technology (OT), from systems that are very specific to the maritime environment, such as ECDIS and other navigational equipment, to common industrial technologies such as Programmable Logic Controllers (PLCs), sensors and automation systems.

Modern ships are also becoming more connected. IoT sensors, condition-monitoring systems, remote diagnostics and ship-to-shore data platforms are increasingly being added to traditional shipboard systems.

Behind all these systems are communication protocols.

During my time sailing as an Electro-Technical Officer (ETO), I worked with several of these technologies from an operational and maintenance perspective. Today, working in cybersecurity, I look at the same communication paths from another perspective: What happens if someone who is not supposed to communicate with these systems manages to do so?

That is what we will explore in this article.

We will look at some of the common protocols and communication technologies found onboard ships, including NMEA, HART, CAN Bus, Modbus, Siemens industrial communication, OPC UA and MQTT, and then look at them through an OT cybersecurity lens.

Various Shipboard Protocols and Their Roles

Before discussing individual protocols, it is important to understand that they do not all do the same job or operate at the same level.

For example, NMEA 0183 is used to exchange navigational data over serial interfaces, while Modbus TCP carries Modbus messages over TCP/IP. Ethernet provides the underlying network for many modern systems, whereas MQTT is an application-layer messaging protocol commonly associated with IoT architectures.

A simplified overview looks like this:

This distinction becomes important when securing a vessel because there is no single security solution that can simply be applied to every protocol.

1. NMEA Protocols

The National Marine Electronics Association (NMEA) develops standards used for communication between marine electronic equipment.

Three important standards in this area are NMEA 0183 ¹, NMEA 2000 and OneNet.

Figure 1: Simplified NMEA network architecture showing the ship ECDIS receiving data from various sources.

NMEA 0183

NMEA 0183 is commonly associated with serial communication between navigational equipment.

A ship’s navigation systems require information from multiple sources. GPS/GNSS provides position, the gyrocompass provides heading, the speed log provides vessel speed, and other instruments provide additional navigational data.

NMEA 0183 provides a standardized way of exchanging this information between compatible marine equipment.

NMEA 2000

NMEA 2000 uses a different architecture. It is based on CAN technology and allows multiple marine electronic devices to communicate over a common network.

Instead of relying only on separate point-to-point communication paths, multiple compatible devices can exchange information over the same network.

OneNet

OneNet takes marine networking further by bringing NMEA communication into an Ethernet/IP-based environment.

If we look at these technologies together, we can see an interesting evolution:

Serial communication → CAN-based networking → Ethernet/IP networking

The same broad change can be seen elsewhere onboard ships: equipment that was once relatively standalone is increasingly becoming interconnected.

2. HART Protocol

HART stands for Highway Addressable Remote Transducer.

It is widely used with industrial field instrumentation and allows digital communication to coexist with the traditional 4–20 mA analogue signal.

This is one of the technologies I encountered directly while working onboard.

For example, a pressure or flow transmitter may provide its primary process value through a 4–20 mA loop, while a HART communicator can be connected for configuration, diagnostics and access to additional device information. It has dual channel configuration where it superimposes low-level digital communication signals onto a legacy 4–20 mA current loop using Frequency Shift Keying (FSK). This enables two-way field communication for device diagnostics, configuration, and extra variables without interrupting the primary analog process signal.

This is a good example of how a protocol may exist very close to the actual physical process. While cybersecurity discussions often focus on servers, PLCs and firewalls, the data used by those systems ultimately comes from field devices such as transmitters and sensors.

3. CAN Bus

Controller Area Network (CAN) is another communication technology that can be found in machinery and control environments.

CAN was originally developed to provide reliable communication between electronic controllers without requiring a central host computer.

Its efficiency and reliability have resulted in its use beyond automotive applications, including industrial and marine systems.

In a shipboard environment, CAN-based networks may be present inside machinery packages, engine-control systems and other equipment where multiple electronic controllers need to exchange information.

NMEA 2000 itself is also based on CAN technology.

4. Modbus RTU and Modbus TCP

Modbus ² is one of the best-known industrial communication protocols and is still widely used across industrial environments.

Modbus RTU

Modbus RTU typically operates over serial communication, commonly using RS-485.

It provides a relatively simple way for industrial devices to exchange values such as coil states, register values and measurements. It uses two wire (half-duplex) or four wire (full-duplex) configuration for communication.

For example, a PLC may read measurements from a power meter or another industrial device using Modbus RTU.

Modbus TCP

Modbus TCP brings Modbus communication onto TCP/IP networks.

Instead of exchanging Modbus messages over a serial connection, the communication can take place across Ethernet networks using TCP.

This makes integration between different industrial systems much easier, particularly when data needs to move between PLCs, HMIs, gateways and monitoring systems.

The Modbus Organization continues to maintain specifications for both serial and TCP/IP implementations. It has also published a separate Modbus Security ³ specification that combines Modbus with TLS and certificate-based authentication.

5. Siemens S7 Communication and PROFINET

Siemens SIMATIC S7 PLCs are widely used in industrial automation.

Siemens automation environments may use S7 communication, PROFINET and other technologies depending on the architecture.

PLCs may control pumps, valves, compressors and other machinery, while HMIs and engineering workstations communicate with the controllers for monitoring, troubleshooting and configuration.

6. OPC UA

OPC Unified Architecture (OPC UA) ⁴ provides a standardized way for industrial systems from different vendors and platforms to exchange information.

Unlike many older industrial protocols, security was an important part of OPC UA’s design. OPC UA can support encryption, message signing, application authentication, user authentication and auditing. ⁵

This makes OPC UA particularly interesting as OT systems become more interconnected and information needs to move between industrial equipment, applications and enterprise or cloud environments.

7. MQTT

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol commonly used in IoT environments.

Instead of every device communicating directly with every other device, MQTT commonly uses a broker.

A sensor, application or gateway can publish information to a topic, while another application can subscribe to that topic.

For example, consider a vessel collecting fuel-consumption information. Sensors and monitoring equipment may provide data to an onboard system or IoT gateway, which can then forward selected information to a shore or cloud platform.

This type of architecture is becoming increasingly relevant as shipping companies seek near-real-time visibility into vessel performance.

8. Other Wireless IoT Technologies

Wireless technologies can be useful where installing additional cabling is difficult or where battery-powered sensors need to operate for long periods.

Their use onboard will depend heavily on the application and equipment installed. But as more wireless and IoT devices are introduced, they also become part of the vessel’s overall cyber attack surface.

Looking at Shipboard Protocols Through a Cybersecurity Lens

Now that we know what some of these protocols do, the more interesting question is: Are they secure?

The answer is not simply yes or no.

Many legacy industrial and marine protocols were developed when the environments around them were very different from what we see today.

Industrial networks were expected to be relatively isolated and accessible mainly to trusted equipment and personnel.

The priorities were therefore:

Reliability, availability, interoperability and efficient communication.

Authentication, encryption and protection against a remote cyber attacker were not always primary design requirements.

The problem is that the environment around these protocols has changed.

NMEA and the Navigation Data Problem

Consider NMEA 0183.

The protocol provides a standardized way for marine equipment to exchange navigational information, but legacy NMEA communication was not designed around modern concepts such as strong authentication and encryption.

This becomes important when navigational data starts passing through gateways and interconnected networks.

A recent study examining the exposure of NMEA gateways found thousands of Internet-facing endpoints transmitting NMEA messages. Researchers also created a maritime honeypot to observe activity directed toward an exposed gateway. ⁶

The honeypot received scanning and reconnaissance activity, although the researchers did not observe attacks specifically targeting the NMEA gateway protocol during the experiment. Separately, the researchers demonstrated scenarios involving GPS spoofing, AIS injection, autopilot manipulation and resource-exhaustion attacks.

This distinction is important.

Simply finding an Internet-exposed system does not mean it has already been compromised. But operational equipment being unnecessarily reachable from an untrusted network creates an attack opportunity that did not need to exist in the first place.

CAN Bus and the Importance of the Attack Path

Traditional CAN communication also has limited native security capabilities compared with modern secure network protocols.

If an attacker gains sufficient access to a CAN-based control network, malicious message injection or manipulation becomes a concern.

But the important phrase here is: If the attacker gains access.

Someone sitting somewhere on the Internet cannot automatically manipulate an engine-control CAN bus simply because CAN itself lacks modern authentication.

There needs to be an attack path.

That path could potentially involve:

• A compromised maintenance computer
• An insecure gateway
• Poorly segmented networks
• Remote-access infrastructure
• A compromised engineering workstation
• Another trusted system connected to the control environment

This is why OT cybersecurity cannot be reduced to asking whether an individual protocol is secure. Network architecture matters just as much as protocol security.

What About HART and Field Devices?

Field instrumentation may appear far removed from traditional cybersecurity.

A pressure transmitter connected through a 4–20 mA loop is obviously very different from an Internet-facing server.

But consider what happens if the configuration or calibration of a field device is modified.

The controller may continue operating normally while receiving incorrect process information.

That makes the integrity of field devices, their configuration and the engineering tools used to access them important parts of OT cybersecurity.

The closer we get to the physical process, the more important data integrity becomes.

Why Is Modbus Still Used if It Isn’t Inherently Secure?

Traditional Modbus communication does not inherently provide the authentication and encryption expected from many modern secure protocols.

If an attacker gains access to an inadequately protected Modbus network, the attacker may potentially read process information or, depending on the device and configuration, attempt write operations.

A natural question then comes up: If Modbus has these limitations, why not simply replace it?

Industrial environments work differently from consumer IT.

A PLC or industrial controller may remain operational for 15 or 20 years, sometimes even longer. Machinery may have been designed around existing interfaces, and changing the communication protocol can require changes to controllers, field equipment, engineering software and other dependent systems.

There is also a simple reason why Modbus became so widely used: It is simple and it works.

Therefore, the solution cannot always be “remove Modbus.”

Instead, legacy communication needs to be protected by the architecture around it.

That can include segmentation, restricting communication to required devices, limiting unnecessary services, controlling engineering access and monitoring abnormal network activity.

It is also worth noting that the protocol ecosystem itself has evolved. The Modbus Organization’s newer Modbus Security specification uses TLS and X.509 certificates to provide authentication and message-integrity protection.

PLC Communication and the Stuxnet Lesson

PLC cybersecurity deserves particular attention because PLCs can directly affect physical processes.

If an attacker compromises an engineering environment with sufficient privileges, modifying PLC logic could potentially change how machinery operates.

The best-known example is Stuxnet cyberattack. Stuxnet was a highly sophisticated cyberweapon that targeted Iran’s nuclear facilities by manipulating programmable logic controllers (PLCs) to self-destruct uranium enrichment centrifuges. This attack demonstrated an important lesson that applies across OT environments:

Compromising the digital engineering environment can ultimately create physical consequences.

For ships, this means an engineering workstation capable of changing PLC logic should not be treated like an ordinary office computer.

A Secure Protocol Can Still Be Deployed Insecurely

OPC UA provides a useful contrast to many legacy protocols.

It supports capabilities such as encryption, authentication, message signing and auditing.

Does that mean an OPC UA deployment is automatically secure?

No.

Security features can be disabled. Certificates can be poorly managed. Access permissions can be too broad. An endpoint can be exposed where it should not be.

This leads to an important OT cybersecurity principle: A secure protocol can still be deployed insecurely.

Configuration and architecture matter.

MQTT, IoT Gateways and Ship-to-Shore Connectivity

MQTT presents a different security problem because it is commonly associated with IoT architectures and moving telemetry between systems.

Suppose an MQTT broker or IoT gateway is exposed or poorly configured.

Weak authentication, excessive permissions, insecure communication or a compromised gateway could affect the confidentiality or integrity of the information being exchanged.

The concern becomes particularly interesting onboard ships because the gateway may sit somewhere between operational equipment and external shore or cloud platforms.

Wireless Protocols Add Another Attack Surface

Wireless technologies such as Zigbee add another dimension because communication does not require a physical network cable.

Security considerations can include device authentication, key management, wireless exposure, availability and protection against resource-exhaustion attacks.

As more IoT sensors are installed onboard, these devices should not be considered separately from the vessel’s cybersecurity programme.

They need to appear in asset inventories and network diagrams just like more traditional OT equipment.

A Protocol Doesn’t Need a Vulnerability for an Attack to Succeed

This is one of the most important concepts when looking at OT cybersecurity.

Suppose Modbus itself is working exactly as designed.

An attacker who compromises an authorized engineering workstation may not need to exploit Modbus at all.

The workstation may already be allowed to communicate with the PLC.

Similarly, an IoT gateway may legitimately collect information from an engine-monitoring system.

If that gateway becomes compromised, an attacker may abuse an already trusted communication path.

The cybersecurity problem therefore goes beyond finding vulnerabilities in individual protocols.

We need to understand: Who can communicate with what, through which path, using which protocol, and for what purpose?

Example: From an Engine Sensor to a Shore Dashboard

Consider a modern vessel where fuel-flow and engine-performance information is collected onboard.

A simplified data path could look like this:

Sensor / Engine Monitoring System → IoT Gateway → Ship IT/OT Boundary → Satellite Connection → Cloud Platform → Shore Dashboard

Notice something important here. The engine PLC itself does not necessarily need to be connected to the Internet.

Suppose an attacker compromises the IoT gateway or another trusted component somewhere along this data path.

The attacker may potentially manipulate telemetry before it reaches shore.

The immediate consequence may simply be loss of data integrity: the shore team sees incorrect fuel-consumption or machinery-performance information.

But suppose that information is subsequently used for:

• Fuel-efficiency recommendations
• Maintenance planning
• Machinery-performance analysis
• Operational decision-making

Incorrect data can now influence decisions.

The attacker did not necessarily need to reprogram the engine PLC. Compromising a trusted data path may be enough to affect decisions further up the chain.

The same principle applies to other connected systems.

This is why simply asking: “Is the PLC connected to the Internet?” is not enough.

A better question is: What systems are connected to the PLC, what are those systems connected to, and where do those trust relationships eventually lead?

What Is the Purdue Model in OT Cybersecurity?

One way of understanding an industrial network is through the Purdue Model.

The Purdue Model separates an industrial environment into different levels according to the role of the systems at each level.

A simplified representation is:

Level 0 – Physical Process

This is where the actual physical process takes place.

It includes equipment such as:

• Sensors
• Transmitters
• Actuators
• Motors
• Valves

On a ship, this could include a pressure transmitter measuring lubricating-oil pressure or an actuator operating a valve.

Level 1 – Basic Control

This level contains systems that directly control the physical process.

Examples include:

• PLCs
• Remote I/O
• Local controllers
• Machinery controllers

A PLC controlling pumps or auxiliary machinery would typically fit around this level.

Level 2 – Supervisory Control

This is where operators monitor and interact with the process.

Examples include:

• HMIs
• Operator stations
• Alarm and monitoring interfaces
• Engineering workstations

The PLC may be running the control logic, while an engineer or operator views the process through an HMI at this level.

Level 3 – Site Operations

Level 3 contains systems supporting the wider operation of the industrial environment.

Depending on the architecture, this may include:

• Operations servers
• Historians
• Maintenance systems
• OT management services

This is where information from multiple control systems may start being aggregated for wider operational use.

Level 3.5 – Industrial DMZ

Although not part of the original Purdue hierarchy, a DMZ is commonly introduced between OT and enterprise IT.

The idea is simple: IT and OT should not need unrestricted direct communication.

Services that need to exchange information across the boundary can instead be placed or proxied through controlled systems in the DMZ.

Examples may include:

• Jump servers
• Update repositories
• Data-transfer services
• Remote-access gateways
• Proxy services

Level 4 – Enterprise IT

This includes normal business systems such as:

• Email
• Office computers
• Business applications
• Enterprise servers

On a ship, the exact mapping is less straightforward than in a large factory, but business and administrative systems can broadly sit on the IT side of the architecture.

Level 5 – External / Internet / Cloud

Above the enterprise environment are external services such as:

• Internet
• Shore data centres
• Cloud platforms
• Vendor services
• Fleet-management platforms

For a connected vessel, VSAT or LEO satellite connectivity such as Starlink can provide the communication path between the ship and these external environments.

Applying Purdue to a Ship

A very simplified shipboard interpretation might look like:

Shore / Cloud / Internet
↓
VSAT / Starlink
↓
Ship IT / Business Network
↓
OT DMZ / Controlled Boundary
↓
OT Monitoring / HMI / Engineering Systems
↓
PLC / Machinery Controllers
↓
Sensors / Transmitters / Actuators

Figure 2: Purdue Model Concept Showing Shipboard Implementation.

However, a real vessel will not necessarily fit neatly into every Purdue level.

Navigation systems, vendor gateways, IoT platforms, remote diagnostics and cloud services can create communication paths that cross the traditional hierarchy.

That is why Purdue is useful as a conceptual model for segmentation, but should not be treated as a complete security architecture.

The more important principle is to identify zones and the controlled communication paths between those zones.

How Can Shipboard OT Systems Be Protected?

The first step is accepting that OT cyberattacks are possible.

Connecting a vessel to shore does not automatically make it insecure. But every new connection should have a reason, an owner and appropriate controls around it.

Know What Is Onboard

You cannot protect equipment you do not know exists.

Maintain an asset inventory covering:

• PLCs
• HMIs
• Engineering workstations
• IoT and industrial gateways
• Switches and firewalls
• Servers
• Sensors
• Navigation systems
• Remote-access systems

Where practical, the inventory should also include software or firmware versions, IP addresses, communication protocols and the owner or vendor responsible for the system.

Segment According to Function and Risk

Crew Internet, business systems, navigation equipment and machinery-control networks should not communicate freely simply because they are part of the same vessel.

VLANs can provide logical separation, but a VLAN by itself should not be treated as the complete security boundary.

Communication between sensitive zones should be controlled using appropriate firewalls and access-control policies.

Control Communication Between Zones

If an engine-monitoring gateway only needs to send specific data to another network, allow the communication that is actually required.

Do not automatically provide broad access between networks.

This is the principle of least privilege applied to network communication.

If only one system needs Modbus TCP communication to another system, there is little reason for every device in that network to have the same access.

Secure Remote Access

Remote vendor support can be extremely useful onboard ships, particularly when specialist engineers cannot physically reach the vessel.

But remote access also creates an important entry point.

Access should be:

• Authenticated
• Authorized
• Logged
• Time-bound where practical
• Enabled only when required

Depending on the architecture, controlled jump servers can provide an additional boundary between remote users and sensitive OT systems.

Protect Engineering Workstations

An engineering workstation capable of downloading logic to a PLC is fundamentally different from an ordinary monitoring computer.

Access to engineering software, PLC project files and controller programming functions should therefore be tightly controlled.

If an engineer only needs to monitor a process, that does not necessarily mean the account should also have permission to modify control logic.

Close Unnecessary Ports and Services

If a network service is not required, it should not remain exposed simply because it was enabled by default.

Communication between IT and OT zones should be documented.

For every firewall rule or port-opening request, useful questions include:

• Why is this connection required?
• Which source needs access?
• Which destination needs to be reached?
• Which protocol and port are required?
• Is communication required in both directions?
• Does the rule still need to exist?

Over time, these reviews prevent temporary connectivity requirements from becoming permanent attack paths.

Remove Default Credentials

Default usernames and passwords remain a basic but important security problem.

Credentials should be changed during commissioning and managed appropriately throughout the equipment lifecycle.

The same applies to IoT gateways, switches, firewalls and other network-connected devices—not only PLCs.

Control Removable Media

Ships frequently interact with outside personnel.

Service engineers, vendors and technicians may bring laptops, USB drives and diagnostic equipment onboard.

Removable media and maintenance computers can bridge otherwise separated environments.

Procedures for authorization, malware scanning and the use of external devices therefore remain particularly important onboard vessels.

Monitor What Is Happening

Prevention alone is not enough.

Firewall events, authentication logs, remote-access sessions, endpoint activity and unusual network communications can provide indications that something is wrong.

OT monitoring should, however, be designed carefully.

Availability and safety remain the priority, and security tools should not themselves interfere with operational systems.

Defence in Depth Is the Key

There is no single product that can secure all these protocols.

A firewall cannot compensate for weak passwords.

Encryption cannot compensate for a compromised engineering workstation.

Network segmentation cannot protect an organization if unrestricted remote-access credentials provide a path around it.

And an IDS cannot stop every attack simply because it can see network traffic.

Maritime OT cybersecurity therefore requires defence in depth.

Multiple controls should work together so that compromising one layer does not immediately give an attacker unrestricted access to operational systems.

A simplified defence-in-depth approach could include:

Asset Inventory → Segmentation → Firewall Policy → Access Control → Secure Remote Access → Endpoint Security → Monitoring → Incident Response

Figure 3: Defence-in-Depth Shipboard Implementation.

This becomes increasingly important as the maritime industry connects traditional OT equipment with modern IT, IoT and cloud platforms.

Final Thoughts

Protocols such as NMEA, HART, CAN, Modbus and S7 communication were created to solve operational problems. Their primary purpose was to make equipment communicate reliably, not to defend against every cybersecurity threat we face today.

At the same time, it would be wrong to conclude that every legacy protocol is automatically unsafe or that every newer protocol is automatically secure.

Newer technologies such as OPC UA provide stronger security capabilities. Even so, those capabilities still need to be configured and managed correctly.

The answer is also not to stop connecting ships.

The real challenge is understanding what is connected, why it is connected, which protocol it uses, who is allowed to communicate with it, and what happens if that trust is compromised.

Having worked with shipboard automation and instrumentation operationally, and now looking at these systems from a cybersecurity perspective, this is the biggest change I see:

The individual PLC, transmitter or navigation instrument may be doing exactly the same job it did before.

What has changed is the environment around it.

And that environment is becoming increasingly connected.

References