Is Our Product Actually Subject to UR E27?
Article 3 of a 12-Part Series on UR E27 Strategies for Marine Equipment Suppliers
※ The equipment types, product configurations, and review scenarios described in this article are illustrative examples created to explain how UR E27 applicability should be assessed.
The first question equipment manufacturers usually ask when preparing for UR E27 is: “Does our product also need to obtain UR E27 certification?” It appears to be a simple question, but in practice, it cannot be answered in a single sentence.
The presence of an Ethernet Port does not automatically mean that the same level of requirements applies to every product. Conversely, a product is not automatically excluded from review simply because it is not directly connected to an external network. Nor does an existing Type Approval, by itself, determine whether UR E27 applies.
At a minimum, the following factors must be considered together:
- The function the product performs onboard the vessel
- Whether it operates using software or firmware
- Its connections to other systems
- Its impact on the safety and continuity of vessel functions
- Its maintenance, update, and remote access paths
- The boundary between the standalone product and the complete package system
- Its relationship with the vessel's integrated network established by the shipyard
- The specific rules and approval conditions applicable to the vessel and classification society
Determining applicability is therefore not simply a matter of checking the function name shown in the product catalogue or counting the number of communication ports. It is closer to a form of system analysis that examines what role the product performs onboard, how far its connections extend, and what could be affected if the product were compromised.
IACS UR E27 addresses the cyber resilience of onboard systems and equipment. The exact scope of application and method of demonstrating conformity for an actual project must ultimately be confirmed against the applicable classification rules, shipyard specifications, and discussions with the classification society. This article explains the internal assessment that equipment manufacturers should perform before entering those discussions.
1. The First Misconception: “It Is Not Network Equipment, So It Does Not Apply”
Some manufacturers assume that UR E27 relates only to network devices such as firewalls, routers, servers, or gateways. However, the key issue in a UR E27 assessment is not the product's name. It is whether the product is a programmable device or system that performs or supports a vessel function.
Consider the following types of equipment:
- A PLC panel that controls major pumps onboard the vessel
- A monitoring unit that monitors the condition of propulsion equipment
- A sensor that measures tank level and transmits the data to the Cargo Control System
- A controller that collects fire-detection signals and generates alarms
- A gateway that collects circuit-breaker status information from the power system
- A data concentrator that receives information from navigation equipment
- An engineering workstation used to configure and maintain equipment
These are not network security devices in the conventional sense. However, they may contain firmware or application software, maintain user accounts and configuration values, exchange data with other equipment, and affect vessel functions.
This statement is therefore unlikely to provide a sufficient basis for exclusion. A more appropriate question would be:
To answer this question, the product must first be viewed not as a single product name, but as a collection of functions and components.
2. Applicability Begins with the Product's Onboard Function, Not Its Name
The importance and review scope of the same product may differ depending on the vessel function for which it is used. For example, consider the same model of industrial computer installed in three different locations.
The hardware is identical in all three cases, but the onboard function, connected systems, and assigned privileges are different. An applicability assessment should therefore begin in the following sequence:
- 1Identify the function the product performs onboard the vessel.
- 2Determine how that function relates to navigation, propulsion, steering, power, safety, fire response, cargo management, or other essential functions.
- 3Distinguish whether the product directly controls, monitors, transfers data for, or maintains that function.
- 4Assess whether the product's failure or compromise could result in loss of function, unintended operation, or incorrect indications.
An important point is that a product should not be excluded merely because it “does not directly control” a vessel function.
A vessel function may still be seriously affected if incorrect data is displayed to the operator, an alarm is suppressed, or a gateway carrying control commands is manipulated.
3. The Second Question: Is the Product a Programmable Device or System?
The next step is to determine whether the product contains logic or data that can be modified. Typical components include:
- PLCs, controllers, and embedded computers
- Operating systems
- Firmware
- Application software
- Communication configuration files
- User accounts and privilege information
- Operational parameters and configurations
- Scripts, databases, and web interfaces
- Software update or firmware upload functions
A product name alone is not sufficient to distinguish a simple mechanical component from a computer-based system. For example, a conventional pressure sensor may simply convert a measurement into an electrical signal. A smart sensor, by contrast, may contain firmware, configurable settings, digital communications, diagnostic functions, and an update interface. Both products may be described as sensors, but they do not require the same level of cybersecurity review.
| Category | Conventional Sensor | Smart Sensor |
|---|---|---|
| Main operation | Measures a physical value and outputs an analogue signal | Measures, calibrates, diagnoses, and transmits digital data |
| Internal software | None, or only fixed basic logic | Includes firmware and modifiable settings |
| Communication | One-way signal such as 4–20 mA | May support Ethernet, fieldbus, or wireless communication |
| Configuration changes | Local mechanical adjustment | Changes through a dedicated tool or network |
| Update | Generally not applicable | Firmware update may be possible |
| Cyber impact | Potentially limited | Configuration manipulation, update misuse, or communication compromise may be possible |
However, the fact that a product is a smart sensor does not automatically mean that it must obtain independent UR E27 certification. It is also necessary to determine which system includes the sensor, who implements the security functions, and at what level conformity will be demonstrated.
Programmability is therefore an important starting point for assessing applicability, but it is not the final conclusion.
4. The Third Question: What Does the Product Connect To, and for What Purpose?
Manufacturers often record only the product's primary Ethernet connections as network interfaces. In practice, however, the cybersecurity boundary extends beyond Ethernet ports. Connection paths that should be examined include:
- Ethernet connections to the vessel's integrated network
- Serial or fieldbus communications with other controllers
- Wi-Fi, Bluetooth, and cellular communications
- USB, SD cards, and other removable media
- Maintenance laptop connection ports
- Manufacturer-specific diagnostic interfaces
- Routers, modems, or gateways used for remote access
- Paths used to introduce software update packages
- Connections to supplier clouds or shore-based support centers
- Dry contacts and digital signals received from other equipment
Not all connection paths carry the same level of risk. It is therefore insufficient to record them simply as “connected” or “not connected.” For each interface, the following information should be confirmed:
- The connected system
- Communication direction
- Protocols and ports used
- Data or commands exchanged
- Authentication and access-control methods
- Whether the connection is continuous or activated only when required
- Whether it passes through an external or untrusted network
- Functions that can be modified through the interface
- The impact of connection failure or data manipulation
- The party responsible for managing the interface
- 1The control panel was connected to the vessel's Automation Network.
- 2An upper-level server on the Automation Network was connected through a firewall to the vessel's IT Network.
- 3During maintenance, a service engineer's laptop was connected to the panel's service port.
- 4Firmware update files were introduced through a USB storage device.
- 5For emergency support, an engineer could connect through a remote access gateway provided by the shipyard.
When only direct connections were considered, the panel appeared to be standalone equipment. Once the complete communication and maintenance paths were traced, it was found to be connected to the vessel network, maintenance laptops, USB devices, and the remote support environment.
An applicability assessment must therefore consider indirect and temporary connections as well as direct ones.
5. Claims That a Product Is “Air-Gapped” Also Require Verification
Air-gap is a strong term implying complete physical separation. In practice, however, it is often used loosely to mean that the product does not maintain a continuous connection to an external network. If any of the following paths exist, it may be difficult to describe the product as air-gapped in the strict sense:
- Software updates performed through USB
- Temporary connections by a maintenance laptop
- Onsite diagnostics performed by the manufacturer's engineer
- Log extraction using portable storage
- Parameter configuration using a shared laptop
- Temporarily installed remote access equipment
- An upper-level monitoring system connected to another zone
- Restoration of configuration files following hardware replacement
For example, consider a standalone boiler controller that is not connected to an external network during normal operation. If a service engineer periodically connects a laptop to change settings and install firmware updates, that laptop and the update files effectively become external data-introduction paths to the controller. In this case, the review should not be limited to network firewalls.
- Can only authorized service laptops be connected?
- Is use of the service port physically or logically restricted?
- Are the source and integrity of the update package verified?
- Are the technician's account and privileges appropriately separated?
- Are configurations recorded before and after the change?
- Are logs retained so that the work performed can be traced?
- Is there a procedure to prevent the introduction of infected laptops or manipulated files?
Access control, secure updates, removable media management, and configuration management may therefore remain important even for products without continuous network connections.
6. The Fourth Question: What Happens to the Vessel Function If the Product Is Compromised?
When assessing the importance of a product, the consequences of failure or compromise matter more than the product's price or physical size. It is useful to distinguish the following four types of consequences.
The product stops or becomes unavailable. For example, a failure of the Power Management Controller may prevent normal generator load sharing.
Rather than simply stopping, the product outputs an incorrect control command. For example, a Valve Control Unit may receive an unauthorized command that causes a valve to open or close.
The physical equipment may continue to operate correctly while incorrect status information or alarms are displayed to the operator. For example, manipulated values from a Tank Level Monitoring System could cause the operator to make an incorrect loading or transfer decision.
Even if the product's own function is not essential, an attacker may use it as a path to access other systems. A Data Collection Gateway used for performance analysis may not issue control commands directly, but it may still be an important device connecting trust boundaries if it is positioned between the OT Network and a shore-based cloud.
These impacts are difficult to assess by reviewing the product in isolation. They should be examined in conjunction with the overall vessel architecture known to the shipyard or system integrator. At a minimum, an equipment manufacturer should be able to answer the following questions:
- “What stops if our product becomes unavailable?”
- “Who could make an incorrect decision if our product's data were manipulated?”
- “Which settings or connected systems could be changed if our product's administrator privileges were compromised?”
- “Could compromise of our product create a path to other onboard systems?”
The answers provide a basis for discussing the product's scope of application and the level of requirements that should be applied.
7. The Fifth Question: Where Does the ‘Product’ Boundary End?
One of the most frequent sources of confusion in UR E27 implementation is the system boundary. This is because the product name used by the manufacturer often does not match the actual project supply scope. For example, even if a shipyard orders a “Cargo Monitoring System,” the actual supply may include:
- Main Server
- Operator Workstation
- PLC or Remote I/O
- Ethernet Switch
- Serial Gateway
- Printer
- Engineering Laptop
- Remote Access Router
- Backup Storage
- Third-Party Database
- Antivirus / Whitelisting Software
- Dedicated Network inside the Cabinet
- Interface to the shipyard's upper-level Network
The manufacturer may have developed only the application software and PLC logic. What is delivered to the shipyard, however, is a package system integrating multiple components. This gives rise to the following boundary questions:
- Is the third-party switch included within the product's certification scope?
- Who configures and tests the firewall provided by the shipyard?
- Is the engineering laptop part of the delivered product or only temporary test equipment?
- Is the remote access router a standard product component or a project option?
- Who performs operating system hardening for the server — the manufacturer or the shipyard?
- Where is cybersecurity responsibility divided at the interface to the vessel's upper-level network?
- Who manages vulnerabilities and updates for third-party components?
If the certification boundary is determined only by the product name, some components may be omitted from the review. Conversely, the manufacturer may be assigned responsibility for areas of the vessel that it cannot control.
8. It Is Useful to Divide the System Boundary into Three Layers
The following three scopes can be distinguished to clarify the product boundary.
The scope designed by the manufacturer and placed under its direct configuration and change control. Examples: proprietary application, PLC logic, base hardware, firmware, standard product interfaces, internal product accounts and log functions.
The complete package actually supplied for a specific vessel project. Examples: customer-specific gateway, project-specific software, third-party switch, operator workstation, remote support option, interfaces added at the shipyard's request, specific OS/patch/application versions.
The scope covering the vessel-wide network and other systems configured by the shipyard or system integrator. Examples: vessel backbone network, firewalls between zones, integrated remote access system, vessel-wide time synchronization, central log server, integration with other equipment, cybersecurity rack or integrated security-management environment.
Applying this three-layer boundary model makes the allocation of responsibility for each review item clearer.
| Review Item | Manufacturer | Joint | Shipyard |
|---|---|---|---|
| Internal product accounts and privileges | ● | ||
| Disabling unnecessary internal product services | ● | ||
| Security logs generated by the product | ● | ||
| Method for forwarding logs to an upper-level server | ● | ||
| Product interfaces and permitted communications | ● | ● | |
| Firewall policies between zones | ● | ● | |
| Vessel-wide remote access gateway | ● | ● | |
| Provision of product software updates | ● | ||
| Approval process for updates onboard the vessel | ● | ● | |
| Vessel-wide network recovery strategy | ● | ● |
Joint-responsibility items require particular attention. Unless responsibilities are clearly defined in advance, disputes may arise later in the project, with one party stating, “We understood that the shipyard would provide that function,” while the other responds, “We expected it to be implemented within the product.”
9. Practical Case 1: Is a Simple Communication Converter Outside the Scope?
Consider a small gateway that converts serial signals to Ethernet. The device has no operational display and does not generate control commands directly. The manufacturer may describe it as follows:
Further review may nevertheless be required if the device:
- Is installed between the Propulsion Control System and Integrated Automation System
- Provides a web-based administrator interface
- Has a default administrator account
- Supports remote firmware updates
- Allows communication-target IP addresses and ports to be changed
- Supports bidirectional communication
- Causes the exchange of status information and commands between the two systems to stop if it fails
Under these conditions, the gateway is not merely an accessory. It forms a conduit between two systems and can control or modify the communication flow. At a minimum, the following should be examined:
- Administrator authentication and privileges
- Handling of default accounts
- Disabling unnecessary protocols and services
- Configuration backup and restore
- Integrity of firmware updates
- Security events and configuration-change logs
- Permitted communication paths
- Fail-safe behavior following a failure
- Known vulnerabilities and the support period
A product may be small and inexpensive, while still performing an important role at the system boundary.
10. Practical Case 2: Does Using an Approved PLC Make the Entire Panel Compliant?
Consider a control panel manufacturer using a PLC and switch that have received UR E27-related approval. The manufacturer may assume that the complete panel also satisfies the requirements because approved components have been used. The actual panel, however, includes additional design elements:
- PLC application logic
- User account and password settings
- Network address and routing settings
- Switch VLANs and management accounts
- HMI application
- Remote maintenance software
- Update procedures using USB
- Interface to the shipyard's upper-level network
- Backup and recovery methods
A component certificate may demonstrate that the PLC or switch was assessed under a defined product configuration and approval scope. It does not automatically demonstrate the accounts, network settings, applications, interfaces, and maintenance procedures established by the panel manufacturer. Differences between the approved components and the final supplied system may arise where:
- The approved firmware differs from the firmware actually delivered
- A service disabled during certification is enabled for the project
- Customer-specific logic is installed on the PLC
- Remote access software outside the certification scope is added
- Multiple approved products are connected without verifying system-level communication controls
- Backup is possible only for individual devices, with no recovery procedure for the complete panel
Using approved components is therefore an important starting point, but a separate review of the boundary, design, configuration, and testing of the assembled system may still be required.
11. Practical Case 3: Is the Manufacturer Free of Responsibility If the Shipyard Provides Remote Access?
Consider a product with no direct internet connection, where remote support is provided through a common remote access gateway installed by the shipyard. The shipyard may be responsible for establishing the gateway and protecting the connection outside the vessel. This does not, however, remove all responsibility from the equipment manufacturer. The manufacturer may still need to explain:
- The exact product interface accessed remotely
- The accounts and privileges used for remote work
- The functions a service engineer can perform
- Conditions under which remote access is permitted
- Connection and change logs generated within the product
- Handling of sessions and temporary accounts after disconnection
- Approval and recovery methods for software and configuration changes
- The impact of failed remote work on operational functions
- How remote access can be blocked at the product level during an emergency
For example, even if the shipyard's gateway provides multi-factor authentication and connection approval, product-level access control may remain insufficient if the remote engineer uses a shared administrator account with authority to modify every safety-related setting. Conversely, even strong account controls within the product will not complete the overall control framework if the shipyard's remote access path lacks approval, recording, and termination functions.
Remote access is a representative shared-responsibility area where product design and vessel integration meet.
12. A Practical Seven-Step Process for Determining Applicability
Equipment manufacturers can conduct their internal assessment in the following sequence.
Identify the hardware and software, including: controllers, servers, workstations, and network equipment; OS, firmware, applications, and PLC logic; third-party software; engineering and maintenance tools; removable storage devices included in the supply; optional or customer-specific components.
Output: the product component list and the initial baseline.
Classify the role of each component: direct control; condition monitoring and alarms; data collection, conversion, and transmission; support for safety functions; user operation; maintenance and configuration changes; software updates; remote support; backup and recovery.
Describe functions from the perspective of actual vessel operation, not catalogue wording.
Include temporary connections and physical media as well as continuous network connections: connected system, communication direction, protocol, data or commands, connection purpose, authentication method, trust level, activation conditions, impact of failure or compromise.
Factual information per interface is more useful than a general statement such as “no external connection.”
For each product or component, assess the impact if it: becomes unavailable; outputs an incorrect command; displays incorrect information; has its settings or software modified; is used as a path to compromise another system.
This helps determine the product's direct and indirect impact on vessel functions.
Separate: the scope directly controlled by the manufacturer; the scope requiring agreement with the shipyard; the scope provided through the vessel's common design.
The objective is not to avoid responsibility, but to determine where each requirement must actually be implemented and verified.
For each potentially applicable requirement, distinguish whether: both the product function and evidence exist; the function exists but documentation or test evidence is insufficient; the requirement can be satisfied through a configuration change; product development is required; the requirement must be satisfied through the shipyard's integrated design; a compensating control or separate agreement is required; the requirement does not apply, and a rationale can be provided.
“Not applicable” should not be left blank — it should be supported by a documented rationale.
Based on the internal review, clarify: the final scope of the product or system; the unit at which conformity must be demonstrated; the allocation of responsibilities between shipyard and manufacturer; the extent to which existing certificates will be accepted; whether additional testing or project-specific verification is required; available demonstration routes (TA, SoC, or SoF); common security controls to be provided at vessel level; the method for approving exclusions or compensating controls.
The internal assessment is not the final ruling — it is the technical preparation needed for an accurate discussion with the shipyard and classification society.
13. A Practical Applicability Assessment Table
A simple table such as the following can be used during the initial review.
| Assessment Area | Question to Confirm | Example Finding | Follow-Up Action |
|---|---|---|---|
| Vessel function | What vessel function does the product perform or support? | Cargo valve monitoring and control | Confirm relationship with essential functions |
| Programmability | Does it contain software, firmware, or modifiable logic? | PLC logic and HMI application present | Establish the version baseline |
| Network connection | Does it communicate with other systems? | Bidirectional Ethernet communication with IAS | Identify ports, protocols, and data flows |
| Temporary access | Is there a maintenance access path? | Service laptop and USB used | Review access and media controls |
| Remote access | Can the product be accessed from shore? | Possible through the shipyard's common gateway | Agree on shared responsibilities and approval procedures |
| Impact of compromise | What happens if the product is manipulated or unavailable? | Incorrect valve commands may be issued | Verify control privileges and fail-safe behavior |
| Product boundary | What is included in the actual delivery scope? | PLC, HMI, switch, and gateway included | Finalize the supply configuration |
| Third-party components | Are external components or software included? | Commercial OS and industrial switch included | Obtain approval, vulnerability, and support information |
| Existing approval | Does the existing certificate cover the actual configuration? | Gateway and modified software not included | Confirm the approval scope with the classification society |
| Evidence | Are design, configuration, and test records available? | Only a functional description exists; no test results | Prepare test procedures and records |
| Responsibility allocation | Which requirements are satisfied through common vessel controls? | Central firewall and remote access provided by shipyard | Agree on interface requirements |
| Conformity route | At what level and through which method will conformity be demonstrated? | Project-specific SoC may be required | Consult the shipyard and classification society early |
The purpose of this table is not to mark every item immediately as “yes” or “no.” It is more important to distinguish verified facts, unresolved matters, and items requiring agreement with other parties. This enables the manufacturer to reflect uncertainty in the contract conditions, schedule, and technical plan.
14. Five Statements That Require Particular Caution
Making any of the following statements before completing an applicability review may increase risk later in the project.
→ Direct connections are not the only concern. Upper-level systems, service laptops, USB devices, and temporary remote access paths must also be examined.
→ The impact of incorrect indications and missing alarms on operator decisions must be assessed.
→ The component approval scope must be compared with the actual panel's applications, settings, interfaces, and supply configuration.
→ Even if the shipyard provides the common firewall and remote access environment, product-level accounts, privileges, logs, updates, and hardening may remain the manufacturer's responsibility.
→ If the product scope and functional gaps are identified for the first time during document preparation, design changes and the test schedule may be affected.
A more appropriate response would be:
This is not an attempt to avoid answering whether UR E27 applies. It clearly identifies the assessment process and the parties with whom agreement is required.
15. Conclusion: Before Deciding Whether UR E27 Applies, Define What Constitutes the Product
To answer the question, “Is our product subject to UR E27?”, the product itself must first be clearly defined.
- What function does the product perform onboard the vessel?
- Which hardware and software components does it contain?
- Which systems does it connect to?
- What are its temporary access and update paths?
- Which vessel functions could be affected if it were compromised?
- How does the standard product differ from the project-specific supply configuration?
- Where does the manufacturer's responsibility end?
- Where does the product meet the shipyard's integrated security controls?
- To what extent does the existing certificate cover the actual delivery configuration?
Drawing a conclusion that the product “applies” or “does not apply” without answering these questions creates two possible problems. If an applicable product is incorrectly excluded, product modifications and additional testing may be required later in the project. Conversely, if system-level requirements are applied indiscriminately to individual components, unnecessary development and certification costs may result.
The objective of an applicability assessment is therefore not to include as many products as possible within the certification scope — or to exclude as many as possible. The key is to determine three matters accurately:
- 1What should be treated as a single product or system?
- 2Which requirements must be satisfied within that product?
- 3Which requirements must be satisfied jointly through the vessel's integrated design?
Only after these boundaries have been established does a requirement-by-requirement gap analysis become meaningful. The manufacturer can then distinguish the scope covered by existing certificates, the scope requiring additional development, and the scope requiring project-specific verification.
Applicability is not an administrative decision based solely on whether a certificate exists. It is an engineering decision that defines the product's functions, configuration, connections, and responsibility boundaries.
Once a product's applicability is confirmed, the next question is how to demonstrate it.
Article 4 will examine what distinguishes Type Approval (TA), Statement of Compliance (SoC), and Statement of Fact (SoF) as routes for demonstrating UR E27 conformity, and how a manufacturer should decide among them.
Related Reading:
- Chapter 4: Understanding Why IACS Introduced E26 and E27 — The Purpose Behind the Requirements
- Is a SoC-Centric Approach Enough for Ship Cybersecurity? — Statement of Compliance vs. Type Approval
- Anatomy of a Ship ZCD — Understanding the Building Blocks of an IACS UR E26 Zone and Conduit Diagram
- Why Most Ship ZCDs Fail — Seven Common Mistakes in IACS UR E26/E27 Projects
IT/OT Integrated Cybersecurity specialist with expertise in IACS UR E26/E27 compliance, N2SF, Cybersecurity Strategy & Governance, BPR, and Digital Transformation. Former IT Consultant at KPMG (2019–2022). M.S. Information Systems, University of Maryland, Robert H. Smith School of Business.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment