IACS UR E26/E27 in Practice: Turning Class Cyber Requirements Into Newbuild Engineering Deliverables

For any vessel contracted for construction on or after 1 July 2024, the IACS cyber resilience requirements are not guidance you might adopt. They are class requirements the ship has to satisfy to be classed at all, which makes them contractual the moment the shipbuilding contract is signed.

That single change of status is what most owners and yards have not fully absorbed. A recommendation you can defer. A class requirement you cannot, because the surveyor will not certify the ship without evidence it is met. And the evidence in question is not a policy binder written after delivery. It is engineering work — asset inventories, network diagrams, segmentation, tested controls — that has to be designed into the build and handed over as documentation at commissioning. Retrofitting segmentation and inventories into a delivered ship is an order of magnitude more expensive than specifying them into the newbuild. This post is about doing the second thing.

What E26 and E27 actually divide between them

The two Unified Requirements operate at different levels, and confusing them is the first mistake. UR E26, “Cyber resilience of ships”, is the vessel-level requirement: it treats the ship as a system of systems and asks that the integrated whole is resilient. UR E27, “Cyber resilience of on-board systems and equipment”, is the equipment-level requirement: it applies to each individual computer-based system that goes aboard. E26 Rev.1 was adopted in November 2023 and E27 Rev.1 in September 2023; the revised versions apply to ships contracted from 1 July 2024, and the earlier versions were withdrawn to avoid confusion.

The practical consequence is that responsibility is split. E27 is largely a supplier obligation — the maker of a specific control system, engine management unit or navigation package has to demonstrate their box meets the security capabilities. E26 is an integration obligation that lands on the yard and, ultimately, the owner: taking compliant components and assembling them into a vessel whose networks, zones and recovery arrangements hang together. A ship full of individually E27-compliant equipment wired into a flat, unsegmented network does not meet E26. The requirements have to be worked as a pair.

The five functions, read as build deliverables

E26 is structured around five functional elements — identify, protect, detect, respond and recover — the same spine as most modern cyber frameworks. That structure is useful only if you read each function as a thing the yard has to build and evidence, not as a heading in a manual.

• Identify becomes a computer-based system asset inventory: every in-scope system listed with maker, model, firmware version, the network it sits on and what it connects to. This is the foundational artefact — nothing downstream can be assured if you cannot enumerate what is aboard.
• Protect becomes security zones and network segmentation, access control, and malware protection — the architecture that keeps a compromise in one zone from propagating to the whole ship.
• Detect becomes monitoring and diagnostic capability on the networks that matter, so an anomaly is visible rather than silent.
• Respond becomes documented incident procedures plus the engineered ability to isolate a network segment and fall back to manual or local control of essential functions.
• Recover becomes backup and restore arrangements and controlled shutdown or recovery procedures for the systems whose loss would be safety-critical.

Each of those is a specification line the newbuild contract can carry, an acceptance test at commissioning, and a document in the handover pack. If your build specification does not name them, the yard will build to the cheapest reading of the requirement and you will discover the gap at survey. This is the same discipline of translating a legal obligation into concrete engineering work that we have written about in a non-maritime context; the pattern travels.

Segmentation is a wiring decision, not a policy

The item that most often gets deferred, and most punishes deferral, is network segmentation. E26 expects the ship’s networks to be organised into security zones with controlled connections between them, so that IT, operational technology and crew or passenger internet access are separated rather than sharing one flat network. Whether a given boundary is enforced logically, with VLANs and firewalls, or physically, with genuinely separate cabling, is an engineering judgement that turns on the severity of a compromise — there is a strong case for physical separation where the impact of a breach reaches propulsion, steering or power management.

The point for the newbuild is that this is decided in the cable plan and the network topology drawing, at design stage. You cannot meaningfully re-zone a delivered ship without touching cabling, switch configuration and integration testing across systems that are already commissioned and signed off. Get the zone model into the design review, get the topology diagram approved by class, and make the segregation evidence a named deliverable. Leave it to a policy document and you have written down an intention the physical ship does not honour.

What the equipment suppliers owe, under E27

E27 is where the maker’s package earns its place aboard. For each in-scope computer-based system the supplier is expected to provide the documentation that lets class and the integrator assure it: a system asset inventory, topology diagrams, a description of the security capabilities and how to test them, security configuration guidelines, secure-development-lifecycle evidence, maintenance and verification plans, information supporting incident response and recovery, a management-of-change process and test reports. The security capabilities themselves draw on the IEC 62443 family, graded into security profiles, with a defined minimum profile required for in-scope equipment and compensating measures where a legacy or constrained device cannot meet a specific capability.

Read that list as procurement language. If your equipment purchase orders do not require the E27 documentation set as a deliverable, you are trusting each maker to supply it out of goodwill, and some will hand you a datasheet and a compliance claim instead. The moment to demand vulnerability disclosure arrangements, update mechanisms and end-of-life declarations is in the purchase order, which is exactly the posture we argue owners should take on class cyber notation more broadly.

The acceptance evidence to hold at delivery

E26 requires a ship cyber resilience test procedure that runs across construction, commissioning and the survey cycle, not a one-off box-tick at handover. So the question to answer before you accept the vessel is: can you produce, on the day, the initial computer-based system asset inventory, the class-approved network architecture and segregation evidence, the security capability test reports, the recovery and backup arrangements, and the per-system E27 documentation for the equipment aboard. If all of that is in the handover pack and internally consistent, the ship is defensible. If the inventory does not match the topology drawing, or the topology drawing does not match the cabling, you have stated compliance without operating compliance — and the gap becomes yours to close in service, at anchor, at the worst possible cost.

None of this is exotic. It is ordinary systems engineering, done at the stage where it is cheap, against requirements that are now contractual rather than optional. The owners who treat E26 and E27 as a design input to the newbuild get a resilient ship and a clean survey. The ones who treat them as paperwork to be assembled after delivery get a flat network, a mismatched inventory, and an invoice for putting right on the water what should have been settled in the yard.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.