Why Shipboard OT Security Isn't IT Security

Defending a ship's control systems like corporate IT almost guarantees aiming at the wrong target. The reason is simple: their top priorities differ. This is not an empirical intuition — it is the logical consequence of engineering reality. Different physical consequences dictate different security priority orderings. In an enterprise network, the worst outcome is usually a data breach: customer records, trade secrets, or financial data stolen — serious, but the ship does not sink. In the engine room and on the bridge, the worst outcome is a loss of main engine control, a non-responsive rudder, or an ECDIS screen going dark — during a port approach window or in congested waters, these can cascade into casualties. This asymmetry of consequences is the first, most fundamental premise for understanding shipboard OT security.

The priorities are inverted

NIST's OT security guide (SP 800-82 Rev.3) puts it plainly: IT ranks confidentiality, integrity, availability; OT prioritizes "safety, followed by availability, integrity, and confidentiality." In an engine room, "just reboot it" on a running machine is often unacceptable — availability dominates.

More precisely, NIST SP 800-82 Rev.3 states that OT security requirements should be prioritized in the order: Safety → Availability → Integrity → Confidentiality — a full inversion of the Confidentiality-Integrity-Availability (CIA) triad familiar from IT. "AIC" is a shorthand used by industry commentators to describe this inverted ordering; it is not NIST's own acronym. Whatever shorthand one uses, the underlying logic is unchanged: a ship's control network is a direct interface to the physical world, and any security operation that temporarily disrupts system availability may create a more immediate danger than the threat it was meant to address.

Consider this scenario: a container ship making slow-speed maneuvers in a narrow strait. The ECDIS reboots without warning — forced by an uncoordinated security patch push — and the screen goes dark for 90 seconds. Ninety seconds is barely noticed in IT operations. For a fully laden ship holding course in a 10-knot tidal current, it could be catastrophic. This example is not extreme — it illustrates why "availability-first" is an engineering fact at sea, not a conservative excuse, and why directly transplanting enterprise IT security policies and tools onto a ship is dangerous.

NIST SP 800-82 Rev.3 reinforces this explicitly, stating that "OT cybersecurity programs should always be part of broader OT safety and reliability programs." The implication: any cybersecurity engineer modifying a shipboard OT configuration must first understand its safety implications — a consideration that virtually never arises in corporate IT.

A few hard constraints of shipboard OT

• Very long lifecycles: IT parts last 3–5 years, OT "can exceed 20 years"; the world fleet averages ~22.2 years (by vessel count)
• Protocol-level exposure: marine protocols like NMEA and CAN carry no built-in encryption or authentication
• No casual reboots: stopping real-time / safety systems is costly; many are "no-stop"
• 24/7 availability: unexpected downtime is often unacceptable
• Vendor black boxes: changes often only by the OEM; third-party security is constrained

What a 22.2-year average vessel age actually means

UNCTAD's Review of Maritime Transport 2023 reports that as of 1 January 2023, the global merchant fleet of propelled seagoing vessels of 100 GT and above had an average age of 22.2 years by vessel count. This figure requires some interpretation: it is a simple average weighted by number of ships, not by deadweight tons or gross tonnage — the GT-weighted average for 2024 was approximately 12.6 years, because newer ships tend to be larger. For cybersecurity purposes, however, the per-ship perspective is precisely the right one: each vessel is an independent attack surface, regardless of how much cargo it carries.

An average of 22.2 years means that a substantial share of the operational fleet had its control system hardware and software specified around 2000–2005. At that time, Windows XP was the mainstream operating system, NMEA 0183 was the unquestioned bridge standard, the concept of a ship network connected to shore was barely emerging, and external connectivity meant expensive per-minute VSAT dial-up. Equipment vendors of that era had no reason — and no means — to design against today's threat environment.

Pen Test Partners security researchers, during hands-on vessel penetration tests, documented ECDIS units running Windows NT (Microsoft ended support in 2004) and Windows XP (end-of-support April 2014). These are findings from a single practitioner firm's case experience, not a fleet-wide systematic survey, but the pattern they reveal is consistent with the industry's broadly accepted understanding of OT lifecycles. Compare this to the IT industry's normal cadence: enterprise laptops replaced every three years, servers every five; a server running an end-of-life OS for more than a decade is a near-unthinkable exception in IT, but may simply be the norm in shipboard OT.

The patching problem compounds this. IT systems receive security updates pushed automatically overnight. OT systems face a triple barrier: first, many OT devices require vendor re-certification before any software modification — an uncertified patch cannot legally be installed; second, shipboard OT systems cannot be taken offline while a vessel is at sea, so changes must wait for a port or anchorage maintenance window; third, satellite bandwidth is limited and expensive, making large update downloads costly underway. These three barriers stack, leaving shipboard OT systems unpatched for months or years after vulnerabilities are publicly disclosed — while those same systems are increasingly connected to external networks via VSAT, crew Wi-Fi, or port IT infrastructure.

Protocols without authentication: the "bare-wire" reality of maritime OT

The second structural weakness of shipboard OT networks comes from the design era of the communication protocols themselves. Two representative examples are NMEA 0183 and Modbus.

NMEA 0183 is the de facto common language of marine navigation equipment. According to Pen Test Partners' findings from real vessel audits, this protocol connects steering control, propulsion systems, dynamic positioning (DP), ballast water management, GPS, AIS (Automatic Identification System), Navtex (navigational telex), and BNWAS (Bridge Navigation Watch Alarm System) — a suite of safety-critical devices. Designed for closed serial-line environments, NMEA 0183 has no authentication mechanism (any device can send arbitrary messages), no encryption (all data transmitted in plaintext), and no message validation (recipients cannot verify the true source of a sentence). This means any attacker with access to an NMEA network segment can inject forged navigation data with no detection by the receiving system.

Modbus, published in 1979 and originally designed for serial PLC communication by Modicon (now Schneider Electric), remains widely deployed in industrial OT environments including ships. Modbus likewise has no authentication layer — any device can issue commands to a PLC — no encryption, and no native logging (no record of who issued which command and when).

A clarification on sourcing: the specific list of systems connected by NMEA 0183 comes from a single practitioner report (Pen Test Partners, 2017); the security deficiencies of the Modbus protocol are corroborated across multiple independent technical sources with higher confidence. Both protocols share the same design assumption: a physically isolated local serial network, not an IP network interconnected with the internet.

The reality of modern ships has diverged entirely from that design assumption. As broadband satellite (VSAT, Ku/Ka-band) has become standard, crew entertainment Wi-Fi has become expected, port-vessel data exchange has gone digital, and shore-based fleet management systems demand real-time equipment data, shipboard OT increasingly connects to external IP networks. The "unlocked door" of NMEA 0183 now opens onto a public-facing internet. In IT security terms: unauthenticated HTTP was recognized as unacceptable two decades ago; the equivalent security level still governs rudder response on ships today.

Compounding this is the "discovery-as-harm" problem specific to OT. Standard IT security tools — active network scanners, for example — can cause industrial OT devices to fault or reboot, because many OT devices cannot handle unexpected network packets, including standard ICMP pings. This creates a catch-22: the tools used to locate vulnerabilities may themselves trigger availability incidents. This observation has been independently documented by multiple OT security practitioners and deserves particular attention during any shipboard OT audit.

Three real incidents: what OT fragility looks like in practice

Beyond theory, documented real-world incidents illustrate the seriousness of the problem. The following three cases are drawn from public literature, each revealing a different dimension of shipboard OT security risk.

First case: ECDIS virus infection and delayed departure of a new dry-bulk vessel. The Guidelines on Cyber Security Onboard Ships, 3rd edition (December 2018), published jointly by BIMCO, ICS, INTERCARGO, INTERTANKO, and others, documents this event in detail: a newly built dry-bulk ship was delayed sailing for several days after both of its ECDIS networks were found to be infected with a virus. The ship was designed for paperless navigation and carried no paper charts — without a functioning ECDIS it could not legally depart. A vendor technician was required to visit the ship to diagnose and restore the systems. The guidelines' official conclusion: the infection vector was "unknown." This is a textbook deconstruction of the "air-gap" myth: the vessel was new, not yet in commercial service, still at the yard or berth. The BIMCO/ICS guidelines are explicit: "even air-gapped systems can be compromised." USB sticks, maintenance laptops, and supply-chain pathways are classic routes across an air gap, requiring no network connection.

Second case: Black Sea GPS spoofing, June 2017. On 22 June 2017, the US Maritime Administration (MARAD) issued Safety Alert 2017-005A, documenting a GPS anomaly in the northeastern Black Sea: more than 20 vessels in the same area simultaneously received the same false GPS position, placing them near an inland airport (Gelendzhik) approximately 25 nautical miles from their true position. GPS receivers reported high confidence in the false signal — a characteristic of GPS spoofing (rather than mere jamming): attackers transmitted a coherent false signal rather than simply suppressing the real one. The significance of this case is that what was attacked was not the shipboard OT equipment itself, but the input data on which the equipment depends. ECDIS, ARPA, AIS, and DP systems all consume that data with high implicit trust — as we default to doing with any "trusted-source" signal. This reveals another dimension of OT security: data integrity (corresponding to IEC 62443 FR3) and input-source verification are no less important than access control of the devices themselves.

Third case: Maersk NotPetya, 27 June 2017. NotPetya malware entered Maersk's global IT systems via a Ukrainian accounting software backdoor, forcing the company to reinstall approximately 4,000 servers, 45,000 PCs, and 2,500 applications in roughly 10 days — a task that would normally take six months. Maersk estimated losses of $250–300 million; 76 port terminal operations worldwide halted; ships maintained approximately 80% of container throughput through manual workarounds. An important qualification: NotPetya primarily struck Maersk's IT infrastructure (ERP systems, booking systems, terminal management software) — there is no public record of individual ships' propulsion or navigation OT being directly compromised. What this case demonstrates is how an IT-layer collapse can paralyze maritime OT operations across an entire global network: IT/OT interdependence, not pure OT compromise. This distinction matters, but the conclusion is equally sobering: in a highly integrated shipping ecosystem, a breach of IT security perimeters is sufficient to make global shipping operations non-functional.

IEC 62443: the bridge to E27

Industrial control security has a mature standard, IEC 62443, whose seven "foundational requirements" (FR1–FR7: identification & authentication, use control, system integrity, data confidentiality, restricted data flow, timely response to events, resource availability) plus Security Levels 1–4 form a common language. E27 §4 states that "the requirements in this section are based on the selected requirements in IEC 62443-3-3" — so E27 is essentially that OT-security language, applied to ships.

Each of IEC 62443's seven foundational requirements maps directly to the shipboard OT realities described above. FR1 (Identification and Authentication Control) addresses precisely what NMEA 0183 and Modbus lack. FR3 (System Integrity) addresses the input-data integrity exposure illustrated by the Black Sea GPS spoofing case. FR5 (Restricted Data Flow) is the normative expression of zone-and-conduit segmentation — preventing malicious traffic from the crew Wi-Fi zone from traversing laterally into propulsion controls. FR7 (Resource Availability) directly echoes the OT availability-first principle: any modification to a safety system must be shown not to degrade system availability.

IEC 62443's Zones-and-Conduits segmentation model is the architectural answer to the complexity of shipboard OT networks. Its core idea is grouping assets into security zones by risk level, with controlled conduits governing inter-zone communication. Applied to a ship, typical zones might include: bridge/navigation (ECDIS, GPS, AIS, radar), machinery/propulsion (AMS, main engine control, steering gear), cargo (cargo computer, ballast water system), and crew/hotel (crew network, entertainment). IACS UR E26 implements this model at the whole-ship level; UR E27 requires each Computer-Based System (CBS) to clearly define its interfaces to trusted and untrusted zones — exactly the question equipment vendors must answer at the design stage.

IEC 62443's four Security Levels (SL1–SL4) provide a framework for tiering requirements. SL1 covers protection against unintentional or casual violations; SL2 against intentional attack using simple means and generic skills; SL3 against attacks using sophisticated means and IACS-specific skills; SL4 against attacks with extensive resources, specialized skills, and high motivation. The capability requirements selected by E27 target primarily the SL2 level — a reasonable starting point that balances security effectiveness with engineering feasibility for most commercial vessel OT equipment.

The regulatory timeline also deserves attention. IMO adopted Resolution MSC.428(98) in June 2017, requiring shipping companies to address cyber risks in their Safety Management Systems by the first annual DOC audit after 1 January 2021 — that deadline has passed. BIMCO/ICS and partner organizations provided voluntary practical guidance in their Guidelines, 3rd edition, in late 2018. IACS UR E26 and E27 Rev.1 were published in September 2023 and entered into force for ships contracted on or after 1 July 2024: applicable to passenger ships, cargo ships ≥500 GT, high-speed craft ≥500 GT, and mobile offshore drilling units on international voyages. E27 specifically requires all CBSs to meet 30 security capabilities, with CBSs interfacing to untrusted networks subject to an additional 11 capabilities, all drawn from IEC 62443-3-3 and IEC 62443-4-1 (secure development lifecycle).

This regulatory arc reveals a two-tier reality: ships contracted after 1 July 2024 must satisfy the full E26/E27 requirements; the existing fleet (average age 22.2 years by vessel count) is bound only by the more principles-based IMO ISM cyber risk management requirement, with no mandatory verification of IEC 62443 capability levels. For much of the operational fleet, E27 compliance is therefore not a regulatory obligation but an incremental value proposition that equipment vendors can offer in the retrofit market and under service contracts.

"Air gap" is not a get-out-of-jail card

Industry's own guidance (BIMCO/ICS) is blunt: "even air-gapped systems can be compromised." One repeatedly documented case: a new dry-bulk ship was delayed sailing for days after its ECDIS (electronic chart system) was infected; designed for paperless navigation with no paper charts aboard, both ECDIS networks were hit — and the official conclusion on the infection vector was "unknown." USB sticks and maintenance laptops are the classic ways across an air gap.

For equipment vendors and yards: from "compliance project" to "product capability"

For equipment vendors, E27's arrival has changed something fundamental: cybersecurity has moved from a shipowner's or flag state's discretionary effort to an entry requirement for new-build projects. For applicable vessels contracted after 1 July 2024, every CBS must meet E27's 30 (plus 11) capability requirements, verified by a classification society. This means vendors' design, testing, and documentation processes must cover these capabilities from the outset — not as a last-minute patch applied by an integrator or yard before delivery.

In practice, working through E27's capability families against a device's interfaces is far more efficient than constructing a security architecture from scratch. Every CBS's E27 compliance path begins with a key question: does this device have an interface to an untrusted network? The answer determines whether 30 or 41 capability requirements apply, and which IEC 62443-3-3 system requirements must be mapped down to the device level. Vendors need not become cybersecurity generalists, but they do need to establish a verifiable internal capability-tracking process and be able to present a clear evidence chain to classification society auditors.

For shipyards, E26 defines cyber resilience requirements at the whole-ship level — including OT network segmentation architecture (Zones and Conduits), implementation of a Cyber Management System (CMS), and supply-chain security requirements. Vendors' E27 conformance is an important piece of the yard's E26 compliance puzzle. This creates an organic division of responsibility: vendors ensure product-level compliance, yards ensure system-integration-level compliance, shipowners ensure operational-management-level compliance. Any missing layer leaves the overall cyber resilience incomplete.

Which brings us back to where this article began. The essential difference between IT security and OT security is not a disagreement about technical detail — it is a fundamental difference in judgment about what consequences are most unacceptable. In an enterprise, the most unacceptable outcome is a data breach. At sea, the most unacceptable outcome is losing control of the vessel at the wrong time and place. The significance of E27 and IEC 62443 is that they translate "what matters most" into specific requirements that can be verified by engineering. The translation has already been done — the task for equipment vendors and yards is to use it.