[Ship OT Security] Why is ship OT security so different from IT security?

— Why E26/E27 Had to Emerge

“Isn’t security just about installing a firewall?”

This is often the first question that arises when people encounter shipboard OT security for the first time.
Organizations with strong IT security experience tend to ask this question even more frequently.

  • Install a firewall

  • Deploy antivirus software

  • Apply patches on a regular basis

At first glance, this feels like sufficient security.

However, in the context of shipboard OT security, this approach almost always fails.
The reason is simple.

A ship is not an IT system.
It is a physically operating system.


The Top Priority of Shipboard OT Security Is Not Confidentiality

In IT security, the fundamental triad is CIA:

  • Confidentiality

  • Integrity

  • Availability

In typical IT environments, this order makes sense.

In shipboard OT environments, however, the order is completely reversed.

The highest priority in shipboard OT security is
Availability — the ability to continue safe operation at this very moment.

Consider the following systems:

  • Engine control systems

  • Ballast systems

  • AMS / PMS

  • ECDIS

If any one of these systems is stopped or delayed due to a security measure,
the result is not a “cyber incident,”
but an immediate operational incident.

For this reason, on board a ship,
“stopping a system for the sake of security” is not a viable option.

An Environment Where Patching Is Not the Answer

In IT security, patching is almost an absolute solution.
When a vulnerability is discovered, a patch is applied.

But in shipboard OT environments, the situation is very different.

  • Re-validation is required after patching

  • Class approval may be necessary

  • There is a risk of operational interruption

  • Equipment manufacturer responsibility must be considered

This is why, in practice, one often hears the following statement:

“The patch server is currently under review.”

This does not mean that security is being neglected.
In fact, it means the opposite.

👉 It reflects uncertainty about how a single patch might affect the operation of the entire vessel.

In shipboard OT security,
how risk is controlled when patches cannot be applied
often becomes more important than whether patches are applied at all.

At this point, traditional IT security frameworks begin to show their limitations.

Ships Are Not Systems Designed for 3–5 Years of Use

IT systems are typically designed around assumptions such as:

  • Replacement cycles of 3–5 years

  • Continuous updates

  • Always-on connectivity

Ships operate under entirely different conditions:

  • Operational lifespans of 20–30 years

  • Coexistence of legacy equipment

  • Offline or hybrid network environments

  • Global, continuously changing operational contexts

As a result, shipboard OT security cannot be designed under the assumption of a
“perfectly up-to-date” system.

This means the core question must change.

❌ “Is this system running the latest security updates?”
⭕ “Is this system safely controlled in its current state?”

Why Classification Societies Are Involved in Cyber Security

Given this environment, a natural question arises:

“Shouldn’t each company manage its own security?”

However, a ship is simultaneously:

  • A private asset

  • An internationally operating asset

  • A system directly tied to public safety

For this reason, cyber security on board ships must be treated as part of safety, not merely IT protection.

This is precisely the context in which E26 and E27 emerged.

E26/E27 Are Not “Security Solution Requirements”

Many misunderstandings begin here.

If E26/E27 are interpreted as:

  • Firewall requirements

  • Mandatory security equipment lists

confusion is almost inevitable.

The true nature of E26/E27 is fundamentally different.

E26/E27 require stakeholders to explain, as a single structure:

  • Design

  • Construction

  • Operation

  • Audit

They ask:

  • What does this vessel’s OT architecture look like?

  • Where can risks arise?

  • Who is responsible for what?

  • How is risk managed when patching is not feasible?

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

This is why the SCARP is less a “security plan” and more
an explanation of how the vessel can be operated safely.

Shipboard OT Security Is a Structural Issue, Not a Technical One

Across real projects, the same failure patterns appear repeatedly:

  • Technology is deployed, but responsibilities are unclear

  • Documentation passes review, but no one uses it during operation

  • Patches are needed, but no one knows who is authorized to decide

These are not failures of security technology.
They are failures of structural design.

For this reason, shipboard OT security cannot be handled by an IT department alone,
nor can it be solved by a single organization acting in isolation.

Comments

Post a Comment