IACS UR E27 · For equipment, OEMs & integrators

IACS UR E27 — cyber resilience
of onboard systems & equipment.

E26 governs the vessel. E27 governs what goes inside it. If you manufacture, integrate, or supply Computer Based Systems for vessels contracted after 1 July 2024, UR E27 defines the minimum security capabilities your equipment must demonstrate — and the documentation Class will require from you.

Jul 2024
Mandatory for vessels
contracted from this date
30+11
Security capabilities
required by the standard
IEC 62443
Underlying technical
standard (62443-3-3)
5
Class societies with
published E27 notations
Understanding the framework

E26 and E27 — two different standards, two different audiences

E26 and E27 were published together by IACS and work as a pair — but they address different parts of the maritime cyber problem and are written for different audiences. Understanding the distinction is essential before you decide what your organisation needs to do.

IACS UR E26 — the vessel

Governs the cyber resilience of the ship as a whole. Written for shipowners, operators, and shipyards. Requires a Cyber System Definition Document (CSDD), zone and conduit architecture, and Class approval of the vessel’s overall security design.

  • Shipowners and operators
  • Shipbuilders and yards
  • DPAs and technical managers
  • ETOs during operation
Vessel-level compliance

IACS UR E27 — the equipment

Governs the cyber resilience of individual Computer Based Systems (CBS) installed on the vessel. Written for equipment manufacturers, OEMs, and system integrators. Requires demonstration that each CBS meets defined security capabilities.

  • Equipment manufacturers (OEMs)
  • System integrators
  • Shipyard procurement teams
  • Component and software suppliers
Equipment-level compliance
Scope

Who needs to comply with E27?

E27 applies to any organisation that supplies, integrates, or maintains Computer Based Systems installed on vessels contracted for construction on or after 1 July 2024. If your equipment ends up onboard a vessel subject to E26, your system must demonstrate E27 compliance before it can be approved by Class.

OEM equipment manufacturers

Manufacturers of navigation systems, propulsion control, power management, cargo systems, and any other CBS installed onboard. Your equipment must receive Class approval under E27 before it can be fitted on an E26 vessel.

System integrators

Companies that combine components from multiple manufacturers into a single shipboard system. Even if individual components are approved, the integrated system as a whole must also demonstrate E27 compliance. Third-party components within your system are your responsibility.

Software suppliers

Providers of software running on CBS — including SCADA, HMI software, automation platforms, and monitoring tools. Software suppliers must demonstrate Secure Development Lifecycle (SDL) compliance and provide maintenance and update documentation.

Shipyard procurement teams

When specifying systems for an E26 newbuild, procurement must ensure that every CBS in scope has or will receive E27 Class approval before delivery. E27 compliance is a procurement requirement, not just a supplier problem.

Firewall and network equipment vendors

Firewalls that control communication between CBS zones or with external networks must comply with E27. This includes industrial firewalls, managed switches, and any network device that forms part of a CBS boundary.

Service and maintenance providers

Organisations providing remote access, OEM service connections, or onboard maintenance must demonstrate that their tools and connection methods comply with E27 requirements for access control and session logging.

Technical requirements

The 30 + 11 security capabilities

E27 defines two tiers of security capability based on where a CBS sits in the vessel’s network architecture. Every CBS must meet the 30 base capabilities. An additional 11 capabilities are required for CBS that share an interface with untrusted networks — such as systems connected to the satellite communications zone or the IT network.

30 capabilities — all CBS
+11 capabilities — CBS on untrusted network interfaces
  • Human user identification and authentication
  • Software process and device identification
  • Account management and lockout
  • Unique credentials — no shared accounts
  • Role-based access control (RBAC)
  • Least privilege enforcement
  • Remote session management and termination
  • Concurrent session control
  • Audit log generation
  • Audit log protection and retention
  • Audit log synchronisation (NTP)
  • System use notifications / banners
  • Protection of audit log information
  • Configuration management and baseline
  • Change control and software update management
  • Patch management process
  • Malicious code protection
  • Security functionality verification
  • Network segmentation support
  • Zone boundary protection
  • Communication integrity
  • Resource management and availability
  • Control system backup and recovery
  • Emergency power and availability
  • Physical access control to CBS components
  • Output device control
  • Removable media protection
  • Incident response support information
  • Secure development lifecycle documentation
  • Maintenance and verification plan
  • Use control on untrusted network connections
  • Explicit deny-by-default for untrusted zones
  • Encrypted communications on untrusted links
  • Cryptographic key management
  • Public key infrastructure (PKI) support
  • Network address validation and filtering
  • Session authentication for untrusted connections
  • Mobile code restrictions
  • Wireless access management
  • Use of approved protocols only
  • Intrusion detection capability on network boundary
These 11 additional capabilities align with IEC 62443-3-3 Security Level 2 (SL2) requirements. A CBS connected to a SATCOM terminal, shore-based monitoring system, or crew IT network will typically require all 41 capabilities.
The capabilities above are based on IEC 62443-3-3 and map to DNV Security Profile SP1/SP2. Exact implementation details vary by Class society — DNV, LR, BV, ABS, and ClassNK each publish their own E27 guidance documents.
Section breakdown

E27 requirements — section by section

E27 is structured across six sections. For each section below, we list what is required and link to the TAGSIA playbooks that implement the corresponding operational controls — useful both for OEMs building compliant systems and for shipowners verifying that installed systems meet requirements.

§4.1 — General
System scope definition and CBS categorisation
The system supplier must define the boundary of the CBS, identify all sub-components within scope, and classify the system according to its criticality and network exposure. Third-party components within the system boundary are included in scope. Systems must be categorised as either standard CBS or CBS connected to untrusted networks.
Related playbooks: Asset Inventory Criticality Mapping CSDD & Exclusion
§4.2 — Access control & IAM
Identity, authentication, and role-based access
Every CBS must support unique user identification and authentication. Shared accounts and default manufacturer credentials are not permitted. Role-based access control must be implemented with least privilege enforcement. Systems must support account lockout and remote session termination. Crew changeover procedures must ensure departing user credentials are revoked.
Related playbooks: Password Policy & RBAC MFA Crew Changeover RBAC Matrix Account Audit Log
§4.3 — System hardening
OS hardening, malware protection, and patch management
All unnecessary services, ports, and software must be disabled. The CBS must implement malware protection appropriate to the OT environment — standard antivirus that could destabilise the system is not acceptable. A documented patch management process must be in place, including OEM-approved testing before deployment. NTP synchronisation must be maintained for audit log integrity.
Related playbooks: OS Hardening Anti-Malware Patch Management NTP / Time Sync Hardening Audit Record
§4.4 — Data protection & backups
Configuration backups, recovery, and data integrity
The CBS must support offline backup of all critical configurations and operational data. The supplier must document the recovery procedure and define a recovery time objective. Backup integrity must be verifiable without connecting to the live system. For networked CBS, communication integrity mechanisms must be in place to detect unauthorised data modification in transit.
Related playbooks: Configuration Backups Golden Images Offline Backup Verification Backup Log
§4.5 — Supply chain & vendor access
Third-party components, OEM access, and service procedures
System suppliers are responsible for the security of third-party components integrated into their CBS. OEM remote access must be controlled, logged, and terminable by the vessel operator. Service engineers must use verified, clean toolsets and must not introduce unauthorised software. All vendor access sessions must be recorded with a post-session audit trail.
Related playbooks: Supply Chain Security Remote Access Service Entry Permit Remote Access Log Post-Session Audit
§4.6 — Incident response support
Audit logging, incident information, and recovery documentation
The CBS must generate and protect security event logs sufficient to support post-incident forensic analysis. Log retention must meet Class requirements. The supplier must provide documentation that supports the shipowner’s incident response and recovery plan — including system-specific recovery procedures and known indicators of compromise for the CBS.
Related playbooks: Syslog Setup Log Retention First 15 Minutes Integrity Verification
Class submission

Documents required for E27 Class approval

To obtain E27 Class approval for a CBS, the supplier must submit specific documentation to the Class society. The table below shows what is required, the E27 section it corresponds to, and whether TAGSIA has a template or playbook that supports its preparation.

Document required E27 reference TAGSIA resource
CBS scope definition and system description §3.1.1 / §4.1 Asset Inventory Guide →
Security capability self-assessment against 30+11 §3.1.2 Hardening Audit Record →
Secure Development Lifecycle (SDL) documentation §3.1.5 Supplier-specific — no template
Maintenance and verification plan §3.1.6 Software & Firmware Tracking →
Incident response support information §3.1.7 First 15 Minutes →
Access control and RBAC configuration evidence §4.2 RBAC Matrix Template →
Patch management procedure §4.3 Patch Management →
Backup and recovery procedure §4.4 Configuration Backups →
Vendor and third-party access control procedure §4.5 Service Entry Permit →
Audit log specification and retention policy §4.6 Log Retention Rules →
Class society guidance

How each Class society implements E27

All IACS member societies apply UR E27 as a minimum baseline, but each has published its own guidance and class notation that layers additional requirements on top. The security profiles and notation names differ — understanding which Class society is certifying your vessel or equipment matters.

DNV
Cyber Secure / Cyber Secure Essential / Cyber Secure Advanced
DNV uses Security Profiles (SP0–SP4) that loosely align with IEC 62443 Security Levels. E27 compliance maps to SP1 minimum. Cyber Secure Essential requires full E26 + E27. DNV has published the most detailed public guidance of any Class society and is the most frequently referenced for E27 interpretation.
Lloyd’s Register
ShipRight Cyber — LR CyberSafe
LR’s rules are closely aligned with E26/E27 requirements. LR does not publish separate E27 interpretation documents publicly but applies E27 through the ShipRight procedure. Currently certifying the first wave of E26/E27 newbuilds at major European shipyards.
Bureau Veritas
CYBER notation (CS1 / CS2)
BV applies a two-tier notation — CS1 aligns with IMO MSC.428(98) and CS2 aligns with E26/E27. For E27 equipment approval, BV uses their published guidance on type approval for computer-based systems aligned with E27 security capabilities.
ClassNK
ClassNK CMID / Part X
ClassNK has incorporated E26/E27 into Part X of their Rules for Classification and publishes a Form-7-10 application for type approval under E27. ClassNK has published public interpretation guidelines and explanatory videos. The most accessible published guidance for E27 equipment certification.
ABS
ABS CyberSafety — CSQS Notation
ABS offers a Cyber Resilience Program for E27 equipment certification. ABS has published a detailed FAQ document covering E27 scope, third-party component responsibility, and certification process. Early adopters can benefit from ABS certification services before the full E26/E27 enforcement cycle.
RINA
RINA Cyber Resilience
RINA applies E27 through their Cyber Resilience notation aligned with IACS requirements. RINA is active in the Mediterranean and Italian shipbuilding sector. E27 equipment certification follows the same documentation requirements as other IACS member societies.
Common questions

Frequently asked questions

E27 only applies to vessels contracted for construction on or after 1 July 2024. If your equipment is being installed on an existing vessel as a retrofit, E27 is not formally required — however, Class societies increasingly recommend E27-compliant equipment even for retrofits, and some shipowners are beginning to require E27 compliance in their procurement specifications regardless of vessel age. For new equipment being fitted to existing vessels, it is worth obtaining E27 approval proactively as it will become a commercial differentiator.
Yes. E27 defines a “System” as a combination of interacting programmable devices and sub-systems. Any third-party equipment within your CBS boundary is within your scope of responsibility. Your suppliers must either obtain their own E27 Class approval for their components, or you must include them in your system-level E27 approval submission and demonstrate that the integrated system meets all required capabilities. You cannot simply exclude a non-compliant component from your submission.
No. E27 does not require the use of a qualified person or certified testing organisation to carry out tests for security capabilities. The supplier performs the self-assessment and provides the documentation to Class. The Class society reviews the documentation and may request additional evidence or testing at their discretion. This is different from some other certification regimes — it keeps the burden on the supplier but does not require a formal third-party audit.
No. A service engineer’s work computer used temporarily for maintenance is not considered an “other system” under E26 §1.3.2 and is therefore not subject to E27 CBS approval requirements. However, the approved service engineer from the supplier is expected to implement appropriate cybersecurity measures for their laptop connection — including using clean, verified toolsets. The connection itself must be authorised, logged, and terminated per the vessel’s access control procedures.
E27 is directly based on IEC 62443-3-3, the component security requirements standard within the IEC 62443 series. The 30 base security capabilities map to IEC 62443-3-3 Security Level 1 (SL1) requirements, and the 11 additional capabilities for untrusted network interfaces map to SL2. If your organisation already has IEC 62443 compliance work underway, E27 compliance will largely follow from it — though maritime-specific adaptations (particularly around operational availability constraints) mean that direct equivalence is not assumed by Class societies.
UR E22 (Computer-based systems) is not within the scope of UR E27 — they are separate requirements. However, E22 is expected to be applied alongside E27 where relevant for classification purposes. E22 addresses the safety and functionality of computer-based systems, while E27 addresses their cyber resilience. If you are applying for or revalidating a Product Design Assessment (PDA) certificate, it is recommended to combine compliance with E10, E22, and E27 to ensure full alignment with Class requirements.

Building E27-compliant systems?

Every TAGSIA playbook tagged with the E27 badge maps directly to the section it satisfies. Use them as your implementation reference and evidence base.

Browse Protect playbooks → Start with Identify
Login
Login
Scroll to Top