IACS UR E27: Systems and Suppliers

6 min read

What you'll take away Explain what IACS UR E27 requires at the equipment level, what suppliers and integrators must demonstrate, and why the rules split ship-level and system-level responsibility.

Lesson 2 left us with a problem. UR E26 demands a cyber-resilient ship, and holds the yard and the owner to it. But walk through any engine control room and count the makers' plates: automation from one supplier, power management from another, navigation from a third, dozens more behind them. The yard integrates these boxes; it does not build them, and it cannot reach inside a supplier's controller to fix what was never designed in. A rule aimed only at the ship would be a rule aimed at the one party unable to comply with it.

So IACS wrote a second rule. UR E27, "Cyber resilience of on-board systems and equipment" (Rev.1, September 2023), applies to the computer-based systems that go into ships, and it lands on the people who make and integrate them. Like E26, it bites through the newbuilding process for ships contracted for construction on or after 1 July 2024, for the same ship types E26 covers: from that point, a supplier's system arrives at the yard with security obligations attached, the way machinery has long arrived with type approval.

What a supplier must demonstrate

E27's core is a defined set of security capabilities that a computer-based system must possess: things like controlling who can log in and what they may do, keeping security logs, resisting malformed network traffic, and being deliverable secure by default, hardened, least-privilege, rather than with every port open and a default password taped to the cabinet. The list is not a maritime invention: it is adapted from IEC 62443, the established security standard family for industrial automation and control systems, so a supplier serving factories and power plants meets shipping on familiar ground.

The capabilities alone are not enough; they must be demonstrated. The supplier's deliverables to the yard and the class society include documentation of which security capabilities the system provides, evidence that they were tested, and guidance for configuring the system securely in service. ClassNK's Guidelines for Cyber Resilience of On-board Systems and Equipment lay this out in the open, what the documentation must contain, how testing is evidenced, and how the equipment-level file feeds the ship-level case that E26 requires.

The integrator, usually the yard, carries the complementary duty: combining those systems into the ship's zone architecture and showing that the capabilities survive integration. A supplier can certify its own box; only the integrator can certify the assembly.

Why the split exists

The two-rule structure mirrors how responsibility actually runs, and it is worth stating plainly, because the same logic governs who you chase when something is wrong:

  • The supplier controls the inside of the product. Only the supplier can build in authentication, logging, and robustness, so E27 puts those obligations there.
  • The yard and owner control the ship: which systems are aboard, in which zones, connected how, with what fallbacks. E26 puts those obligations there.
UR E26: the ship yard and owner Inventory · security zones · conduits · fallback to local control Integration test: do the capabilities survive assembly? the supplier's deliverables: capabilities, test evidence, hardening guidance UR E27: the supplier's system maker, to IEC 62443 access control security logging robust to bad traffic secure by default Two rules, two parties: hardened boxes and a resilient ship only produce resilience together.
The rules stack rather than overlap: E27 puts security capabilities inside each supplier's box and demands the evidence for them, while E26 arranges the hardened boxes into zones with fallbacks. The capability chips shown are examples of the E27 list, not the whole of it.

Neither party can discharge the other's duty. A perfectly segmented ship built from insecure boxes is a set of well-separated weaknesses; a ship full of hardened equipment wired into one flat network throws the suppliers' work away. The two rules only produce a resilient ship together, which is why they share an application date and a survey regime.

What this means at the office

For operators, E27 quietly changes procurement. The questions to a maker proposing new networked equipment, a retrofitted performance monitor, an upgraded automation node, now have a standard shape: show me the security capabilities, the test evidence, and the secure-configuration guidance. A maker who cannot produce them is offering the pre-E27 world, and the gap becomes yours at the next survey or the next incident. Patching and update support deserve contractual attention too: security capabilities age, and a box nobody will ever update is a capability with an expiry date. For the reasoning underneath these requirements, IACS Recommendation 166 remains the consolidated reference the unified requirements grew from.

With the ship built resilient and its equipment demonstrably hardened, the remaining variable is the one that was always going to matter most: how the ship is actually run. That is the next lesson: cyber security as a shipboard discipline, drills included.

Check yourself

1. At what level does UR E27 set its requirements?
2. Why can't the shipyard simply take responsibility for the security of every system on board?
3. Where do E27's required security capabilities chiefly come from?
4. What is 'secure by default' asking of a supplier's product?
5. During construction, what is the integrator's distinctive E27-era responsibility?
6. What should a superintendent ask for when a maker proposes new networked equipment for a ship in service?
7. Which of these must a supplier provide with a computer-based system under the E27 regime?

Select all that apply.

8. E26 and E27 overlap so much that complying with one automatically satisfies the other.

One email a month, at most

New courses, new articles and the occasional sea curiosity, in a single email. A quiet month means no email at all. Nothing is sent until you confirm your address, and one click unsubscribes you from anything we send.