Maritime Cyber Resilience: Navigating IACS UR E26 and E27

A Strategic Guide for Tier 2 and Tier 3 Suppliers

1. The Shifting Market Landscape: Cybersecurity as a New Business Requirement

1.1 The July 1, 2024 Milestone

For decades, maritime equipment standards focused primarily on physical safety and environmental performance. However, the digitization of vessel operations has introduced a new dimension of risk.

On July 1, 2024, the industry crossed a critical regulatory threshold: the International Association of Classification Societies (IACS) Unified Requirements (UR) E26 and E27 officially entered into force for new vessel construction contracts.

This milestone represents a fundamental shift from voluntary guidelines to mandatory classification rules. While equipment for existing vessels may continue under previous standards, the market for new tonnage has effectively changed.

The New Baseline: Cyber resilience is no longer an optional "value-add" for premium vessels; it is now a minimum condition for classification for essential onboard systems. As fleets renew, non-compliant equipment will increasingly be viewed as a liability. Shipowners and operators are beginning to demand cyber-resilient systems to ensure asset protection and continuity of operations, regardless of specific contract dates.

1.2 The Shipyard's Perspective

To understand the pressure on suppliers, one must look at the shipyard's new responsibilities. Under UR E26, the shipyard (acting as the Systems Integrator) is now responsible for the cyber resilience of the entire vessel. They must demonstrate to the Classification Society that the ship's network is segmented, secure, and monitored.

The shipyard cannot achieve this vessel-level compliance if the individual components—the "bricks" that make up the ship—are insecure. Consequently, shipyards are pushing liability down the supply chain. They are increasingly requiring Tier 2 and Tier 3 suppliers to provide:

• Transparent Documentation: Shipyards need detailed asset inventories and topology diagrams to design their security zones.
  
  
• Integration Readiness: Suppliers who cannot define their digital interfaces or firewall requirements create a "dependency deadlock," preventing the shipyard from finalizing the vessel design.
  
  

For the shipyard, a supplier without E27 documentation represents a project risk that can delay commissioning and delivery. As a result, procurement departments are rewriting vendor contracts to mandate E27 compliance as a prerequisite for remaining on the Approved Vendor List (AVL).

1.3 Reducing Commercial Friction

In this new regulatory environment, having "Cyber Ready" products is a strategic advantage that reduces friction during the sales and delivery process.

• Simplifying Acceptance: Systems that hold a valid Type Approval (a pre-certification confirming a product meets Class requirements) for UR E27 allow for a significantly streamlined approval process. For Type Approved equipment, the shipyard and shipowner are spared from witnessing extensive cybersecurity tests for that specific component, reducing the documentation burden for every individual ship project.
  
  
• Avoiding Delays: Non-compliant documentation is a leading cause of technical queries and delays during the commissioning phase20. Providing a pre-certified, E27-compliant system positions a supplier as a low-risk partner.
  
  

Competitive Differentiation: As the industry scrambles to adapt, suppliers who can offer "plug-and-play" compliance will likely capture market share from competitors who treat cybersecurity as an afterthough. By proactively aligning with these requirements, suppliers move from being a potential compliance bottleneck to an essential partner in the delivery of cyber-resilient vessels23.

2. Does This Apply to My Product? (Scope & Definitions)

For Tier 2 and Tier 3 suppliers, the most immediate challenge is determining whether a specific component or sub-system falls under the regulatory umbrella of IACS UR E2724. The scope is deliberately broad, moving beyond traditional "IT" equipment to encompass the vast majority of Operational Technology (OT)—the hardware and software that detects or causes changes in physical processes—found on modern vessels.

2.1 Defining a "Computer Based System" (CBS)

Executive leadership often assumes cybersecurity regulations apply only to servers, workstations, or complex bridge systems. However, UR E27 applies to any Computer Based System (CBS).

The Regulatory Definition: A CBS is defined not by its interface but by its underlying technology. If your product is a "programmable electronic device" or a set of such devices that processes, stores, or transmits information, it is a CBS29.

In Practical Terms: If your equipment contains a microchip, firmware, or software, it is likely in scope. This includes:

• Programmable Logic Controllers (PLCs): Even basic controllers used for auxiliary machinery.
  
  
• Embedded Devices: Sensors, actuators, or alarm panels running embedded firmware.
  
  
• Network Equipment: Managed switches, routers, and gateways.
  
  
• Human-Machine Interfaces (HMIs): Touchscreens and display panels used for monitoring or control.
  
  

The "Black Box" Rule: You can no longer supply a "black box" without disclosing its digital composition. You must be prepared to list every software component (including Operating System and firmware versions) in a CBS Asset Inventory.

2.2 The "Air-Gap" Reality

A common misconception among manufacturers is the belief that "my system is not connected to the ship's network or the internet, so this does not apply to me". Under UR E27, being "offline" or "air-gapped" (physically isolated from other networks) does not automatically grant an exemption.

The Physical Interface Risk: The regulation recognizes that cyber incidents often originate from physical access, not just network intrusions. If your "isolated" system has a physical port—such as a USB port, Service Port, or Serial Port—used for maintenance, updates, or diagnostics, it is considered vulnerable.

Exclusion is Difficult: To be legally excluded from UR E27, a system must meet a strict set of criteria verified by a Risk Assessment. The system must:

1. Have zero IP-network connections to other systems.
   
   
2. Have no accessible physical interface ports (e.g., USB ports must be permanently disabled or blocked).
   
   
3. Be located in a physically controlled access area.
   
   
4. Not be an integrated control system.
   
   

If a service technician ever needs to plug a laptop into your device to troubleshoot it, your device effectively fails the "isolation" test and must likely comply with E27 requirements.

2.3 Essential vs. Non-Critical Systems

The stringency of the requirements depends on the function your system performs47. UR E27 targets systems where failure could endanger the ship, human safety, or the environment.

Mandatory Scope (Essential Services): If your system contributes to any of the following, E27 compliance is effectively mandatory:

• Propulsion & Steering: Engines, thrusters, steering gear50.
  
  
• Power: Generation and distribution systems51.
  
  
• Safety Systems: Fire detection, gas detection, watertight doors, bilge, and ballast systems52.
  
  
• Navigation & Communication: Radar, ECDIS, and GMDSS53.
  
  

The "Weakest Link" Scope: Even non-essential systems (e.g., a cargo monitoring unit or HVAC controller) can be pulled into scope if they are connected to the same network as essential systems54. Shipyards (System Integrators) will often demand E27 compliance from all connected vendors to prevent a non-critical device from becoming a "backdoor" into the critical vessel network.

3. Real Use Cases: Non-Critical but Mandatory Systems

For executive leadership, the most common friction point regarding IACS UR E27 is the scope. It is easy to understand why an Engine Control System needs cyber protection. It is harder to justify why a Public Address system or a Water Treatment unit requires a cybersecurity certification.

The reality is that regulatory scope is defined by potential impact, not just operational complexity. If a system's failure can endanger the ship, the crew, or the environment—or if it connects to a network that does—it falls under the mandatory requirements. Below are four real-world examples of systems often categorized as "Tier 2/3" supply that are now fully in scope.

Case A: The Public Address & General Alarm (PA/GA) System

• The System: Digital PA controllers, talk-back systems, and general alarm panels.
  
  
• Why it's Mandatory: While primarily a communication tool, the PA/GA system is a statutory safety requirement under SOLAS (Safety of Life at Sea)63. Regulations explicitly list "internal and external communication systems" as mandatory scope for cyber resilience64. If the alarm fails during a fire, lives are at risk.
  
  
• The Cyber Risk: A compromised PA/GA system can be used to trigger false abandon-ship alarms (causing panic and operational stoppage) or be silenced during a real emergency.
  
  
• Compliance Implication: You can no longer supply a simple "plug-and-play" digital panel. The system must authenticate users to prevent unauthorized personnel from accessing control menus 66and protect integrity to ensure the software running the alarm logic cannot be tampered with.
  
  

Case B: Emergency Lighting Control System

• The System: Programmable controllers for Low Location Lighting (LLL), emergency exit signs, and navigation lights68.
  
  
• Why it's Mandatory: Emergency lighting is classified as an Essential Service. Failure of these systems directly endangers human safety during an evacuation. IACS UR E26 specifically lists "Lighting (e.g., emergency lighting, low locations)" as a target system.
  
  
• The Cyber Risk: A "blackout" attack where lighting is maliciously disabled during navigation or an emergency event.
  
  
• Compliance Implication: Even if the controller is a small embedded box, it is a CBS. If the controller has a USB maintenance port, it must be physically blocked or logically disabled to prevent malware injection73. The system must also be capable of a controlled restart to a known safe state after a disruption.
  
  

Case C: Ballast Water Treatment System (BWTS)

• The System: Automated filtration and chemical treatment units used to manage vessel stability and ecology.
  
  
• Why it's Mandatory: This is a critical Environmental Safety system. A malfunction can lead to the discharge of invasive species, resulting in heavy fines and detention by Port State Control authorities. "Bilge and ballast systems" are explicitly cited in the regulations.
  
  
• The Cyber Risk: Manipulation of sensor data to hide non-compliant discharges, or ransomware entering the ship's network via a service technician's laptop connected to the BWTS.
  
  
• Compliance Implication: This is a primary vector for "supply chain" infection. If a service engineer connects a laptop to update firmware, the BWTS is considered to be interfacing with an "untrusted network". The system must have defences (like authentication) to ensure only authorised service tools can connect.
  
  

Case D: Refrigerated Cargo (Reefer) Monitoring

• The System: Remote monitoring units that track temperature, humidity, and power for refrigerated containers.
  
  
• Why it's Mandatory: While primarily commercial, failure poses a safety risk (fire from overheating units) and massive cargo loss. "Cargo handling systems" are defined as in-scope OT systems.
  
  
• The Cyber Risk: These systems are often heavily networked (IoT) to allow remote monitoring from shore. This connectivity creates a "bridge" between the external internet and the ship's internal OT network, making it a prime target for hackers trying to pivot into critical vessel systems.
  
  
• Compliance Implication: The Reefer monitoring system must be strictly segregated from the ship's navigation and propulsion networks. Strict user authentication is required to prevent unauthorized changes to temperature set-points.
  
  

4. The "Paperwork" Burden: What You Must Deliver

For Tier 2 and Tier 3 suppliers, IACS UR E27 is less about "hacking" and more about evidence. You can no longer simply ship a piece of equipment and claim it is secure; you must prove it through a rigorous documentation package. This package is the legal basis upon which the Classification Society grants approval and the Shipyard accepts your hardware. Failure to provide these four core documents is the most common reason for delays in the "Plan Approval" phase.

4.1 The CBS Asset Inventory (Software Bill of Materials)

The days of shipping a "black box" are over. Shipyards are now required under UR E26 to maintain a complete inventory of every digital asset on the vessel, and they are contractually forcing suppliers to provide the data for their specific components.

What is required: You must submit a granular list of every hardware and software component within your system93. This is not just a bill of materials; it must include:

• Hardware: Manufacturer, model, and physical interfaces (e.g., Network ports, Serial ports, USBs).
  
  
• Software: Exact versions and patch levels for the Operating System (e.g., Windows 10 IoT LTSC 2019), firmware, application software, and third-party libraries95.
  
  

Executive Insight: This inventory must be "live." If you ship a spare part or release a firmware update five years from now, you must have a process to update this document. Without this, the shipowner cannot perform the vulnerability management required by port state authorities.

4.2 The Topology Diagrams

To integrate your system into the ship's network, the Shipyard needs to understand exactly how your device communicates. You must provide two specific types of diagrams:

1. Physical Topology: A drawing showing the physical architecture—endpoints, cables, network switches, and redundant units. It must align perfectly with your Asset Inventory.
   
   
2. Logical Topology: A diagram showing the data flow. You must identify protocols (e.g., Modbus TCP, NMEA 0183), logical connections between virtual machines, and where data enters or leaves your system.
   
   

Executive Insight: Shipyards use these diagrams to design "Security Zones" (segmented areas of the network) and firewalls. If your documentation does not clearly show which ports are open and what protocols are used, the shipyard cannot integrate your system securely, leading to commissioning delays.

4.3 The "Capabilities" Document (Description of Security Capabilities)

This is your compliance scorecard. It is a document where you map your system's features to the 30 mandatory security capabilities (and 11 additional ones if connected to untrusted networks) required by UR E27106.

The Checklist: For every requirement (e.g., "User Identification," "Software Integrity," "DoS Protection"), you must explain how your system meets it.

The Strategic Loophole: Compensating Countermeasures

If your hardware cannot meet a requirement (e.g., a legacy PLC that cannot support encryption or complex passwords), you do not necessarily need to redesign the product. You can propose a Compensating Countermeasure.

• Example: "This device cannot encrypt data, BUT it is intended to be installed inside a locked cabinet (physical control) within a secure network zone (logical control)".
  
  
• Condition: You must document and prove that this alternative measure provides equivalent protection against the same threat.
  
  

4.4 The Secure Manual (Configuration & Hardening)

You must shift the "secure configuration" liability to the installer. UR E27 requires you to provide Security Configuration Guidelines and Hardening Guidelines.

What is required:

• Default Values: Explicitly state the default passwords and settings.
  
  
• Hardening Instructions: Step-by-step instructions for the shipyard or crew on how to "lock down" the device. This includes changing default passwords, disabling unused ports (e.g., "Turn off Port 80 if web access is not used"), and managing user accounts.
  
  

Executive Insight: This document is your primary defense against liability. If a cyber incident occurs because the crew left the default password active, your defense is that you provided clear, Class-approved instructions on how to change it. If you fail to provide this manual, the negligence lies with the manufacturer118.

5. The Two Paths to Certification

Under IACS UR E27, compliance is ultimately verified per vessel. However, the method by which a supplier proves this compliance varies significantly depending on whether the product is certified in advance. Suppliers must choose between two distinct regulatory pathways. This is a strategic business decision that impacts production costs and delivery timelines.

5.1 Path A: Type Approval (The Strategic Investment)

Best for: Standardized products sold to multiple ships (e.g., Engines, Alarm Systems, Communication Terminals).

Type Approval is a voluntary "pre-qualification" process. It is an upfront investment that validates your product's design against UR E27 requirements once, typically covering a 5-year period.

• The Workflow: You undergo a rigorous, one-time review by the Classification Society. This involves a full audit of your documentation and a witnessed cyber security test of your hardware at your factory.
  
  
• The Commercial Benefit: Once Type Approved, your product is effectively "pre-cleared." When a shipyard purchases your equipment for a specific vessel, you are exempted from repeating the exhaustive design review and factory acceptance testing (FAT) for cyber security for that specific ship contract.
  
  
• Why Shipyards Prefer It: Shipyards are under pressure to deliver on time. A Type Approved system represents low risk, requires less paperwork, and eliminates the scheduling headache of arranging a Class Surveyor for every component.
  
  

Executive Takeaway: Type Approval requires higher initial effort and cost but drastically reduces friction for every subsequent sale, positioning your product as "Plug-and-Play".

5.2 Path B: Case-by-Case Approval (The Tactical Fix)

Best for: One-off custom units, highly specialized equipment, or legacy products near end-of-life.

If a product does not hold a Type Approval certificate, it must prove compliance individually for every single vessel it is installed on.

• The Workflow: For every sales contract, you must submit a complete set of cyber security documents to the Class Society. Furthermore, a Class Surveyor must physically attend your factory (or the shipyard) to witness the Cyber Security Factory Acceptance Test (FAT) for that specific unit before it can be accepted.
  
  
• The Operational Risk: This pathway is operationally expensive. If a surveyor identifies a gap during the witness test, it can delay shipment. Repeatedly generating full documentation packages and paying for surveyor attendance erodes profit margins on high-volume products.
  
  
• The "Bottleneck" Factor: As regulatory deadlines pass, Class Societies are expected to experience backlogs. Reliance on case-by-case approval increases the risk that your documentation will be stuck in a review queue, delaying the shipyard.
  
  

Executive Takeaway: This path minimizes upfront R&D investment but maximizes per-unit cost and administrative burden.

Summary Comparison Table

6. Technical Requirements Simplified (The "Must-Haves")

While IACS UR E27 contains a list of 30 mandatory security capabilities, executive leadership does not need to memorize every clause. Instead, ensure your product roadmap aligns with four fundamental "Must-Have" principles.

6.1 Locking the Doors: Identification & Authentication

The era of "hardcoded" or shared passwords is over. The most common vulnerability in maritime equipment is the use of default credentials (e.g., admin / 1234) that cannot be changed. UR E27 explicitly bans this practice.

The Executive Mandate:

• No More Shared Accounts: Your system must support unique user IDs for different crew members and service technicians.
  
  
• Force Password Changes: If your device ships with a default password, the software must force the user to change it upon first login. You cannot rely on a manual asking them to do it; the system must enforce it technically.
  
  

6.2 Identifying the Product: Integrity & Version Control

Shipyards can no longer accept "Black Boxes." They need to know exactly what software is running on your hardware to manage the vessel's risk over 20+ years.

The Executive Mandate:

• Granular Inventory: Your engineering team must produce a "live" inventory list (Software Bill of Materials) that details every software component, including the Operating System and third-party libraries.
  
  
• Anti-Tamper Mechanisms: Your system needs a way to verify that the firmware or software running on it is legitimate, often achieved through "Secure Boot" or digital signatures. If a hacker tries to load malicious firmware, your device should reject it.
  
  

6.3 Checking Health: Diagnostics & Logging

A silent system is a dangerous system. Under UR E27, your equipment must be "self-aware" enough to report security issues.

The Executive Mandate:

• The "Check Engine" Light for Cyber: Your system must have a "Security Functionality Verification" feature that alerts the crew if a security function fails (e.g., "Antivirus is disabled" or "Logging has failed").
  
  
• Audit Trails: Every critical action—logging in, changing a set-point, or updating firmware—must be recorded in a log file. These logs must be stored securely so they cannot be deleted by an attacker.
  
  

6.4 Handling "Untrusted" Connections: The Service Laptop Risk

This is the single biggest hurdle for Tier 2/3 suppliers. If your equipment allows a service technician to plug in a laptop for maintenance, or if it connects to a remote monitoring gateway, it is communicating with an "Untrusted Network." This triggers a stricter set of requirements.

The Executive Mandate:

• Explicit Human Approval: A remote user (or a service laptop) cannot just "bridge" into your system. The ship's crew must explicitly approve the connection (e.g., by pressing a button) before access is granted.
  
  
• Multi-Factor Authentication (MFA): If your system allows remote access over the internet, a simple password is no longer sufficient. You must implement MFA (e.g., a token or code sent to a phone) for these connections.
  
  
• Virus Scanning: You must ensure that any laptop or USB drive connecting to your system does not introduce malware.
  
  

7. Action Plan for Decision Makers

The transition to IACS UR E27 compliance is not merely a technical update; it is a market access requirement. With the July 1, 2024 regulatory deadline now active, shipyards are actively filtering their supply chains to minimize their own integration risks.

For Tier 2 and Tier 3 suppliers, the window for "wait and see" has closed. Executive leadership must pivot from awareness to execution. The following three-step plan provides a roadmap to secure your position on the Approved Vendor List.

7.1 Immediate Audit: Define Your "Cyber Exposure"

Before allocating budget, you must determine exactly which products in your portfolio are liable. Do not rely on assumptions that your equipment is "too simple" to matter.

Actionable Steps:

1. Scan the Product Portfolio: Review your entire catalog against the IACS definition of a Computer Based System (CBS). If a product contains a programmable microcontroller, firmware, or software, it is technically in scope.
   
   
2. Map Criticality: Identify which of your products perform or support Essential Services (Propulsion, Steering, Power, Safety). These are your high-risk compliance targets.
   
   
3. Identify Connectivity: Flag any system that includes a physical interface for data exchange (Ethernet, USB, Serial). Even if intended only for maintenance, these interfaces trigger E27 requirements.
   
   
4. The "Black Box" Check: Ask your engineering team if they can produce a granular Asset Inventory (Software Bill of Materials) for these products today. If they cannot list every third-party library, you have a "documentation debt" that must be resolved immediately.
   
   

7.2 Evaluating Business Impact: Type Approval vs. Project-Specific

Once you identify the affected products, you must decide on a certification strategy. This is a financial decision: do you pay upfront (CAPEX) to streamline future sales, or pay per project (OPEX) and risk delivery delays? 

Strategic Decision Matrix:

• Scenario A: High-Volume / Standard Products: Recommendation: Pursue Type Approval (TA) immediately. Shipyards prefer TA components, and you avoid the logistical nightmare of scheduling a surveyor for every single factory acceptance test.
  
  
• Scenario B: Bespoke / Low-Volume Engineered Systems: Recommendation: Use Case-by-Case Approval. The ROI on Type Approval is low for custom one-offs. However, you must price the cost of documentation and surveyor witnessing into your commercial bid.
  
  
• Scenario C: Legacy Products (End-of-Life): Recommendation: Develop Compensating Countermeasures. If a legacy product cannot be re-engineered, qualify it with a documented "wrapper"—such as placing it behind a secure gateway that handles the security functions.
  
  

7.3 Resource Allocation: Engineering vs. Documentation

The most common point of failure for suppliers is underestimating the documentation burden. Creating the evidence required for Class approval often takes more man-hours than the software changes themselves.

Executive Directives:

1. Bridge the IT/OT Gap: Do not assign this solely to your internal IT department. IT security is different from OT resilience. Your Product Managers and R&D Leads must own the E27 compliance roadmap because it affects product functionality and safety.
   
   
2. Documentation "Sprint": Allocate resources specifically for technical writing. Your engineers need to produce Topology Diagrams and Security Capability Statements. If you lack internal capacity, consider outsourcing the "paperwork" phase to specialized maritime cyber consultancies to prevent bottlenecks.
   
   
3. Prepare for Supply Chain Transparency: Shipyards will demand to know your sub-suppliers. Prepare to enforce E27 requirements on the vendors who supply your chips and software libraries, as you are now responsible for the cyber hygiene of the components you integrate.