IACS UR E26 and E27 set complementary cyber-resilience requirements for certain new ships and their on-board systems. This guide explains their scope, responsibilities, evidence and relationship with IMO guidance, NIST CSF 2.0, IEC 62443 and NIS 2.
What changed from 1 July 2024
The International Association of Classification Societies (IACS) applies the revised versions of its Unified Requirements UR E26 and UR E27 to ships contracted for construction on or after 1 July 2024. The original versions were withdrawn before they took effect.
These are IACS Unified Requirements, not EU legislation. They establish complementary classification requirements:
- UR E26 addresses cyber resilience at ship level.
- UR E27 sets minimum cyber-resilience requirements for on-board systems and equipment identified through E26.
The stated mandatory scope includes passenger ships on international voyages, cargo ships and high-speed craft of 500 GT and above on international voyages, mobile offshore drilling units of 500 GT and above, and specified self-propelled mobile offshore construction units. Other vessel categories listed in the requirements may use them as non-mandatory guidance. The detailed scope should therefore be checked against the relevant UR and the ship's classification arrangements.
How E26 and E27 work together
E26 treats the ship as a collective entity. It covers in-scope operational technology systems and specified interfaces, and frames cyber resilience through five functional elements:
- Identify
- Protect
- Detect
- Respond
- Recover
E27 works at the level of the computer-based systems and equipment identified through E26. It addresses the security capabilities of those systems, the supplier information needed to assess them, and the evidence used to demonstrate conformity.
In practical terms, E26 establishes the ship-level context: which assets, systems, connections and cyber risks matter to the vessel. E27 then supports the assessment of the individual on-board systems within that context.
Responsibilities across the project
Cyber resilience is not solely a shipowner or supplier task. E26 allocates work across several parties, while responsibility for fulfilling an individual requirement lies with the stakeholder contracted with the classification society.
| Party | Typical contribution under the requirements |
|---|---|
| Owner or company | Provides ship-level operational context and participates in the ship cyber-security and resilience programme. |
| Shipyard or system integrator | Integrates systems, interfaces and ship-level cyber-resilience design evidence. |
| Supplier | Provides system documentation, security-capability evidence, configuration information and secure-development-lifecycle evidence required by E27. |
| Classification society | Reviews and surveys the applicable evidence and activities under the classification process. |
Clear contractual allocation matters because the required evidence is created across design, construction, commissioning and operation. A checklist completed at one point in time does not replace the lifecycle activities specified by the requirements.
What evidence E26 requires
E26 requires controlled ship-level evidence appropriate to the project phase. This includes:
- an asset inventory;
- zone and conduit information;
- a cyber-security design description;
- test procedures and related test evidence; and
- a ship cyber-security and resilience programme.
Zones and conduits are used to describe segmentation and communication paths between systems. They help make system boundaries, interfaces and controls visible at ship level.
The relevant survey and review activity depends on the lifecycle phase and the detailed requirement. E26 should not be read as establishing a single universal audit or training cycle.
What E27 requires from systems and suppliers
E27 applies to computer-based systems identified through E26. It requires evidence that can include:
- supplier documentation;
- security capabilities;
- testing or analytical evaluation;
- configuration evidence; and
- secure-development-lifecycle evidence.
Its security capabilities cover areas such as identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response to events and resource availability.
E27 does not mean that every item needs a separate certificate. System certification is ship-specific, while type approval may be used voluntarily for standard, routinely manufactured systems.
The precise relationship with IEC 62443
E27 draws on selected requirements from IEC 62443, but it is not a blanket adoption of the whole standard series.
Its section on security capabilities is based on selected requirements from IEC 62443-3-3. Its section on secure development cites selected requirements from IEC 62443-4-1:2018, the currently valid edition for secure product-development lifecycle requirements. Edition 2.0 remains under development.
IEC 62443-4-2:2019, including its 2022 corrigendum, remains a valid standard for component technical security requirements. However, E27 should not be described as an IEC 62443-4-2 certificate or as proof of certification to IEC 62443.
The limited relationship with IMO guidance and NIST CSF 2.0
The IMO's Guidelines on maritime cyber risk management, issued in April 2025, use six functional elements: Govern, Identify, Protect, Detect, Respond and Recover. They list IACS E26, E27 and NIST CSF 2.0 among non-exhaustive additional references, whose use remains at the user's discretion.
NIST Cybersecurity Framework 2.0 also uses these six functions. E26 revision 1 uses five: Identify, Protect, Detect, Respond and Recover. Similar language helps comparison, but it does not establish clause-by-clause equivalence or incorporate every NIST CSF 2.0 outcome into E26.
The IMO's earlier Resolution MSC.428(98) stated that approved safety management systems should take cyber risk into account under the ISM Code, and encouraged Administrations to ensure this no later than the first annual verification of a company's Document of Compliance after 1 January 2021. That historical management-system milestone is separate from the E26 and E27 application date.
NIS 2 as organisational context
NIS 2 is separate from IACS classification requirements. Under Directive (EU) 2022/2555, Annex I includes specified inland, sea and coastal passenger and freight water-transport companies, as well as port bodies. The relevant water-transport entry excludes the individual vessels operated by those companies.
Whether an organisation falls within NIS 2 depends on its entity type, size rules, exceptions and national implementation. Conformity with E26 or E27 does not by itself establish NIS 2 compliance.
A practical way to prepare
Start by confirming whether the vessel and contract fall within the IACS scope. Then establish the ship-level E26 context before treating E27 as a supplier-documentation exercise.
A useful sequence is:
- identify in-scope assets, systems and interfaces;
- define zones, conduits and the ship-level cyber-resilience design;
- assign responsibilities between the owner or company, yard or integrator, suppliers and class;
- collect and assess E27 system evidence alongside integration and test evidence; and
- maintain the programme and evidence through the relevant design, construction, commissioning and operational stages.
This approach keeps the distinction clear: E26 addresses cyber resilience of the ship as an integrated whole, while E27 addresses the on-board systems and equipment that support it.