IACS UR E27 Clause Map

E27's full title is "Cyber Resilience of On-board Systems and Equipment." It is not a brand-new security theory — §4 states plainly that "the requirements in this section are based on the selected requirements in IEC 62443-3-3," and every capability cites its source SR number. As ABS characterized it in Regulatory News No. 14/2023, E27 is "a subset, or summary, of the requirements in IEC 62443-3-3." In other words, E27 is the most authoritative mature standard for industrial control system security, tailored for the maritime context — not a purpose-built maritime framework built from scratch.

This matters practically: OEM vendors and design institutes (system integrators) do not need to learn an entirely new security logic from scratch. They need only to build on existing IEC 62443-3-3 knowledge and determine which SRs were selected into E27 by IACS and which were omitted or adapted. IEC 62443-3-3:2013 (Edition 1.0, published August 2013, stability date 2027) defines 51 base system requirements across seven foundational-requirement families (FR1–FR7); E27 selects the subset most relevant to maritime operating environments, forming the closed set of 41 capabilities. This clause map is the navigation tool that helps every party in the supply chain quickly locate: which SRs apply to my equipment, which FR family they belong to, and where they sit in E27.

Version history: from the 2022 original to Rev.1 (in force 1 July 2024)

E27 was not born in its current form. IACS published the original E27 in April 2022; however, before its planned 1 January 2024 entry-into-force date, IACS withdrew it after incorporating industry feedback. Rev.1 was adopted in September 2023, followed two months later by E26 Rev.1 in November 2023. Both standards entered into force on 1 July 2024. Notably, E27 Rev.1 was finalized before E26 Rev.1 — the "component/equipment level" standard was locked before the "ship level" standard. This sequence reflects the IEC 62443 layered architecture: establish component capability boundaries first, then build zone-and-conduit rules at the system level. All active E27 surveys and Type Approvals in the market are conducted against Rev.1; the original version carries no legal force.

E27's three obligation pillars: §3 documentation, §4 capabilities, §5 SDLC

Many discussions equate E27 with its §4 41-capability list, but the full E27 compliance obligation spans three layers. §3 imposes systematic documentation requirements: CBS asset inventory (§3.1.1), security-zone topology diagrams (§3.1.2), description of security capabilities (§3.1.3), security configuration guidelines (§3.1.5), incident-response support documentation (§3.1.8), and a Management of Change Plan (§3.1.9). §4 is the core: 41 security capabilities (30 core + 11 additional), each traced back to an IEC 62443-3-3 SR number. §5 focuses on the Secure Development Lifecycle (SDLC), requiring alignment with IEC 62443-4-1 and covering private key management (§5.1), security update documentation (§5.2), and product defence-in-depth (§5.5). For equipment vendors, §3 documentation obligations are often underestimated relative to §4 technical capabilities — and are typically checked first in a survey.

41 capabilities: 30 in §4.1 + 11 in §4.2

E27 §4's security capabilities are split into two parts. The 30 items in §4.1 apply to every in-scope CBS — they are the baseline threshold for every piece of equipment. The 11 additional items in §4.2 apply only when a CBS has a communication interface with an "untrusted network" (any network outside E26's protected perimeter). Together that is 41 — the number worth memorising first before any self-audit. Industry literature sometimes refers to these two parts as "Table 1" and "Table 2," but the document's organizing structure uses §4.1 and §4.2 (each section containing a tabular capability listing, per the document structure described by ure27.com).

What the "untrusted network" threshold means for vendor design decisions

Whether the 11 additional §4.2 capabilities are triggered depends on one key question: will this CBS, by design, have an interface with an "untrusted network"? Within the E26/E27 framework, a "trusted network" is the ship's internal network within E26's protected boundary; everything outside that boundary — satellite links, shore-side connections, third-party data interfaces — is an untrusted network. This determination must be made during the design phase, not improvised at Type Approval or class survey.

From an engineering standpoint, this design decision has clear compliance-cost implications: a CBS that can architecturally avoid direct contact with untrusted networks (for example, by routing through a boundary device acting as a protocol gateway, while itself remaining in the internal trusted zone) reduces its E27 compliance scope by approximately 27% (from 41 to 30 items). Device types that typically trigger §4.2 include: voyage data recorders (VDRs) with satellite uplinks, fleet management systems with shore-based remote access capability, and engine-room monitoring gateways communicating with shore via public or carrier networks. When design institutes draft the E26 Zone-and-Conduit architecture, they should simultaneously annotate each CBS's network-contact type, so vendors can accurately determine whether their verification scope is §4.1 only or §4.1 + §4.2.

Seven capability families (FR1–FR7): mapping from IEC 62443-3-3 to E27

IEC 62443-3-3:2013's 51 base system requirements are organized around seven Foundational Requirement (FR) families (FR1–FR7). E27 selects the subset relevant to the maritime context, but does not use FR family names as section titles within the standard text itself (based on available open-text sources, E27 §4 presents capabilities as a tabular list, each item annotated with its source SR number, rather than organized under FR headings). Grouping E27's 41 capabilities by FR1–FR7 is therefore a cross-reference analytical view — mapping each capability's IEC 62443-3-3 SR source back to its FR family — a useful lens for understanding the distribution of compliance effort.

The FR-family distribution of IEC 62443-3-3's original 51 SRs is: FR1 (Identification and Authentication Control, IAC) 13 SRs; FR2 (Use Control, UC) 12 SRs; FR3 (System Integrity, SI) 9 SRs; FR4 (Data Confidentiality, DC) 3 SRs; FR5 (Restricted Data Flow, RDF) 4 SRs; FR6 (Timely Response to Events, TRE) 2 SRs; FR7 (Resource Availability, RA) 8 SRs. In terms of volume, FR1 and FR2 together account for 25 of the 51 SRs (approximately 49%), confirming that identification, authentication, and authorization control are the primary domain in industrial control system security. After E27 selects its subset, FR1/FR2's dominance is expected to carry over; however, the precise distribution of E27's 41 capabilities across FR families cannot be directly verified from open-text sources, so the table below presents an illustrative mapping based on IEC 62443-3-3's original structure — consult your class society for the definitive clause-level determination.

What the FR-family distribution signals to vendors and designers

Understanding FR-family weighting helps vendors make correct R&D investment priority decisions when resources are limited. FR1 (Identification and Authentication Control) and FR2 (Use Control) together account for 25 SRs in the IEC 62443-3-3 original — nearly half of all SRs. This means E27's broadest coverage area very likely concentrates on two core questions: who can log in, and what can they do after logging in. For equipment vendors, this has direct product design implications: default passwords must be force-changed on first activation; role-based access control (RBAC) must be built-in rather than optional; and auditable event logs must be locally accessible on the device.

FR3 (System Integrity) covers communication integrity verification and malicious-code protection — the second largest compliance workload area, and particularly challenging for embedded OT devices. Many legacy platforms lack sufficient computing resources to run real-time antivirus engines and must instead use application whitelisting or firmware signing mechanisms at the architectural level. FR7 (Resource Availability) focuses on DoS protection, backup, and recovery; in the shipboard OT context this typically means equipment must maintain basic control function availability under abnormal traffic load — safety-critical functions cannot be degraded by network load. FR6 (Timely Response to Events) is the smallest family in IEC 62443-3-3 at just 2 SRs, but requires audit logs to be accessible by shipboard or shore-side incident-response teams, which involves log format standardization and access-permission management.

Categories (I/II/III): note they live outside E27

A common misconception is to attribute CBS "categories" to E26/E27. In fact, system Categories I/II/III are defined in IACS UR E22, by failure effect: Cat I failure "will not" endanger people, ship, or environment (monitoring/informational); Cat II failure "could eventually" lead to danger (alarm and control); Cat III failure "could immediately" lead to dangerous or catastrophic situations (propulsion, steering, power control). The higher the category, the deeper the documentation, FAT witnessing, and review.

The language distinguishing the three categories is precise and important: Cat I is "will not lead to" (definitively will not), Cat II is "could eventually lead to" (may gradually lead to), Cat III is "could immediately lead to" (may lead to immediately). This language comes from E22 Rev.3's own definitions, reflecting a gradient in failure consequences along dimensions of time and certainty. For design institutes, the system category determines the zoning architecture requirements in E26 for that system's security zone. For equipment vendors, one point must be clear: CBS category does not affect the count of E27 capabilities — a Cat I administrative terminal and a Cat III propulsion controller both face the same §4.1 30 core capabilities (if neither touches an untrusted network). Category differences affect E26 zone rules and survey depth, not E27 capability thresholds.

Practical use: Type Approval vs vessel-specific survey

For equipment vendors, there are two practical paths to E27 compliance, and which path is chosen directly affects R&D investment timing and commercial competitiveness. The first is Type Approval: the vendor proactively applies to a classification society to verify, in a single exercise, that a specific CBS product model satisfies all applicable E27 capabilities (plus §3 documentation and §5 SDLC obligations), obtaining a certificate valid for approximately 5 years. Once certified, when the equipment is installed aboard a ship, it substantially reduces clause-by-clause verification work at the vessel project level — the class society has already completed a one-time product-level determination. In January 2026, RINA awarded E27 Type Approval to iOThree Limited's V.Secure system, one of the publicly disclosed examples to date.

The second path is vessel-specific compliance: for each specific vessel project survey, each CBS demonstrates satisfaction of applicable E27 capabilities on a clause-by-clause basis. This path remains viable without Type Approval, but requires substantially more documentation preparation, longer dialogue cycles with the class society, and repeated work across multiple projects. For equipment that is highly productized and planned for repeated installation across multiple ships, the upfront investment in Type Approval typically achieves "compliance cost amortization" by the third or fourth vessel project. When design institutes make product recommendations, supplier equipment carrying a valid E27 Type Approval can simplify the compliance delivery timeline for the whole ship — and this factor is increasingly treated as a positive selection criterion in newbuild project reviews.

How to use this map: first place your system's category per UR E22 Rev.3 (I/II/III), then confirm whether it connects to an untrusted network (deciding §4.1's 30 items or §4.1 + §4.2's 41 items), then work family by family against your equipment's interfaces and functions, and simultaneously prepare §3 documentation checklists and §5 SDLC deliverables. For highly productized equipment intended for repeated installation, assess the Type Approval cost-benefit ratio. For navigation or radiocommunication equipment, confirm whether the IEC 61162-460 alternative path applies. Leave the rest to formal dialogue with your class society — this map is the starting point, not the finishing line.