Ship cyber security: which rules actually apply to your vessel?

Ask a shipowner “where are you on cyber security compliance?” and the answer usually points at one thing. But there is no single rule here. There are two regimes with different scope, different dates and different binding force — and they are constantly conflated.

The first is the class side: the International Association of Classification Societies’ Unified Requirements E26 and E27. The second is the safety-management side: IMO Resolution MSC.428(98) and its relationship to the ISM Code. The first imposes technical conditions on a specific set of ships; the second places a management expectation on the whole fleet. Spend money without knowing the difference and it either goes to the wrong ship or answers the wrong question.

This guide separates them: which rule reaches your vessel, from what date, asking for what.

Scope note. This is an independent guide. It is not a publication of IACS, the IMO or any classification society and carries no endorsement from them. It does not replace the rule texts. Where they conflict, the current documentation of your ship’s classification society and flag state governs.

Start with the split: date, not fleet

The decision tree is simpler than expected. It begins with one question: when was the ship’s construction contract signed?

	Contract before 1 Jul 2024	Contract on or after 1 Jul 2024
IACS E26 / E27	Not in mandatory scope	Mandatory — class verification before delivery
IMO MSC.428(98) / ISM	In scope (with the nuance below)	In scope
Practical starting point	Safety management system	Newbuild contract and supply chain

The overwhelming majority of the fleet in the water today sits in the first column. That does not mean “cyber security does not concern us” — it means the place it concerns you is the safety management system, not the class survey. Putting budget and attention in the wrong column is the most common error we see.

The IACS side: what E26 and E27 actually ask for

Since 1 July 2024, E26 and E27 have applied to ships whose construction contract was signed on or after that date. Scope covers commercial and offshore vessels of 500 gross tonnage and above, passenger ships carrying more than 12 passengers, and self-propelled mobile offshore units. Smaller and non-conventional craft were deliberately left outside the mandatory core.

The two rules split the problem on purpose.

E26 — the ship as one system. The rule treats the vessel as a collective whole rather than a sum of components, and builds a minimum baseline around five functions: identification, protection, attack detection, response and recovery. That set is the same structure underpinning the NIST and IEC 62443 frameworks — IACS did not invent something maritime-specific here; it adapted a scaffold that had settled in land industry. The aim is the secure integration of IT and OT (operational technology) systems across design, construction, commissioning and the operational life of the ship.

In practice this means “we bought a firewall” is no longer an answer. Each of the five functions has to be separately demonstrable: an inventory of what systems are on board (identification), network segregation and access control (protection), noticing abnormal behaviour (detection), who does what during an incident (response), and the ability to return the system to a known good state (recovery).

E27 — the supplier gate. E27 works one level down, targeting computer-based systems and equipment supplied by third parties. The demand is explicit: security must be embedded in the design before the product is installed on board. This is the least-discussed part of the rules and the one that creates the most work on the procurement side.

E27’s real effect is contractual rather than technical. An owner buying equipment for a newbuild now has to demand evidence of cyber resilience alongside performance — and if that is not written into the supply contract, the owner has quietly taken the problem onto their own books by the time of delivery.

The real change: accountability is now shared

The most durable effect of E26/E27 is not in the technical control list but in the chain of accountability. Cyber resilience is no longer one party’s job:

• the yard has to integrate systems securely,
• the equipment supplier has to ship hardened products under E27,
• the operator has to run and maintain them.

Every link now carries a documented, auditable obligation rather than an informal expectation. That changes where non-compliance shows up: the problem usually appears not in the absence of a control, but in the absence of a contract clause saying who owns it.

The IMO side: the widespread misreading of MSC.428(98)

This needs care, because it is the most-repeated piece of wrong information in the field.

MSC.428(98) was adopted at the 98th session of the IMO Maritime Safety Committee on 16 June 2017. What it asks for is that cyber risks be appropriately addressed in safety management systems as defined in the ISM Code, and that this happen no later than the first annual Document of Compliance verification after 1 January 2021.

The common retelling stops there and summarises it as “cyber security became mandatory on 1 January 2021.” The text itself is softer than that: the resolution encourages administrations — flag states — to ensure this. The binding force therefore comes not from the resolution but from how the flag state applies it, and from class and port-state control practice.

Why does the nuance matter? Because it produces two different mistakes. The first is deciding “it isn’t mandatory then” and dropping the subject — while flag-state and inspection practice have in fact filled that gap. The second is mistaking the resolution for a technical standard — whereas MSC.428(98) does not tell you which firewall to install; it asks you to treat cyber risk the way you already treat every other risk in your safety management system. The demand is managerial, not technical.

For the existing fleet: not mandatory, but not a gap either

Ships contracted before 1 July 2024 are outside the mandatory scope of E26/E27. Class societies and the advisory side strongly recommend applying them to these vessels anyway — but a recommendation is not a class condition and should not be budgeted as one.

A realistic order for an existing-fleet owner:

1. Start with the safety management system. That is where the obligation line runs. How cyber risk is handled in the SMS is something that can be asked at a DoC verification.
2. Build the inventory. Which computer-based systems are on board, which of them touch a critical bridge or engine-room function, which exchange data with shore. This step serves both the SMS side and E26’s first function — it pays for itself twice.
3. Map remote access. How service providers, suppliers and technical management connect to the ship is undocumented on most fleets. Undocumented access is unmanaged access.
4. Use E26’s five functions as a maturity scale. Even where it is not mandatory, identify–protect–detect–respond–recover is a useful self-assessment scaffold for an existing ship. It is the cheap way to find out where you stand.
5. Write it into newbuild and major-conversion contracts now. The next order will fall in scope. Positioning supplier obligations at contract stage is always cheaper than arguing about them at delivery.

A note on smaller tonnage

The 500 gross tonnage threshold leaves part of a coaster-weighted or small-tonnage fleet outside mandatory scope. That looks like an exemption, but charterer and inspection expectations are shaped by the risk of the trade rather than by the class threshold — being out of scope does not mean being out of the question.

Summary

• E26/E27 apply only to ships above 500 GT whose construction contract was signed on or after 1 July 2024. The existing fleet is not in mandatory scope.
• E26 treats the ship as a whole (identify–protect–detect–respond–recover); E27 targets supplier equipment and requires security to be designed in.
• MSC.428(98), adopted in 2017, expects cyber risk to enter the safety management system by the first DoC verification after 1 January 2021 — as an encouragement addressed to administrations rather than a mandate. Its binding force is set by flag-state practice.
• For the existing fleet the right starting point is not class but the safety management system and a systems inventory.

Cyber security regulation is repeating a pattern the industry knows well: a good practice becomes an expectation, then an audit item. A control you cannot document is, to an inspector, a control that does not exist — and that holds regardless of which regime you fall under.