UR E26 Cyber Compliance: CBS Categorization Issue

Introduction

Several years after signing a newbuilding contract, the day of vessel delivery finally arrives. Class certificates are issued, the yard is satisfied, and the Owner takes over the vessel.

From that moment on, all cyber risks the vessel encounters at sea ultimately reside with the Owner.

This obvious fact often becomes blurred in practice. During UR E26 (IACS Unified Requirement for Cyber Resilience) projects — where suppliers, shipyards, classification societies, and consultants exchange documents — the Owner’s visibility as the final acceptor can narrow.

This note summarizes a few key points that may be useful for management and project teams, with technical jargon kept to a minimum.

1. “Our system is not in scope” — A common flawed assumption

UR E26 defines Cyber-enabled Systems (CBS) as the scope of regulation.

A frequent issue in practice is that suppliers claim “our system is not CBS” based on incorrect assumptions.

A common argument:

“Our equipment is not connected to any network, so it is not in scope.”

This assumption does not align with the intent of UR E26.
The rule does not focus solely on network connectivity, but rather on whether the system:

• has software-based functionality,
• processes data or interacts with external entities, and
• could impact vessel safety or operation as a result.

“Data flow” in this context does not only mean permanent network connections. Even without continuous connectivity, if data moves between systems via removable media — such as USB devices — as part of operational or maintenance processes (e.g., chart updates, firmware patches, log extraction, parameter backup), such pathways may fall within the assessment scope.

That said, the presence of USB or removable media alone does not automatically make a system a CBS.
However, if such pathways are linked to operation, maintenance, or configuration changes, they become significant factors in CBS determination.

Similarly, even without any network cable, a system that allows firmware updates or parameter changes may still fall under CBS.

In simple terms:

“If this system were compromised, could it affect vessel safety, operation, or critical functions?”

2. Three recurring misconceptions in practice

Recognizing these patterns in advance helps steer review meetings in the right direction.

Misconception 1 — “Category 1 systems can be ignored”
Even low-risk (Category 1) equipment may require reassessment if it is connected to higher-category systems or frequently operated. Recent discussions on rule development have also highlighted the potential need for one-way communication devices (e.g., data diodes) in such configurations.

Misconception 2 — “Filling Yes/No in a table is sufficient”
A common format preferred by suppliers and system integrators is to submit equipment lists with only a “CBS: Yes/No” column. In many cases, this leads to comments from Class. Supporting evidence — such as drawings, internal photos, manuals, and certificates — greatly improves the review process.

Misconception 3 — “No need to look inside panels”
It is not uncommon to find PLCs inside panels where suppliers initially claimed none existed. Likewise, even a single USB port creates a data entry/exit point. Securing internal panel photos along with external interface details can significantly reduce future disputes.

3. Three questions to ask your team

To understand the status of CBS classification, the following three-step questioning approach is effective:

Step 1 — “Is this system within the regulatory scope?”
If the system has no relevance to safety-related functions, the discussion may end here.

Step 2 — “If in scope, is it classified as CBS?”
Does it include programmable elements?
Does it process data?
Does it have external interfaces?
Can firmware be updated or parameters modified?
What data flows exist during operation and maintenance?

If any of these apply, the system is likely to be considered CBS.

Step 3 — “If it is CBS, how are UR E26 security requirements addressed? What remains unmanaged?”
Any unmet requirement becomes residual risk.
It is important that the Owner understands not just the existence, but also the nature and level of these risks.

4. Looking behind the numbers

One area frequently challenged by Class is when assumptions appear to be adjusted to lower risk scores.

For example, if a system that is operated multiple times per day is marked as “low usage frequency,” the calculation may look correct, but the underlying assumption is questionable.

The key check is simple:

Do the numbers reflect reality?

Asking “why this value?” often reveals whether reassessment is needed.

5. Where the final acceptance sits

This is one of the most commonly blurred areas in UR E26 practice.

• Class defines minimum requirements and verifies compliance.
• SI, suppliers, and consultants provide interpretations and technical solutions.
• Final acceptance (often managed as Definition of Acceptance, DOA, depending on the project) structurally remains with the Owner.

In other words:

The decision to accept or mitigate residual risk ultimately belongs to the Owner.

Furthermore, after delivery, beyond technical compliance,
operational liability typically resides with the Owner.

In practice, when an SI says “it’s fine, Class has approved it,” projects often proceed without further challenge. However, this is worth reconsidering:

• In the event of a cyber incident, the key question becomes: who accepted the risk?
• Depending on the contract structure, post-delivery risks generally remain with the Owner.
• “We relied on expert judgment” is often insufficient in dispute scenarios.

Therefore, it is critical that Owner-side acceptance of residual risks is explicitly documented.

Monday Morning Checklist — Six minimum questions to ask

1. Who prepared the CBS list, and does it include internal panel verification (photos)?
2. Have Category 1 systems been re-evaluated based on connectivity?
3. Have non-networked systems been assessed for data flows via removable media (e.g., USB)?
4. Is there documented justification and evidence for each “non-CBS” classification?
5. Is Owner acceptance of each residual risk formally documented?
6. Are CBS systems clearly mapped within the network diagram, including defined zones and conduits?

If these six questions can be answered clearly, the project is likely well under control.

Closing Remarks

UR E26 is still evolving in terms of interpretation and application.
Decisions made in current projects are likely to shape future industry practices.

How the Owner understands cyber risks, makes decisions, and documents those decisions will significantly influence the post-delivery risk position.

The one who takes the vessel, and the one who signs last, is ultimately the Owner.