**Your session just ended. But did the server know that?**
In maritime OT environments, the answer is often: not immediately — and that gap is exactly where attackers operate.
**What UR E27 Requires**
IACS UR E27 mandates that session IDs are invalidated server-side the moment a session ends — whether through user logout, timeout, crew changeover, or connection drop. Holding a captured token after termination must grant zero access. Client-side deletion alone is not compliance.
**Why It Matters for Ships**
Vessels operate across rotating crew schedules, shared bridge workstations, and intermittent connectivity. A session token captured during a port call — when networks are most exposed — can remain valid for hours if the server never invalidates it. An engineer logs out of the ECDIS management interface; without server-side invalidation, that token stays live on any device that captured it. At sea, with limited monitoring capability, a replayed session can go undetected until damage is done.
The attack surface is not theoretical. Shared terminals, extended anchor periods with active shore connections, and legacy OT systems with weak session handling create conditions where token replay is not just possible — it is practical.
**IEC 62443-3-3 Technical Context**
SR 3.8 RE1 under Foundational Requirement FR 3 (System Integrity) defines session ID invalidation as the technical enforcement layer for session termination, applying at Security Levels SL 3 and SL 4 — the tiers where CBS components face untrusted network interfaces.
The critical distinction here: client-side token deletion (clearing a browser cookie, closing an app) creates the appearance of logout without the security guarantees. SR 3.8 RE1 requires server-side session state to be authoritative. Any token not explicitly invalidated server-side must be treated as potentially live. This requirement sits beyond the baseline UR E26 scope precisely because it addresses systems exposed to adversarial network conditions.
**Implementation Insight**
→ For OT systems running vendor-supplied HMI software, confirm whether the underlying session management architecture supports server-side invalidation natively — many legacy platforms do not. The practical fix often involves a session management middleware layer or gateway that enforces invalidation rules centrally, regardless of what the client-side application reports.
🔒 **This is post 41 of 41 — and fittingly, it ends where attackers look to begin: the moment after a session closes.**
As your fleet modernises and crew interfaces multiply, how confident are you that a terminated session is truly dead on the server?
📌 Post 36/41 in my IACS UR E27 series — breaking down all 41 requirements
