OT/IT Convergence on Modern Vessels: A Governance Reading

IACS UR E26 requires OT networks to be segregated from IT networks and crew internet access — a real, mandatory requirement now built into class certification. But ClassNK, one of the societies implementing it, has itself acknowledged that compliant segmentation can still be “highly permissive,” failing to prevent lateral movement in an actual attack. Compliance and genuine convergence governance are not automatically the same thing.

Modern vessels have moved well past the era when navigation, propulsion, cargo, and administrative systems operated as genuinely isolated closed loops. E26 and E27, mandatory for vessels contracted since 1 July 2024, now require documented network architecture and evidence of separation between operational technology and information technology — a meaningful baseline. But the requirement doesn’t mandate a specific technical approach, which means the quality of segmentation varies significantly between vessels that are all, technically, compliant. This is a reading of what owners should actually be governing beyond the notation itself.

Who this is for

• The technical superintendent or IT lead responsible for a fleet’s OT/IT boundary governance, beyond the newbuild specification.
• The owner evaluating whether an existing vessel’s segmentation is genuinely defensible, not just documented.

The E26/E27 relationship, briefly

E26 governs cyber resilience of the ship as a whole across five functional phases — identify, protect, detect, respond, recover — establishing security zones, network segmentation, and vessel-wide incident response as ship-level requirements. E27 operates at the equipment level, mandating a defined set of core security capabilities for onboard computer-based systems, with additional capabilities for higher-risk system categories, and applying primarily to OT equipment manufacturers rather than owners directly. The two work as a hierarchy: E27 ensures individual systems meet a security baseline before integration; E26 ensures the assembled vessel-wide architecture actually holds together as a coherent security posture, not just a collection of individually compliant components.

Why documented segmentation isn’t the same as effective segmentation

The specific criticism worth taking seriously: E26’s segmentation requirement can be satisfied with firewall configurations permissive enough that they don’t meaningfully prevent lateral movement once an attacker has a foothold in one zone. A network diagram showing separated zones, submitted for class approval, demonstrates the architecture exists — it doesn’t demonstrate the rules governing traffic between those zones are actually restrictive. Owners should treat the class-approved segmentation diagram as a starting point for governance, not the end point — the actual firewall rule sets and their real-world restrictiveness deserve independent review, not just documentation sign-off.

Vulnerability management has to be continuous, and that’s an operational commitment, not a paperwork one

For vessels under E26, vulnerability management is explicitly required as a continuous process rather than a point-in-time assessment. This is operationally demanding in a way a single compliance audit isn’t — it requires an actual ongoing capability to track newly disclosed vulnerabilities against the vessel’s specific OT and IT asset inventory, and a process for assessing and remediating them without unacceptable downtime. Fleets without a genuine asset inventory — knowing precisely which hardware, firmware versions, and software are actually running on each vessel — cannot meaningfully do this, regardless of what the SMS documentation claims. Asset discovery platforms specifically built for this gap have emerged recently precisely because manual inventory tracking at fleet scale doesn’t hold up.

Satellite connectivity has become a governance question, not just a bandwidth one

The rapid adoption of Starlink and similar high-bandwidth satellite connectivity has genuinely changed the OT/IT convergence conversation — every external connection, including satellite links, now needs to be treated as part of a managed, secure network architecture rather than a standalone bolt-on. A vessel that added Starlink primarily to improve crew welfare connectivity, without revisiting how that connectivity interacts with the E26 network segmentation already in place, may have quietly reintroduced exactly the kind of unmanaged external pathway the segmentation requirement was designed to close.

Post-commissioning equipment changes are where drift starts

E26 specifically requires new equipment installed after commissioning to be assessed for cyber risk before installation — a requirement that matters most in practice during refits, retrofits, and equipment replacements long after the original class approval. A vessel’s segmentation architecture that was genuinely sound at delivery can degrade over years of individual equipment swaps, each individually justified, none formally re-assessed against the original network architecture. Owners should treat this specifically as an ongoing governance obligation attached to every OT equipment change, not a one-time newbuild requirement.

What genuine OT/IT governance covers, beyond the notation

1. Independent review of actual firewall rule restrictiveness between segmented zones, not just the class-approved network diagram.
2. A genuine, current asset inventory across OT and IT, sufficient to support continuous vulnerability management rather than periodic assessment.
3. Satellite and other external connectivity explicitly integrated into the managed network architecture, reviewed against the existing segmentation whenever connectivity changes.
4. A formal cyber risk assessment step attached to every post-commissioning equipment change, not just the original newbuild specification.

How we engage with this

We read vessel and fleet OT/IT architecture against what E26 and E27 actually require, and where compliant documentation can still mask a genuinely permissive posture, as an Architecture Review. The output is a written assessment of where segmentation is documented versus where it’s genuinely defensible.

We don’t design vessel networks. We don’t issue class notations. We don’t sell OT security monitoring platforms. We read what’s there, identify what’s missing, and write it down for the people who have to decide what to do about it.

Pricing is published at /pricing/. If your fleet’s segmentation has never been independently reviewed beyond the class-approved diagram, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.