# 🛡️ Is Your Ship's Network Being Watched — Or Just Assumed Safe?
Most vessels have network infrastructure. Far fewer have the continuous visibility to know when something on that network has gone wrong.
**What UR E26 §4.3.1 Actually Requires**
IACS UR E26 mandates continuous monitoring of all in-scope networks — not periodic polling, not manual walkthroughs. Shipowners and systems integrators must implement monitoring capable of generating alarms for five specific conditions: excessive traffic, unauthorized device connections, abnormal bandwidth utilization, network connection anomalies, and device management activity. If an IDS is deployed, it must be supplier-qualified and strictly passive.
**Why This Is Uniquely Challenging at Sea**
Shore-based SOC teams can respond to alerts within minutes. On a vessel mid-voyage, that response chain is fundamentally different — limited crew, no immediate IT support, and operational continuity that cannot be paused. This means alarms must be meaningful, actionable, and calibrated to the maritime environment from the start. A flood of false positives on a bridge system at 0200 is not a monitoring capability — it's a liability.
**The IEC 62443 Technical Foundation**
IEC 62443-2-1 §4.3.4.3 requires anomaly detection that addresses both known attack signatures and behavioral deviations — not just firewall rules. E26's passive-IDS-only requirement is a direct response to a fundamental OT/IT tension: an active IPS that blocks or resets connections could interfere with safety-critical real-time processes like propulsion control or dynamic positioning. This makes explicit what IEC 62443 implies — in IACS environments, a monitoring tool that "protects" by disrupting operation may create more risk than it prevents.
**The E26 / E27 Layered Relationship**
E26 §4.3.1 defines the vessel-level monitoring obligation, but it depends on capabilities built into each Computer-Based System. E27 §4.1 maps three supporting requirements: SR 2.3 (portable device control) provides endpoint authorization detection, SR 2.8 (auditable events) generates the log data that makes vessel-level monitoring possible, and SR 7.1 (DoS protection) addresses the capacity threats that abnormal bandwidth alarms are designed to catch. E27 builds the sensors; E26 requires someone to watch them.
**Implementation Insight**
One of the most overlooked gaps in maritime network monitoring is baseline definition. Anomaly detection is only as effective as the normal traffic profile it compares against. Establishing and documenting what "normal" looks like for each vessel's OT network — by system, by voyage phase, by time of day — is essential groundwork before any meaningful threshold or alarm can be configured.
**Over to You**
Has your organization defined OT network traffic baselines specific to vessel operations — or are thresholds still being borrowed from IT security benchmarks?
📌 Post 9/17 in my IACS UR E26 series — breaking down all 17 requirements across the Identify → Protect → Detect → Respond → Recover framework
