🔬 R&D Ship OT Security IACS UR E26/E27 IT vs OT

[IACS E26/E27]  Why Is Ship OT Security So Different from IT Security? — And Why IACS UR E26/E27 Had to Emerge

A structural analysis of why traditional IT security frameworks fail on ships — and how IACS UR E26/E27 redefine cybersecurity as a safety-critical, operationally-aware discipline for the maritime domain

Captain Ethan

Maritime 4.0 · AI, Data & Cyber Security
LinkedIn : linkedin.com/in/shipjobs

"Isn't security just about installing a firewall?"

This is the first question that arises when IT security professionals encounter shipboard OT security for the first time. It sounds reasonable — but in the context of a vessel underway, it almost always leads to the wrong conclusion. A ship is not an IT system. It is a physically operating system. And that single distinction changes everything about how cybersecurity must be designed, implemented, and governed.

---

🔄 1. The Priority Order Is Reversed — AIC, Not CIA

📌 Why is this important?
In IT security, the fundamental triad is CIA: Confidentiality → Integrity → Availability. Protecting data confidentiality comes first. In shipboard OT environments, this order is completely reversed. If any critical system stops — even briefly — the result is not a "cyber incident." It is an immediate operational and safety incident.

IT CIA vs Ship OT AIC — Priority Comparison

Priority	IT Security (CIA)	Ship OT Security (AIC)
1st	Confidentiality — protect data	Availability — keep the ship running
2nd	Integrity — data accuracy	Integrity — sensor/control data trustworthiness
3rd	Availability — system uptime	Confidentiality — voyage / cargo data protection

⚠️ Systems Where Availability = Safety

⚙️ Engine Control System 🚢 Ballast Control 🗺️ ECDIS 🔋 AMS / PMS 🧯 Fire Detection System 📡 GMDSS

---

🩹 2. An Environment Where Patching Is Not Simply "the Answer"

📌 Why is this important?
In IT security, patching is the first and most reliable response to a vulnerability. When a CVE is published, the patch goes out within days or weeks. In shipboard OT environments, applying a patch is never a simple operation — it involves classification society oversight, vendor re-validation, and the risk of operational disruption to safety-critical systems mid-voyage.

✅ Why Patching on Ships Is Structurally Different

• Re-validation required after patching — OT systems must be functionally re-tested before returning to operational status.
• Class approval may be necessary — software changes to type-approved equipment can trigger a new certification review.
• Risk of operational interruption — an unexpected behavior after patching while at sea can become a safety incident.
• Vendor responsibility — unauthorized patches can void manufacturer warranties and maintenance agreements.

💬 "The patch server is currently under review."

This is not negligence. It reflects the real uncertainty of how a single update might affect the entire vessel's operational chain. In shipboard OT security, how risk is controlled when patches cannot be applied often becomes more critical than whether patches are applied at all.

🔬 Compensating Controls When Patching Is Not Feasible

• Network segmentation — isolate vulnerable systems from crew and IT networks (UR E26)
• Application whitelisting — only approved processes can run on OT controllers
• Port disable / service restriction — close unused ports and services at firewall level
• Anomaly detection / IDS — detect exploit attempts without modifying the system itself
• Documented risk acceptance — formally record the unpatched state and the mitigating controls in place (UR E27 §6)

---

⏳ 3. Ships Are Not Designed for a 3–5 Year Lifecycle

📌 Why is this important?
IT hardware is designed around 3–5 year replacement cycles with continuous updates and always-on connectivity. Ships operate under completely different constraints — a vessel commissioned in 2010 with a 25-year operational lifespan will be running the same OT equipment in 2035. The security model must account for this reality from day one.

IT Environment vs Ship OT Environment

Dimension	IT Systems	Ship OT Systems
Lifespan	3–5 years	20–30 years
Updates	Continuous, automated	Controlled, infrequent, vendor-managed
Connectivity	Always-on, high bandwidth	Offline / hybrid, satellite-dependent
Legacy Coexistence	Rare — systems replaced regularly	Routine — 10–15 year old systems active
Failure Consequence	Data loss / service outage	Loss of propulsion / navigational hazard

✅ The Core Question Must Change

❌ IT Mindset

"Is this system running the latest security updates?"

✅ OT Mindset

"Is this system safely controlled in its current state?"

---

⚓ 4. Why Classification Societies Are Involved in Cybersecurity

📌 Why is this important?
"Shouldn't each company manage its own security?" — A reasonable question. But a ship is simultaneously a private asset, an internationally operating asset, and a system directly tied to public safety. When the safety consequences of a cyber failure can affect crew lives, marine environments, and port communities, security cannot remain a purely private decision.

✅ The Multi-Party Nature of Shipboard Cyber Risk

• A cyber incident at sea may threaten crew safety (loss of engine control, fire suppression failure)
• It may impact port state operations (AIS spoofing, LRIT manipulation, false arrival notifications)
• It may compromise cargo integrity (manipulated stowage plans, falsified dangerous goods declarations)
• It can trigger environmental incidents (ballast system compromise, fuel management manipulation)

🔍 Real-World Reference: The 2017 NotPetya attack on A.P. Møller-Maersk infected 45,000 PCs and 4,000 servers across 76 ports — causing ~$300M in losses and demonstrating exactly how IT/OT cyber failures cascade across global maritime logistics chains.

---

📋 5. E26/E27 Are Not "Security Solution Requirements"

📌 Why is this important?
The most common misunderstanding: interpreting UR E26/E27 as a list of "required security products to install." They are not. These rules ask stakeholders to explain the entire cyber posture of a vessel as a coherent structure — not just what tools are deployed, but who is responsible, where risks exist, and how those risks are governed under operational constraints.

✅ What E26/E27 Actually Ask

• What does this vessel's OT architecture look like? — Asset inventory, network topology, security zone map
• Where can risks arise? — Threat modeling, attack surface analysis, interface enumeration
• Who is responsible for what? — Shipowner, shipyard, equipment supplier roles clearly delineated
• How is risk managed when patching is not feasible? — Compensating controls, documented risk acceptance, review cycles

🔬 SCARP — Structure Before Technology

The Ship Cyber Assessment and Risk Plan (SCARP) required under UR E26 is less a "security plan" and more an explanation of how the vessel can be operated safely under cyber risk conditions — covering design intent, residual risks, and operational procedures.

In other words: these rules ask about structure before they ask about technology.

---

🏗️ 6. Shipboard OT Security Is a Structural Issue, Not a Technical One

📌 Why is this important?
Across real maritime projects, the same failure patterns appear repeatedly — not because the technology is insufficient, but because structural responsibilities are unclear. When security fails on a ship, it is almost always a governance failure before it is a technical failure.

⚠️ Recurring Failure Patterns in Maritime Cyber Projects

• Technology deployed, but responsibilities are unclear — firewall installed, but nobody manages the rule set or reviews logs.
• Documentation passes review, but no one uses it during operation — SCARP filed with class, never referenced by crew or DPA.
• Patches needed, but no one knows who is authorized to decide — vulnerability known, but the decision chain between shipowner, ISM manager, and vendor is undefined.
• Vendor equipment assumes connectivity that doesn't exist — remote update mechanisms designed for shore-side use fail at sea without satellite link.

✅ What Structural Security Requires

• Defined roles across the entire lifecycle — shipyard, equipment supplier, shipowner, ship operator, DPA each have documented responsibilities.
• Operational procedures, not just technical controls — who acts, when, and how when a cyber incident occurs at sea.
• Cross-organizational coordination — shipboard OT security cannot be handled by an IT department alone, nor solved by a single organization in isolation.

---

🔬 Research Summary — Why IACS UR E26/E27 Had to Emerge

The gap between IT security assumptions and ship OT realities is not a technical problem — it is a fundamental mismatch of priorities, lifecycles, and governance models. IACS UR E26/E27 emerged precisely to close this gap.

• Ship OT security prioritizes Availability over Confidentiality — the opposite of IT's CIA triad.
• Patching on ships requires structural governance, not just a maintenance window — compensating controls fill the gap.
• 20–30 year system lifecycles demand security architectures designed for "safely controlled now", not "always up to date."
• E26/E27 ask about structure before technology — who is responsible, where the risk is, and how it is governed operationally.
• Maritime cyber failures are almost always governance failures first — technology alone cannot solve structural problems.

#MaritimeCybersecurity #ShipOTSecurity #IACSE26 #IACSE27 #OTSecurity #CyberResilience #Maritime40 #ITvsOT #ShipSecurity

Captain Ethan

Maritime 4.0 · AI, Data & Cyber Security

Maritime professional focused on the intersection of vessel operations, classification society regulations, and OT/IT cybersecurity. Writing for engineers, consultants, and operators navigating Maritime 4.0 together.

LinkedIn More Articles