IACS Unified Requirements E26 and E27 are class requirements for cyber resilience on ships. E26 covers the cyber resilience of newbuilds, and E27 covers the cyber resilience of onboard systems and equipment. They shape how ship systems are designed, segmented and protected against unauthorised access or disruption.
What the requirements cover in practice
IACS Unified Requirements E26 and E27 sit in the ship cybersecurity layer where design decisions become resilience controls. E26 focuses on cyber resilience for newbuilds, while E27 focuses on onboard systems and equipment already in service. Together, they shape how vessel systems are segmented, protected and made harder to disrupt through cyber means.
That makes the topic broader than a compliance label. It is about how shipboard technology is engineered so that essential functions remain controlled, recoverable and less exposed to unauthorised access or interference.
Why ship cyber resilience needs class-level requirements
Ships combine operational technology, navigation, communications and vendor-supported equipment in a constrained environment, often with limited patch windows and high availability needs. Requirements such as E26 and E27 matter because cyber failure at sea can affect safety, voyage continuity, remote support, cargo handling and the integrity of onboard control systems.
These requirements are especially relevant where systems are connected across trust boundaries, because a weakness in one onboard component can become a route into more critical functions. For that reason, ship cybersecurity cannot rely only on endpoint hardening, it also depends on architecture, segmentation and controlled access paths.
For a broader treatment of how maritime cybersecurity is framed across vessels, port systems and related operational environments, see the Maritime Cybersecurity Guide.
How E26 and E27 shape ship design and equipment assurance
E26 is best understood as a design-time requirement. It pushes resilience considerations into the build phase, when network zones, remote access assumptions, backup paths and recovery expectations can still be built into the ship rather than bolted on later.
E27 is the operational counterpart. It is concerned with onboard systems and equipment that must continue to function safely under realistic cyber conditions, including malicious access attempts, misconfiguration and disruption of service. In practice, that means the cyber posture of a ship is evaluated not just by what is installed, but by how it behaves under stress and how dependencies are isolated.
The practical value of the class rules is that they turn cyber resilience into an engineering requirement for the vessel and its components, not just an IT security preference. That is where IACS UR E26 and E27 Ship Cyber Resilience Guide is useful for understanding the covered shipboard scope, zones and conduits, and the evidence shipowners and integrators usually need.
What implementation usually depends on
Meeting these requirements usually depends on more than one control family. Shipboard segmentation, secure remote maintenance, account discipline, change control, component integrity and recovery planning all play a part. The challenge is not only preventing direct compromise, but also limiting what an attacker can reach if one pathway is abused.
Class requirements also intersect with equipment assurance and supplier integration. Onboard systems may arrive as embedded products, integrated subsystems or remote-managed services, so owners and builders need a clear view of which interfaces are exposed, which dependencies are trusted, and which controls must be validated before handover. That is why implementation often involves both design documents and survey evidence, not just a policy statement.
Where shipping environments include third-party maintenance or integrator access, the access path itself becomes part of the resilience story. The OT Third-Party and Integrator Access Guide is a useful companion for the remote support and handover issues that often appear in shipboard deployments.
Risk and Threat Considerations
These requirements exist because ship systems are exposed to both operational failure and hostile interference. If segmentation is weak, remote access is overbroad, or onboard systems share trust too freely, a compromise in one area can spread into navigation, control, communications or other critical services.
Failure mechanism: Attackers or faulty integrations exploit flat networks, poor access control, weak vendor paths or unsegmented equipment to move laterally, disrupt services or alter the behaviour of onboard systems.
Impact: The result can be loss of availability, degraded safety margins, delayed recovery, unsafe operation or the need to take systems offline during a voyage or maintenance window.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | E26 and E27 depend on network zoning and segmentation to limit spread across ship systems. |
| AC-6 — Least Privilege | Shipboard access paths and remote support should be limited to the minimum required authority. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Onboard equipment and external service paths need strong authentication where systems interconnect. | |
| Recommendation — Apply SC-7 to segment shipboard networks and restrict traffic between critical onboard zones. Use AC-6 to constrain shipboard and vendor access to only the permissions needed. Apply IA-9 to authenticate external systems and services that connect to shipboard assets. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Shipboard segmentation, resilient connectivity and controlled interfaces map directly to network infrastructure safeguarding. |
| CIS-6 — Access Control Management | Class requirements rely on limiting who can reach onboard systems and service interfaces. | |
| Recommendation — Use CIS-12 to manage ship network boundaries, routes and exposed management paths. Use CIS-6 to enforce least privilege for shipboard and remote access paths. | ||
Practitioner Guidance
Why practitioners should care: E26 and E27 are most useful when they are treated as design and assurance requirements, not as a paperwork exercise. Shipbuilders, owners, integrators and class stakeholders need to agree early on what must be isolated, what must be recoverable and what evidence will prove the vessel meets the intended resilience outcome.
What to watch for: The main warning signs are unclear system boundaries, vendor access that is broader than necessary, and equipment that has been fitted without a clear cyber resilience rationale. Where those patterns exist, the ship may meet functional requirements while still remaining unnecessarily exposed.
Related resources from NHI Mgmt Group
- What happens when organisations try to meet cyber insurance or regulatory identity requirements without unified enforcement?
- What happens when a company expands into states with different privacy requirements without a unified program?
- Why does Unified Namespace create new security requirements in industrial environments?
- What are the signs that a bank's privacy program is not keeping pace with unified data protection requirements?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org