E26 & E27 Cyber Resilience Compliance Whitepaper

The three-layer compliance stack: IMO, classification, and flag-state enforcement

Understanding the binding force of E26/E27 first requires mapping the regulatory architecture in which they sit. The framework has three layers, each reinforcing and depending on the one above.

The first layer is the foundational IMO requirement. In June 2017, the IMO Maritime Safety Committee at its 98th session (MSC 98) adopted Resolution MSC.428(98), directing shipowners and managers to incorporate cyber risk into their Safety Management Systems (SMS) under the ISM Code. The resolution is not a technical specification — it is a management principle: operators must identify, assess, and manage cyber risks within the SMS. The compliance deadline was the first annual verification of each company's Document of Compliance (DoC) occurring after 1 January 2021. From that point, any ISM audit is expected to verify that cyber risk management is embedded in the SMS. MSC.428(98) applies globally to all ships operating under ISM, which is broad in scope — but it provides no actionable technical baseline. It tells operators what to do without specifying how.

The second layer is the IACS unified technical requirement. Precisely because IMO offered no technical detail, the industry needed a verifiable, auditable technical standard. IACS published UR E26 (ship-level cyber resilience) and UR E27 (on-board systems and equipment) in April 2022. However, those original versions were formally withdrawn before their planned 1 January 2024 entry-into-force date, replaced by Rev.1 — E27 Rev.1 issued September 2023, E26 Rev.1 issued November 2023 — with a unified mandatory date of 1 July 2024. This withdraw-and-reissue episode is unusual in IACS history; it reflects substantial industry feedback on the original technical provisions and significant revision effort to improve enforceability. E26/E27 translate IMO's principle-level mandate into a specific list of required technical capabilities, document submission procedures, and surveyor-witnessed acceptance tests — all verifiable item by item by a class society.

The third layer is flag-state and Port State Control (PSC) enforcement. IACS unified requirements are implemented through each member society's own rules; a vessel receiving class certification has simultaneously met its flag state's technical standards for new construction, while PSC inspectors enforce these standards at ports worldwide. A qualifying newbuild that fails to meet E26/E27 cannot, in principle, obtain or retain its class certificate — and without class, it cannot trade commercially. This consequence is more practically effective than any fine. An important boundary: E26/E27 apply only to ships whose construction is contracted on or after 1 July 2024. Vessels already in service remain governed only by IMO MSC.428 and ISM. For owners managing mixed-age fleets, this creates a dual-track compliance world that must be assessed separately for each vessel.

E26 governs the whole ship; E27 governs on-board systems and equipment — a ship's E26 compliance rests on its individual CBS each meeting E27. Both are mandatory for new ships whose construction is contracted on or after 1 July 2024.

How it became mandatory, step by step

From the IMO folding cyber risk into the safety management system, to IACS issuing technical unified requirements, there was even a "withdraw and reissue": the April-2022 originals were due to take effect on 1 January 2024 but were withdrawn before coming into force, replaced by Rev.1 (E27 Sept 2023, E26 Nov 2023), with a unified effective date of 1 July 2024.

Withdraw and reissue: an unusual revision episode

After the April 2022 originals were published, industry feedback from equipment manufacturers, shipyards, and owners surfaced a range of enforceability questions: how technical capability requirements were defined, the scope and format of document submissions, and the operational boundaries of FAT witnessing all needed greater clarity. IACS withdrew the originals before they took effect (the IACS website marks them as "UR E26 New — Withdrawn"), conducted a systematic revision, and published E27 Rev.1 in September 2023 and E26 Rev.1 in November 2023, deferring the unified effective date to 1 July 2024 and giving the industry approximately six additional months of preparation time.

Two key implications follow. First, any contract or technical specification referencing the April 2022 originals must be reviewed for legal force — the originals carry no binding weight; only Rev.1 is operative. Second, the originally planned 1 January 2024 effective date corresponds to a version that never came into force, meaning that the technical baseline applicable to early-2024 construction contracts must be verified with the specific class society. Meanwhile, DNV reported that approximately 200 vessels had voluntarily acquired DNV's Cyber Secure notation (across notation tiers) before the mandatory July 2024 date, demonstrating that the market had already generated meaningful early-adoption experience ahead of mandatory implementation.

Two submission routes

Submission is ship-specific and ends in a System certificate. Whether the equipment holds a type approval decides the route:

Type approval versus ship-specific plan approval: a strategic decision

The "Route A / Route B" labels used in the diagram above are a common industry shorthand, not official IACS terminology. The accurate official mechanism is: a supplier can pre-qualify a CBS by obtaining a Type Approval Certificate (TAC) demonstrating that the system meets E27 requirements, or submit full documentation on a per-vessel basis through the plan approval process for each specific ship. Both paths lead to the same end point — a System certificate — but they allocate upfront investment and per-vessel marginal cost very differently.

For equipment manufacturers, this is the most strategically consequential decision in the entire E27 compliance framework. The type approval path requires the supplier to complete a full-scope verification once at the outset: submit a complete documentation package with compliance mapping for all 41 security capabilities to a class society, undergo a factory audit, and have a class surveyor witness one Cyber FAT. Once the TAC is issued, each subsequent vessel order within the TAC validity period (approximately 5 years per ABS guidance, but practice varies by society — verify with your classification society) requires only a reduced per-vessel document set with no additional FAT witnessing. For suppliers with volume orders across multiple yards and a relatively standardised product — propulsion control systems, integrated navigation systems, vessel automation platforms — the economics of type approval improve rapidly with order volume.

The ship-specific route (no type approval) requires no upfront certification investment; complete documentation is submitted per vessel, but each delivery requires a class surveyor to physically attend the factory or yard to witness the Cyber FAT. For a CBS developed specifically for a single project with little prospect of repeat delivery — for example, a proprietary manoeuvring system for a specialised engineering vessel — this approach is reasonable. However, for suppliers with multi-vessel orders, the ship-specific route carries a practical risk that is often underestimated: surveyor availability, not documentation readiness, frequently becomes the binding constraint on delivery dates. Class societies have finite pools of qualified cyber surveyors, and the calendar pressure on Cyber FATs is likely to intensify as the industry enters mandatory compliance at scale. A supplier on the ship-specific route that cannot confirm a surveyor slot months in advance risks delivery delay — a cost that is easy to overlook during contracting.

Type approval is also not a permanent exemption: even with a valid TAC, suppliers must still submit certain vessel-specific items per ship, including the CBS asset inventory, topology diagrams, and test reports. What type approval exempts is design review and witnessed FAT; it does not remove all per-vessel documentation obligations. Version drift is a related concern: if firmware or software versions advance after TAC issuance, whether the new version remains within TAC coverage varies by class society policy and must be confirmed proactively to avoid compliance disputes at delivery.

The 10 document types

1. CBS asset inventory
2. Topology diagrams
3. Description of security capabilities
4. Test procedure for security capabilities
5. Security configuration guidelines
6. Secure Development Lifecycle (SDLC) documents
7. CBS maintenance & verification plans
8. Information supporting the owner's incident response & recovery
9. Management-of-change plan
10. Test reports

The rationale behind the document list: why each item exists

The ten document types are not an arbitrary checklist — together they form an evidence chain from design through operation, each type targeting a specific regulatory purpose at a specific lifecycle stage. Understanding the rationale helps suppliers, yards, and designers plan their documentation architecture with the end in mind from the outset, rather than assembling materials under time pressure at the submission deadline.

The CBS asset inventory (item 1) is the foundation of the entire compliance structure. It establishes the identity of each CBS: hardware model, software version, firmware version, network interfaces, and deck location. Without an accurate asset inventory, vulnerability management, patch records, and incident response have no anchor. This document maps to the Identify function of the NIST Cybersecurity Framework and is the operational baseline the owner must maintain throughout the vessel's service life.

Topology diagrams (item 2) show the interconnections among CBS units, between CBS units and the vessel's network zones, including all data flows and interface types. For the shipyard (systems integrator), these diagrams align with E26's Zones and Conduit Diagram requirement and together demonstrate that network segmentation has been designed and implemented at the vessel level. For the equipment supplier, the critical value of topology diagrams is that they determine whether the CBS has an interface with an untrusted network — if it does, the additional 11 security capabilities in E27 apply on top of the baseline 30, substantially expanding the compliance scope.

The description of security capabilities (item 3) and the test procedure for security capabilities (item 4) are the technical core of the E27 evidence package. The former maps each of the 30 (or 41) security capabilities to the specific implementation mechanism in the product; the latter specifies how each capability is verified as correctly implemented on the actual system. These two documents form the basis for Cyber FAT witnessing regardless of whether the supplier follows the type approval or ship-specific route — the difference is only that the type approval route completes these documents once at the TAC stage, while the ship-specific route requires them per vessel.

Security configuration guidelines (item 5) address the ship's crew and shore-based maintenance staff: they specify how the CBS should maintain its approved security configuration in operation, covering password policies, port management, and access privilege tiering. This document is auditable at annual class renewal — owners must demonstrate that the approved configuration has been maintained in service, not merely achieved at design time and allowed to drift thereafter.

The Secure Development Lifecycle documents (item 6) represent E27's reach upstream into the supply chain. E27 explicitly requires equipment suppliers to operate a Secure Development Lifecycle aligned to IEC 62443-4-1, meaning cybersecurity is not a testing-phase concern but a systemic capability spanning requirements analysis, design, coding, testing, release, and vulnerability response. This is a new challenge for many industrial control system suppliers, particularly those whose development processes were built on functional safety frameworks without integrated information security.

The CBS maintenance and verification plan (item 7) and the information supporting the owner's incident response and recovery (item 8) both address post-delivery operations: the former specifies how to periodically verify that the CBS's security performance has not degraded in service; the latter provides the owner with technical information needed during a cyber incident — including log formats, backup and recovery interfaces, and emergency fallback procedures. Both documents reflect E27's foundational position that a supplier's cyber responsibility does not end at delivery but extends across the operational life of the equipment.

The management-of-change plan (item 9) specifies the procedures to follow when a CBS undergoes a configuration change, software update, or hardware replacement, ensuring that changes do not compromise the approved security state and that the class society is notified as appropriate. This is the procedural control mechanism for version-drift risk. Test reports (item 10) are the results summary of all security capability tests, retained as the final evidence record for Cyber FAT witnessing.

Viewed as a whole, these ten document types form a tightly interdependent evidence chain: E27 documents (items 1–10, supplied by the equipment manufacturer) are a prerequisite for the yard's E26 ship-level compliance argument. A supplier that delays submitting its E27 documentation package directly blocks the yard's E26 submission to class, and in turn affects the entire vessel's delivery schedule. This dependency means that E27 compliance is far from an internal matter for the equipment supplier alone — it is a critical-path item for the entire project supply chain.

E27 capabilities

41E27 capabilities30 + 11

E26 ship requirements

17E26 ship requirements

NIST-aligned functions

5NIST-aligned functions

CBS categories (E22)

3CBS categories (E22)

Stakeholder map: who owns which layer

A key feature of E26/E27 is its clear role stratification — different parties carry compliance responsibility at different layers, and those boundaries are explicitly mapped in the technical requirements. Understanding this stratification is essential for each party to identify its own obligations and allocate resources in the early project phases.

The equipment manufacturer (OEM or supplier) owns E27 compliance. They must demonstrate that each CBS meets all applicable E27 security capabilities — 30 for systems without untrusted-network interfaces, 41 for those with such interfaces. Suppliers must also operate a Secure Development Lifecycle aligned to IEC 62443-4-1 and deliver a complete E27 documentation package to the yard. Under the type approval path, the supplier invests upfront in TAC certification; under the ship-specific path, the supplier must arrange and support FAT witnessing for each vessel. Suppliers who treat E27 compliance as a paperwork exercise rather than a product capability build will struggle under actual review — class surveyors test the capabilities that the documentation claims.

The shipyard (systems integrator) owns E26 compliance. Under E26, the yard is the "systems integrator" responsible for assembling CBS from multiple suppliers into a cyber-resilient vessel and demonstrating this to class. The yard's dependency on supplier E27 documentation is bilateral: on the procurement side, the yard must contractually require E27-compliant packages from suppliers; on the design side, the yard must establish zone definitions early, because zone decisions determine which CBS will have untrusted-network interfaces — and therefore whether suppliers must meet 30 or 41 capabilities. This means E26/E27 compliance work must begin at the concept design stage.

The designer (naval architect or design office) carries a critical early role in zone architecture and conduit design. The Zones and Conduit Diagram is the most central E26 design-phase document, and its design decisions must be made before procurement begins: once a functional domain is determined to interface with the business network or the internet, the corresponding CBS must meet the additional 11 E27 capabilities, directly affecting product selection and supplier qualification requirements. A designer who defers network segmentation design to the detailed design phase may face the cost of re-selection or remedial supplier compliance action.

The shipowner (operator) owns E26 compliance in the operational phase. The owner must sustain the Ship Cyber-Security and Resilience Programme: tracking CBS patch status (suppliers must release security patches within reasonable timeframes; owners must track and apply them); maintaining access control and portable device management procedures; keeping CBS software bill of materials (SBOM) and CVE records current; and responding to cyber incidents according to plan. All of these are surveyable at annual class renewal — owners must demonstrate that written plans have been implemented in actual operations, not merely filed away.

The class society is the verification and witnessing authority across the entire system: reviewing documents, issuing type approval certificates, witnessing Cyber FATs on the ship-specific route, issuing class certificates with cyber notations, and verifying ongoing compliance at annual surveys. Implementation details vary across class societies; all procedural questions — FAT scheduling, document format requirements, TAC version-change handling — should be resolved against the specific society's current rules.

Early certification examples: projects that led the way

Several projects completed class certification under E26/E27 ahead of or around the mandatory effective date, providing valuable practical benchmarks for the industry.

On the DNV side, a series of three DP2 shuttle tankers built by Samsung Heavy Industries for TEN (Tsakos Energy Navigation), reported by Riviera (2025), became the first shuttle tanker newbuild series to receive DNV's Cyber Secure (Essential) class notation, compliant with IACS E26/E27 and IEC 62443-3-3, with two deliveries in Q2 2025 and one planned for Q2 2026. This project demonstrated the viability of an early E26/E27 compliance path in the large tanker segment.

On the Lloyd's Register side, in May 2025 North Star's two Commissioning Service Operation Vessels (CSOVs) — Grampian Kestrel and Grampian Eagle — built by Vard Langsten in Norway to the VARD 4 22 design, became the first offshore wind vessels formally approved by Lloyd's Register under LR Rules implementing IACS UR E26 and E27, with their dynamic positioning and Voith Schneider propulsion systems assessed (source: LR press release, May 2025). This case is particularly instructive because the DP systems and propulsion controls on a CSOV are precisely the type of CBS that interfaces with untrusted networks — meeting the full 41-capability E27 requirement was central to their approval.

The shared lesson from both cases is that E26/E27 compliance, while requiring substantial coordination among suppliers, yards, designers, and owners across all project phases, is operationally achievable under current technology conditions and class society review capacity, with certification timelines that are now beginning to solidify. Experience accumulated in early projects — including document formats, FAT scheduling practices, and CBS version management — will serve as reference points for subsequent builds.

Four real-world readiness gaps

Even after the mandatory effective date, several structural gaps persist across the industry in actual implementation. Understanding these gaps helps each party identify risks and address them proactively.

The first gap is the disconnect between documentation capability and product capability. Many suppliers' equipment already embeds substantial cybersecurity protection at the functional level, but the capabilities have never been systematically documented in the format E27 requires. The product capability exists; the evidence does not. Generating a complete E27 capability compliance map — matching each of the 41 security capabilities to specific implementation mechanisms in the product — typically requires joint input from engineering, software, and certification teams, taking far longer than initial estimates suggest. For OEMs with long product histories and limited original documentation, this workload is particularly substantial.

The second gap is version drift and the absence of Software Bill of Materials (SBOM). A product that has obtained type approval will almost inevitably go through firmware or software version changes. Whether new versions remain within TAC coverage, how owners track and record the version state of deployed CBS units, and whether CVE records are maintained — these are universally weak areas in current practice. SBOM generation is particularly complex in industrial embedded systems; many products' component inventories were never systematically recorded during development, and retrospective reconstruction carries both cost and accuracy challenges.

The third gap is late-stage zone definition decisions. In some projects, network segmentation design was not seriously addressed until after procurement was complete, with the result that certain already-specified CBS units were identified as interfacing with untrusted networks only in the detailed design phase — suddenly requiring compliance with the additional 11 E27 capabilities. Demanding that suppliers supplement capabilities or documentation at that stage is expensive and can trigger delivery disputes. The correct approach is to establish zone architecture before procurement tendering begins and to specify E27 capability requirements (30 or 41) in the procurement technical specification.

The fourth gap is the bottleneck in specialist surveyor availability. Class societies have a finite pool of surveyors qualified to witness E27 Cyber FATs, and with multiple newbuild projects progressing simultaneously across global yards, surveyor scheduling pressure is a foreseeable systemic risk. A supplier on the ship-specific route that cannot lock in a surveyor slot months in advance may face the scenario of equipment ready at the factory but with no surveyor available to witness the FAT — leading to vessel lay-by time and quantifiable economic loss. This risk is one of the hidden advantages of the type approval path over the ship-specific route and should be factored into the cost-benefit assessment of the two paths.

All four gaps share a common root cause: treating E26/E27 compliance as a pre-delivery "finishing task" rather than as an embedded process throughout the project lifecycle. Starting compliance work at the concept design stage rather than the detailed design stage carries a materially lower marginal cost — the difference is one of order of magnitude.

This whitepaper is an introductory overview, easy to forward to peers; formal compliance requirements and classification rest with class society review.