UR E26, After the Mandate ⑤ — The Vendor's View: The Economics of Certification and the Paradox of Integration
The Vendor's View — The Economics of Certification and the Paradox of Integration
How do you get a single product certified against the differing criteria of multiple class societies, while still making it bind well with other systems?
- LinkedIn : https://www.linkedin.com/in/abysstoinfinity
The fifth installment of a six-part series — and the fourth stakeholder piece (the vendor). Where Part 4 looked from the position of binding certified boxes into a single ship (the shipyard), this piece looks from the position of making those boxes and getting them certified. The vendor is the smallest unit of integration — and the root from which the integration challenges we saw in Part 4 begin.
1. The Smallest Unit of Integration
In Part 4, we said the shipyard binds certified boxes into a single ship. Then who is the party that makes those boxes and gets them certified? The primary addressee of E27 is precisely them: the vendor. If E26 deals with the vessel as a whole, E27 deals with the security capabilities of the individual computer-based systems (CBS) that make up the vessel — and implementing those capabilities in a product and obtaining type approval is the vendor's share of the work.
The vendor is the smallest unit in this value chain. But small does not mean simple. On the contrary, the roots of the integration challenges we saw in Part 4 — the problem of broken handshakes, the problem of systems certified as "cannot connect to untrusted networks" — begin exactly here, in the design and certification of individual products. If the owner in Part 2 asked "what to buy," the class society in Part 3 asked "what to assure," and the shipyard in Part 4 asked "how to implement," the vendor's question is the most fundamental of all —
How do you get a single product certified against the differing criteria of multiple class societies, while still making it bind well with other systems?
2. What E27 Demands of the Vendor — A Cultural Shift Toward Security by Design
Let us start with the content of the demand. E27 requires that an individual CBS possess 30 core security capabilities, plus 11 additional capabilities if it is to be connected to untrusted networks. Concretely, this includes authentication, access control, encrypted communication, audit logging, the ability to receive security updates, and operational elements as well — a vulnerability disclosure policy, a security update process, and an end-of-life schedule. Looking at actual type approval certificates, the product must be accompanied by documents such as secure development lifecycle (SDLC) guidance, configuration management procedures, security configuration guidelines, and test procedures — for example, the documentation submitted when Kongsberg Maritime's K-Chief and K-Safe automation systems received E27 type approval from DNV at security profile 1.
The key point here is that these are capabilities that traditional maritime OT never had. Many maritime OT systems were not designed with such functions in mind. Moreover, some major maritime OT vendors (e.g., Kongsberg Maritime, Wärtsilä, and others) have rarely practiced vulnerability disclosure through public advisory channels, and their vulnerabilities have often surfaced through the NVD or through notifications to individual customers. E27's vulnerability disclosure and update requirements therefore demand a shift not only in product design but in operating culture itself.
3. The Economics of Type Approval — Certify Once for Life, vs. Evidence for Every Ship
The most important decision a vendor makes is whether to obtain type approval. And the logic of that decision is a clear-cut economy of scale.
With type approval, the product becomes pre-qualified when installed on a classed vessel. Certify once, and compliance on each individual vessel is confirmed through only a small-scale review by the class society. Indeed, Kongsberg Digital's ship-to-cloud data collection solution Vessel Insight had already obtained type approval from DNV at security profile 1 in 2022 — two years before the mandate — with the result that individual vessels could satisfy E27 with only a small review. Conversely, without certification — as we saw in Part 4 — the system must have documentation comparable in volume to a type approval package produced anew for every ship on which it is installed.
Small-scale review per individual vessel
A single fixed-cost investment eliminates recurring costs
Repeated for every ship installed
Documentation burden and commercial disadvantage
In other words, type approval is a structure that eliminates recurring costs through a single fixed-cost investment. The arithmetic is therefore simple. For a vendor delivering the same product repeatedly across many vessels, type approval is a clear economy of scale, and the industry's consistent recommendation is accordingly that "all systems should obtain type approval where possible." Certification is a cost — but the cost of not certifying — the documentation burden repeated ship after ship, and the commercial disadvantage that burden creates — is usually greater.
4. The Multi-Class Profile Burden — One Product, Different Certifications at Different Class Societies
But the economics are one layer more complicated. A vendor does not supply only the vessels of one particular class society — it sells the same product to vessels of every class society worldwide. Yet the processes and profiles of type approval differ from society to society. DNV operates a security profile scheme based on CP-0231; ClassNK operates a separate application form and a "CY" certification scheme; RINA, ABS, and BV each run their own procedures.
As a result, a truly global vendor may have to certify the same product redundantly across multiple class societies. Just as the class-by-class divergence we saw in Part 1 appeared to the owner as asymmetric costs (Part 2) and to the shipyard as multi-class response (Part 4), to the vendor it appears as the cost of repeatedly certifying one product against the profiles of multiple class societies. The same divergence travels down the value chain, repeating itself in changed form.
Looking at the actual market, some solutions certify with DNV (Kongsberg Vessel Insight), others with RINA (iOThree's onboard security operations system V.Secure, E27 type approval in January 2026). To be universally acceptable to all customers, a vendor may not be able to stop at any single class society.
5. The Paradox: The More Securely You Build, the Harder It Is to Bind
We now reach the central tension foreshadowed in Part 4. And this is the most interesting structural paradox in this series.
The vendor has an incentive to certify its system as "securely" as possible. The extreme form of this is certifying on the condition that the system "cannot be connected to an untrusted network." Do this, and the box itself receives a higher level of assurance. But as we saw in Part 4, that very certification makes the work of binding that box to other systems harder. Data flows crossing trust boundaries come to require a separate gateway, and the encrypted handshakes required by each product's E27 profile can break the integration.
What is at work here is the fallacy of composition. The result of each vendor acting rationally with respect to its own product — making it as secure and as certifiable as possible — aggregates, at the system level, into friction that makes integration difficult.
Individual optimization — make my box as secure as possible —
collides with whole-system optimization — make the integrated ship work well.
This is not any one vendor's blunder; it is closer to a structural phenomenon in which the rationality of the parts culminates in the friction of the whole. The simple sum of compliant components does not automatically make a well-integrated ship — the integration challenge shouldered by the shipyard of Part 4 is, in effect, the aggregate of the vendors of Part 5 each acting rationally.
6. Market Pressure and New Opportunities
And yet the reasons vendors head toward certification are clear. E27 compliance is increasingly written into procurement contracts, so a vendor unable to demonstrate it faces the risk of exclusion from tenders. Type approval is a cost, but it is at the same time market access. The class societies make this message plain as well — to borrow one society's phrasing, cyber resilience is no longer optional but the foundation of safe and compliant operations.
And the paradox of Section 5, paradoxically, creates new markets. Like the E27 type-approved gateway built to solve the "cannot connect to untrusted" problem, some vendors sell products that solve the problems created by other vendors' certifications. The certification trends since the mandate show this too — from ship-to-cloud data collection (Kongsberg Vessel Insight), to integrated automation systems (K-Chief, K-Safe), to an onboard security operations system bundling intrusion detection, automated response, and log analysis (NIDS, SOAR, SIEM — iOThree V.Secure) — not only core OT but a new category that productizes security functionality itself is being certified one after another. In Korea as well, Hanwha Systems joined this current by receiving an Approval in Principle (AiP) for cyber resilience together with a shipyard. The burden created by regulation simultaneously opens a market for products that resolve that burden.
7. The Boundary as Seen from the Vendor's Position
To summarize: the vendor is the minimal unit of the boundary. It is where security capabilities are implemented and certified within a single box — the point at which the big picture of integration is reduced to its smallest component unit.
Whether to obtain type approval
The operation of vulnerability disclosure and updates
The effect its own certification has on integration
Shifting demands in the procurement market
The vendor's real added value lies beyond a "certified box" — it lies in making a box that is "certified, yet easy to integrate." That is, being conscious of the paradox of Section 5 and designing security and interoperability together. A product built that way reduces the shipyard's integration burden of Part 4, raises the owner's operability of Part 2, and simplifies the class society's verification of Part 3. Here too the conclusion is the same — the sharper the boundary, and the more the part is conscious of the whole, the better off the entire value chain becomes.
8. Closing
We have now looked at the four parties in turn. The owner who buys, the class society that assures, the shipyard that implements, and the vendor that makes and certifies. All four perspectives experienced the same boundary — the boundary between the mandatory floor and voluntary differentiation — in different forms from their respective positions.
Yet there remains one final party whose dedicated task is to connect these four perspectives, and to read and guard the boundary. The party foreshadowed since Part 1 as "the role that polices the boundary" — the owner-side advisor, that is, the consultant.
In the next and final installment, we bring the four perspectives together and synthesize the entire series through the consultant's view.
We will see why all of these stories ultimately converge on a single problem: reading the boundary precisely.
Key Evidence
This series is a general analysis of the market structure surrounding IACS UR E26/E27 and does not constitute advice on any specific vendor, product, or certification. Certification requirements and procedures follow the latest unified requirements and guidelines of the relevant classification society and the conditions of individual type approvals.
Owner-side maritime cybersecurity advisor covering IACS UR E26/E27 compliance, zone and conduit design, and OT/IT security architecture for commercial vessels — working across LR, ClassNK, DNV, ABS, and BV newbuilding projects.
🌐 More Articles ↗⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment