UR E27 Is Already in Effect — So Why Do Marine Equipment Manufacturers Still Feel So Little Urgency?
Article 1 of a 12-Part Series on UR E27 Strategies for Marine Equipment Suppliers
The International Association of Classification Societies (IACS) Unified Requirement E27 began applying to applicable ships whose construction contracts were signed on or after 1 July 2024. Judging by the timeline alone, marine equipment manufacturers might be expected to have already made significant preparations. Yet this is not necessarily what we see in practice.
Some manufacturers are working with classification societies to prepare for Type Approval. Others are considering a Statement of Compliance or Statement of Fact for specific products or projects. At the same time, many have yet to begin any meaningful preparations, largely because they have not received specific requirements from shipyards.
These views are not entirely unreasonable. Although UR E27 is already in effect, not every shipbuilding project or equipment manufacturer will experience the same level of demand at the same time. The problem arises when the absence of visible requirements today is interpreted to mean that no such requirements will emerge in the future. The current quiet period may not be evidence that UR E27 will have only a limited impact. Instead, it is more likely to be a transitional phase in which shipyards and classification societies are building experience and developing more specific review criteria and procurement conditions.
Why Does the Market Still Seem Quiet Even Though UR E27 Is in Effect?
The introduction of a new requirement does not mean that its impact will immediately reach every level of the supply chain. After a shipbuilding contract is signed, a project moves through a lengthy process that includes basic design, detailed design, equipment selection, approval drawing submission, production, FAT, delivery, and integration onboard the vessel. As a result, there can be a significant time lag between the reference date that determines whether UR E27 applies and the point at which an equipment manufacturer receives actual requirements.
For example, even after the construction contract for a UR E27-applicable vessel has been signed, time is still needed to finalize the equipment specifications and select suppliers. Once suppliers have been selected, the shipyard must work with the classification society to clarify the scope of application and required submissions before detailed requirements can be passed down to equipment manufacturers. Therefore, the fact that a manufacturer has not yet received a formal request does not mean that no UR E27-applicable projects exist. Such projects may already be underway, while the requirements have simply not yet reached that stage of the supply chain.
In early implementation projects, stakeholders may also differ in how they interpret the requirements and how prepared they are to address them. Shipyards are discussing the scope of application with classification societies, while classification societies are refining their review criteria by applying the requirements to actual products and systems. Equipment manufacturers, meanwhile, are still determining how UR E27 applies to individual products and what response strategy would be appropriate. During this transition, requirements may be communicated in different forms from one project to another. One shipyard may specify cyber resilience requirements in its purchasing specification. Another may include related documentation in a technical questionnaire or Vendor Document Requirement. In another project, the detailed requirements may not become clear until classification comments are issued after approval drawings have been submitted.
What Does It Really Mean That There Have Been No Problems So Far?
Many equipment manufacturers assess the urgency of preparation based on their delivery experience to date. If they have continued to supply existing products without receiving significant comments from shipyards, and classification approvals have proceeded without major difficulty, postponing UR E27 preparation may appear reasonable.
Past delivery performance, however, does not guarantee future compliance. First, previously delivered vessels may not have been subject to UR E27. Even when the shipyard and product are the same, the applicable requirements may differ depending on the vessel's construction contract date and other application conditions. Even if a product has already been supplied to a UR E27-applicable vessel, the requirements may have been communicated only to a limited extent during the early projects. As shipyards and classification societies developed practical experience, some issues may have been addressed through project-specific supplementary measures or additional documentation.
The fact that no separate certificate has been requested so far also does not mean that cybersecurity evidence will not be required. Depending on the product scope and project conditions, manufacturers may be asked to provide descriptions of security functions, network architecture, interface information, user and account management methods, logging capabilities, backup and recovery procedures, remote access controls, test results, or vulnerability management procedures — in addition to, or instead of, a certificate.
Requirements Become More Specific as Experience Grows
During the early stages of a new regulation, attention tends to focus on the wording of the regulation itself. As practical implementation experience accumulates, however, the focus gradually shifts toward specific products and supporting evidence. At first, discussions may center on questions such as:
- Is this equipment subject to UR E27?
- Should it be considered a Computer-Based System?
- How is it related to the vessel's Essential or Important Functions?
- Where is the boundary between the individual product and the integrated system?
As implementation experience grows, the questions become more specific.
- Have all external interfaces of the product been identified?
- How are user accounts and privileges managed?
- How are unnecessary Ports and Services controlled?
- Can security-related Events and Logs be generated and retained?
- Have Backup and Restore functions actually been tested?
- Under what conditions is remote access permitted, and how is it recorded?
- How does a change in the product version affect the existing approval scope?
- How does the supplier manage vulnerabilities and security updates?
At this stage, it is no longer sufficient to say, "Our product includes standard security features." Manufacturers must demonstrate, with supporting Evidence, which functions have been implemented, which parts of the product they apply to, how they are configured, and how they have been tested.
As shipyards gain experience, they are also likely to incorporate the requirements more explicitly into contracts and procurement procedures. Requests for quotation may ask whether UR E27 applies and what approval status has been achieved. Technical evaluations may review certification plans and available submission documents, while supplier selection processes may compare the response capabilities of competing manufacturers.
Classification society reviews will likely follow the same direction. As recurring issues and commonly required documents are identified across multiple projects, review items are expected to become more detailed, consistent, and standardized.
The change experienced by equipment manufacturers may therefore not occur all at once on the regulation's effective date. It may begin with a few technical questions and requests for additional documents, but over time, these requirements are likely to become established as procurement conditions, approval procedures, test items, and supplier evaluation criteria.
The Real Risk Is Not Simply the Absence of a Certificate
When a company is unprepared for UR E27, the first risk that often comes to mind is being unable to deliver a product because it lacks the required certificate. In reality, however, the risks facing equipment manufacturers are much broader.
During the sales stage, the company may be unable to provide clear answers to customer questions.
- Does UR E27 apply to our product?
- What approvals or verification records have we already obtained?
- If additional measures are required, how much time and cost will they involve?
- Is the version to be supplied identical to the version covered by the approval?
If the answers to these questions are unclear, a shipyard may regard the product as a higher project risk — even if its price and functionality are competitive.
During the technical stage, inconsistencies may emerge between the actual product architecture and the submitted documentation. Sales materials may claim that security functions are available, while the development team may be unable to explain exactly how those functions operate or provide the corresponding test results. Some interfaces may be missing from the network architecture diagram, or the actual product configuration may differ from what is described in the manual.
During the project stage, additional reviews and corrective actions may create significant schedule pressure. If approval documents must be rewritten, the product design modified, or additional testing performed, the already confirmed FAT schedule and delivery date may also be affected.
From a management perspective, the company may face unplanned development costs, testing expenses, classification-related costs, and project delay costs. If key development personnel must be reassigned to an urgent response, the schedules of other products and projects may also suffer.
In Part 2, we will examine the sequence in which these risks may unfold in an actual project through a hypothetical shipbuilding scenario.
Why Might It Be Too Late to Start Preparing After a Requirement Is Received?
If UR E27 compliance is viewed merely as a documentation exercise, it may seem reasonable to wait until a shipyard makes a formal request. In practice, however, effective preparation requires coordinated action across multiple areas of both the product and the organization.
The first step is to establish the product's scope and configuration. This includes identifying the hardware, operating system, firmware, application software, network interfaces, and external integration functions. The operating environment and the boundaries of responsibility between the product and other systems must also be clearly defined.
Next, the company must analyze the gaps between the requirements and the current product. It must determine how fully functions such as account management, access control, communication protection, logging, malware protection, Backup and Restore, remote access, and security configuration have been implemented.
If gaps are identified, changes to the product design and software may be necessary. The modified functions must then undergo development and integration testing, while the relevant manuals and test procedures must also be updated. Procedures are also needed to control the product configuration and version and to ensure that the same approved configuration is consistently applied to production units.
Activities such as vulnerability management, security updates, and change management cannot be completed simply by adding product functions. The roles and procedures of development, quality, service, and management systems must also be defined. All of this takes time.
By the time a shipyard requests formal documentation, the product specification and delivery date may already have been fixed. Classification submission deadlines and the FAT schedule may also have been established. If product analysis and design changes only begin at this point, even technically feasible measures may be difficult to complete within the project schedule. The reason to start early is not to obtain TA for every product without exception. It is to preserve a range of viable response options when requirements arise.
Preparing Now Does Not Mean Applying for TA Immediately
When the urgency of UR E27 is emphasized, some companies may feel pressured to pursue TA immediately for every product. That is not the point.
The appropriate response method will vary depending on the nature of the product and the company's business model. If the same standardized product is repeatedly supplied to multiple vessels and shipyards, TA may be an effective option. On the other hand, if a product is heavily customized for each customer or limited to a specific project, an approach centered on SoC, SoF, or individual project approval may be more practical.
Not every product is subject to UR E27 to the same extent. Applicability must first be assessed based on the product's functions, network connectivity, method of integration with the vessel's systems, and relationship to Essential or Important Functions. Preparing now therefore does not mean deciding on a certification method first.
The starting point is to gather the following basic information in advance.
- What is the exact scope and configuration of our product?
- What network connections and external interfaces does it have?
- What function does the product perform onboard the vessel?
- What cybersecurity functions are currently implemented?
- Do the relevant design documents and test Evidence exist?
- How are development, configuration management, and vulnerability management procedures operated?
- To what extent is the product supplied repeatedly, and how much customer-specific Customization is involved?
- What matters should be clarified with the shipyard and classification society in advance?
Once this information has been collected, the company can assess whether UR E27 applies to the product, analyze the gaps between the current state and the applicable requirements, and select an appropriate certification or conformity-demonstration route. Without this basic information, it is difficult to estimate the schedule and cost of any route — whether TA, SoC, or SoF — with confidence.
Where Does the Difference Between Prepared and Unprepared Manufacturers Become Visible?
Being prepared does not mean that every product has already been certified. A prepared manufacturer is one that can explain the status of its product when a customer asks. It has assessed the potential applicability of UR E27, identified the product scope and version, and understands both the implemented security functions and the remaining gaps. It can propose an appropriate certification or project-specific response route and explain the preparation period required and the information the customer must provide. Its design and test information is not scattered across individual files or dependent on the memory of particular employees. Network architecture, interfaces, security requirements, test results, and change histories are managed in a connected and traceable manner.
An unprepared manufacturer, by contrast, begins assessing applicability only after receiving a request. The sales team asks the development team for answers, the development team searches for historical product records, and the quality team belatedly checks whether existing procedures satisfy the requirements. Even with the same product and the same requirements, the outcome will differ depending on the level of preparation.
A prepared manufacturer can review the requirements and propose viable response routes and schedules. An unprepared manufacturer repeatedly says, "We will check and get back to you." As the response is delayed, the shipyard may begin to question not only the product's technical suitability but also the manufacturer's ability to meet the delivery schedule and execute the project.
The First Preparations Equipment Manufacturers Should Begin Now
The starting point for a UR E27 response is not completing a certification application.
These preparations can begin even before the final certification route is selected. In fact, this information is necessary to develop a realistic certification strategy.
Use the Current Quiet Period as Preparation Time
The impact of UR E27 will not reach every equipment manufacturer on the same day or in the same form.
Some manufacturers may first encounter the requirements during the quotation stage. Others may become aware of the issue through classification comments after submitting approval documents. Still others may discover just before FAT that their products lack the necessary security functions or test Evidence.
The important point is not to predict exactly when the requirements will emerge. It is to be ready to explain the product's status, address any gaps, and propose a realistic response route when they do.
The fact that shipyard and classification society requirements are not yet specific does not mean that preparation is unnecessary. On the contrary, this may be the most flexible period in which to analyze product architecture, organize internal information, and improve the necessary functions and procedures.
Once a project has begun, every decision becomes linked to schedule and cost. If preparations start before specific customer requirements emerge, however, the necessary activities can be incorporated gradually into product development plans and internal operations.
The key concern in responding to UR E27 is not simply the absence of a certificate. It is being unprepared to explain and demonstrate product conformity when customers and classification societies begin asking questions.
The fact that no significant problems have arisen so far does not guarantee that none will arise in the future. Nor does the current lack of frequent requests mean that preparation can safely be postponed. The present quiet period does not necessarily mean that the market has yet to move. It may instead be the preparation window available before the requirements become firmly established throughout the supply chain.
In the next article, we will use a hypothetical scenario to examine what can happen when an unprepared product is selected for an actual shipbuilding project.
How can unclear answers during the quotation stage lead to repeated classification comments, product redesign, retesting, FAT delays, and additional costs?
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.
Field Note — Blue Horizonist
The article's diagnosis is accurate. The reason equipment manufacturers haven't moved despite time passing since UR E27 came into effect isn't laziness — it's the significant time lag between when requirements are written into shipbuilding contracts and when they actually reach manufacturers down the supply chain. The further down the chain, the stronger the illusion that "it's not our turn yet." The danger is treating this quiet period as a grace period rather than a preparation window.
The most dangerous assumption in practice is "we've had no problems so far." If you sailed through earlier E27 projects where requirements weren't clearly passed down, that likely means project-by-project workarounds — not systematic compliance. When formal requirements arrive, there's no documentation ready, you start by excavating past records, and by that point your options are already constrained by a locked schedule and budget.
The essence of the preparation framework is: move before you're asked.
A common misconception in practice:
"We haven't received a formal request yet, so there's no need to prepare." A late-arriving requirement isn't an exemption — it's a time lag. Failing to use that lag for preparation means you'll have no flexibility when the request finally arrives.
Key practical takeaways:
- Document your current product's scope, configuration, network connections, interfaces, and software versions based on actual hardware first.
- Prioritize recurring delivery items, network-connected systems, and products tied to essential vessel functions.
- Before any formal request arrives, confirm with stakeholders: applicable vessels, integration scope, approval format, documentation requirements, versions, and schedule.
⚓ Join the ShipPaulJobs Community
Join →
Great insights on UR E27. The key is moving beyond certification toward continuous cybersecurity readiness and evidence management throughout the product lifecycle.
ReplyDeleteExcellent practical perspective. UR E27 readiness is not simply about obtaining a certificate, but about being able to explain, demonstrate, and maintain evidence of cybersecurity throughout the product lifecycle. Early preparation can make a significant difference.
ReplyDelete