IACS UR E26/E27: Patching, Version Control, and Network Security in Shipboard OT — Why Control Comes Before Detection
Patches, software versions, network systems, and security solutions are not separate tools — they are structural means to manage risk without stopping operations
- LinkedIn : https://www.linkedin.com/in/shipjobs/
Collaborator : Lew, Julius, Jin, Morgan, Yeon
In shipboard OT security, patching, version control, network equipment, and security solutions do not exist independently. Under IACS UR E26 and UR E27, they must all be understood as structural means to manage risk without stopping operations — not tools for achieving the "latest and greatest." This article explains how each fits into the framework, and why control always comes before detection on a ship.
Ⅰ. Patching on Ships: Managed Through the MSUS Concept
In IT environments, patching is automatic, continuous, and applied immediately. On a ship, this model does not hold. Shipboard OT instead approaches patching through the concept of MSUS — Managed Software Update System.
- Automatic updates
- Always-on connectivity
- Mandatory patch during operations
- Only validated updates are managed
- Timing aligned with operational & maintenance schedules
- Class and manufacturer approval included
- Applying or not applying is itself a risk management decision
MSUS is not a "server that distributes patches." It is the system that manages exactly what software versions are installed on this vessel. When a project says "patch server is currently under review," it doesn't mean security is being deferred — it means the MSUS framework is being defined.
Ⅱ. Software Version Control: More Important Than Patching
In shipboard OT security, there is something more critical than patching itself: software version control. Many OT devices cannot be patched at all — but they always have a clearly defined version.
Why version control matters in the event of an incident:
- Which software version was running at the time?
- When was it installed?
- Who approved it?
That is why the following are essential on every vessel:
OT security does not ask "Is this the latest version?"
It asks: "Is the current version under control?"
Ⅲ. What Network Systems Are Used in Shipboard OT?
In shipboard OT security, network systems are not primarily "security devices" — they are the devices that create structure. Before a single firewall rule is written, the physical and logical architecture must already define which zones exist and where the boundaries are.
- Designed for OT environments
- Real-time traffic stability
- Physical foundation for zone separation
- Controls traffic between zones
- Enforces IT–OT and OT–Shore boundaries
- Always-allow ❌ — allow only when necessary ✅
- Single controlled gateway for all remote access
- Separate access paths for Vendor / Yard / Owner
- Session-based access control
- VLAN, ACL, routing policies
- Physical and logical separation combined
Ⅳ. Security Solutions: Control Before Detection
In IT security, detection-focused solutions — IDS, IPS, SIEM — are paramount. On a ship, the order is different. Shipboard OT security solution priorities follow this sequence:
Block connections
Restrict access
Understand what traffic is flowing
Identify anomalies (selective)
The reason for this order: ships are not always online, cannot transmit large volumes of logs, and cannot run real-time analysis continuously. That is why many vessels apply OT-specific firewalls and limited network monitoring — and adopt the philosophy of "block what you cannot see."
Detection without control is noise. On a ship, establishing structural boundaries first makes every subsequent security measure more effective and auditable.
Ⅴ. How It All Connects Under E26 / E27
These elements do not exist independently. They are integrated within the same structural framework:
E26 explains the structure at the ship level.
E27 explains each system at the equipment level.
And the actual network and security devices implement that structure in the real world — making documentation and operational reality one and the same.
Key Takeaways
Not a patch server — a system for managing which software versions are installed and approved on each vessel
OT security asks "Is this version under control?" not "Is this the latest?" — version records are key audit evidence
Industrial switches, OT firewalls, remote access gateways, and segmentation are zone structure — not add-on security features
Control → Visibility → Detection. On a ship, structural boundaries must come before any detection capability can be effective
Senior Manager at a global consulting firm specializing in Maritime Cyber Security, AI, and Data Analytics. 17+ years spanning shipbuilding R&D, AI product development, and maritime cyber compliance. Specializes in IACS UR E26/E27, IMO MSC guidelines, and smart ship development. Founder of ShipPaulJobs.
🌐 More Articles ↗📌 Field Note — Captain Paul
The MSUS (Managed Software Update System) concept resolves a confusion that affects almost every shipboard OT security project: the assumption that patching on ships should work like patching on IT servers. IT patching is automated, continuous, and applied immediately because IT environments can tolerate brief disruptions and downtime windows. OT patching on ships must be managed because a patch that causes an unexpected reboot of an IAS controller at sea cannot be rolled back the way a server patch can. MSUS is not a product category — it's a governance framework for making patching decisions with full awareness of operational constraints.
Version control as a more fundamental requirement than patching itself is the counterintuitive insight that experienced OT security practitioners discover early. Many shipboard OT devices cannot be patched — the vendor doesn't release patches, or the patching process would void the equipment certification. But every device has a defined software version that can be tracked, documented, and included in the change control process. In an incident, the question is not "is this the latest version?" but "was this version deployed intentionally, approved by the right authority, and consistent with the documentation?"
A common misconception in practice:
"Patching OT systems on a ship should follow the same cadence as patching IT servers — install updates promptly to reduce vulnerability exposure." Shipboard OT patching is constrained by operational schedules, vendor certification requirements, and the absence of a maintenance window equivalent. The MSUS framework manages version control and patching decisions within these constraints — prompt installation without MSUS governance can create operational risk exceeding the patch's security benefit.
Key practical takeaways:
- Establish the MSUS governance framework before selecting any patch management tool: define which software versions are authorized on this vessel, who approves version changes, and how timing aligns with port calls and maintenance windows.
- Maintain a per-equipment SW/FW version inventory with install date, approval authority, and change log — in an incident, this is the audit trail that answers 'what was running at the time and was it under control?'
- For OT devices that cannot be patched, document the compensatory controls applied — network isolation, monitoring coverage, scheduled replacement timeline — rather than leaving the gap undocumented in the CSDD.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment