Digital

IACS Cyber Resilience Explained

By Joshua Kantner · April 2026 · OceanSphere Consulting

Why Cyber Resilience Is More Than IT

The term cyber resilience is frequently equated with IT security in the maritime industry — firewalls, antivirus software, password strength. This falls short. Cyber resilience as understood by IACS encompasses the entire digital integrity of a vessel: bridge, automation, power supply, communication and every networked system relevant to safe operation.

The decisive difference lies in the approach. IT security focuses on prevention — blocking attacks, restricting access, encrypting data. Resilience goes further. It asks: what happens when prevention fails? How quickly do we detect a disruption? How do we contain the damage? How do we restore critical functions?

For a vessel at sea, this perspective is existential. An office network can be shut down and work offline for two days in an emergency. Navigation, machinery control and communication at sea cannot pause. When ECDIS fails, the alarm system stops communicating or the power management system is compromised, the consequences for vessel and crew safety are immediate.

IACS therefore deliberately chose the term resilience — not security. It concerns a system's ability to remain functional under adverse conditions or transition to a safe state in a controlled manner. This applies equally to hardware, software, networks, procedures and people.

The Objectives Behind It

The IACS Unified Requirements pursue three central objectives. First: address risks early. Cyber resilience should not be a retrofit but an integral part of design, procurement and integration. This means that as early as the specification of a newbuilding, the question must be asked: which Computer-Based Systems will be onboard, how are they networked, and what risks arise from this?

Second: clarify responsibilities. UR E26 defines the obligations of the shipowner, UR E27 those of the system suppliers. For the first time, it is regulatorily established who is responsible for which aspect of cyber resilience. This ends the previously common practice where cyber was a diffuse cross-cutting topic for which nobody felt concretely responsible.

Third: create a uniform minimum standard. Before UR E26/E27, there were recommendations — BIMCO Guidelines, IMO MSC-FAL.1/Circ.3 — but no binding requirements at classification level. Now all IACS member societies must implement the URs. This creates a global baseline on which operators, yards and OEMs can build.

Importantly, the URs do not define a specific technological level. They require a process — systematic risk assessment, traceable measures, documented procedures. This gives operators room for design but also demands genuine substance. Anyone presenting a generic Excel matrix will encounter resistance from class.

Free Initial Consultation Independent marine engineering consulting. We find a solution.
Contact

Why Resilience Goes Beyond Protection

The NIST Cybersecurity Framework, which IACS implicitly draws upon, defines five core functions: Identify, Protect, Detect, Respond, Recover. In maritime practice, the bulk of attention goes to Protect — installing firewalls, closing ports, banning USB sticks. This is necessary but not sufficient.

Detect means: recognising anomalies in the network before they escalate. In shipping this is harder than ashore because there are rarely dedicated security operations onboard. Who notices when a CBS suddenly sends traffic to an unknown IP address? In most cases, nobody — until it is too late.

Respond means: containing the incident. Which system is isolated? Who decides? Is there a contingency plan that is known onboard and regularly exercised? IMO required with MSC.428(98) that cyber risks be addressed in the SMS. In practice, many shipping companies ticked this off with a generic section in the SMS without concrete procedures for an actual event.

Recover is the most frequently neglected function. How is a compromised ECDIS restored? Are there verified backups? Does the crew know the fallback procedures? Is it documented in which sequence systems are brought up after a total failure? Resilience means: having a tested answer to all of these questions.

What Operators Should Take Away

Treat cyber as a permanent technical mandate — not as a one-off project that ends with delivery or the next audit. The regulatory landscape continues to evolve. IMO is working on a Maritime Cyber Risk Management Framework, the EU has tightened requirements for critical infrastructure with NIS2, and classification societies are continuously expanding their notation programmes.

For operators this means: those who build a solid foundation today invest in future readiness. It starts with a complete CBS inventory, continues through a realistic risk assessment and ends with tested recovery procedures. The key lies in integration — cyber management must not sit as an isolated topic alongside regular technical management but must be part of the same processes.

In practical terms: cyber topics belong on the agenda of every superintendent meeting, in checklists for vessel visits and in evaluation criteria for suppliers. Not as additional bureaucracy but as a natural part of technical due diligence.

Technical Deep-Dive: The Five Pillars of Onboard Resilience

Identify: every CBS onboard must be recorded — hardware, software version, network connection, manufacturer, maintenance responsible party. This sounds trivial but is in practice the greatest hurdle. Many vessels have systems installed retrospectively that appear in no network plan. A VSAT router here, a service laptop there, a diagnostic interface on the main engine that is permanently connected.

Protect: network segmentation, access control, operating system hardening, controlled update processes. Protection must be proportionate — a crew welfare system does not need the same protection level as the power management. The art lies in risk-appropriate gradation.

Detect: on vessels without dedicated security monitoring, detection capabilities are usually rudimentary. Realistic approaches for shipping include log aggregation on a central system, automated notifications upon configuration changes and regular plausibility checks of the network topology. High-end solutions such as SIEM systems are technically feasible but economically and in terms of personnel not sustainable on most vessels.

Respond: define clear escalation paths. Who is responsible onboard? When is the shipping company informed? Which systems are immediately isolated? The answers must be embedded in the SMS and regularly exercised — not only on paper.

Recover: backup strategies, verified restoration media, documented start-up sequences. Particularly important: recovery procedures must be tested. A backup that has never been verified is not a backup.

Case Context: Why Many Shipping Companies Are Still at the Beginning

The reality in many shipping companies looks like this: cyber is in the SMS but the operational substance is missing. The risk analysis was created by an external consultant who never saw the actual systems onboard. The network topology is not known to the superintendent in detail. Software updates are performed when the OEM technician comes aboard, without a documented procedure.

This is not an accusation — it reflects the fact that cyber resilience as a topic is still young in shipping. Most superintendents and technical managers grew up with mechanical and electrical systems, not network protocols. The learning curve is steep, and there is no established industry standard yet for what a maritime cyber organisation should concretely look like.

What is certain, however: requirements will not decrease. Those who start building substance now — CBS inventory, network documentation, tested procedures — are better positioned for the next regulatory steps than those who wait until class asks specific questions at the next survey.

Decision Framework: Where to Start?

Three priorities for operators aiming for maximum impact with limited resources: first, complete the CBS inventory — record every networked system with manufacturer, software version, network connection and maintenance status. Second, identify and control remote access points — this is the most common attack vector in practice. Third, walk through a realistic recovery scenario — for example: what do we do when ECDIS will not start and we are at sea?

These three steps cost little but create a solid foundation for everything that follows. And they demonstrate at every audit that the company treats cyber resilience not as a paper exercise but as an operational reality.

Key Takeaways

Related Articles

FAQ

Is it the same as cybersecurity?
Not exactly. Resilience also covers detection and recovery.
Why does this concern superintendents?
Because networked onboard technology falls directly within their scope of responsibility.
Biggest misconception?
Viewing cyber as a peripheral IT topic.

Ready for a solution?

Free initial consultation – we analyze your situation and find the best path forward.

Request Consulting