[IACS UR E27] Untrusted Network – 41 Session ID Invalidation after Termination

IACS UR E27 - Session ID Invalidation after Termination

 

**A logged-out session isn't a closed session — unless the server says so.**

On a vessel operating in a high-threat environment, an attacker who captures a valid session token during active operations doesn't need your password. They just need you to believe the session is over.

 

**What UR E27 Requires**

For Cyber-Based Systems with untrusted network interfaces, IACS UR E27 — aligned with IEC 62443-3-3 SR 3.8 RE1 — mandates that session IDs are invalidated server-side the moment a session ends. It doesn't matter how the session ends. Logout, timeout, crew override, or unexpected connection drop: the token must die on the server, immediately and irrevocably.

 

**Why This Matters at Sea**

Shipboard networks are not office networks. Crew rotate. Shore teams connect remotely. Satellite links drop without warning. Each of these events creates a window where a previously valid token could be replayed by an attacker who captured it during legitimate use.

→ A network engineer completes a remote diagnostic session and disconnects — but the token persists server-side for hours

→ A satellite handover drops the connection mid-session — the token remains valid on the server

→ An attacker replaying that token gains authenticated access to propulsion control or ballast management systems — with no credentials required

 

The vessel's physical isolation offers no protection against this. The exploit happens in the protocol layer, not at the gangway.

 

**IEC 62443-3-3 Technical Context**

SR 3.8 RE1 is an enhancement to the base session lock requirement, positioned at Security Levels 3 and 4 — the levels applicable to systems where a successful attack could have severe or catastrophic consequences. The critical technical distinction is this: client-side token deletion is not invalidation. A token removed from a browser or HMI still exists as a valid credential until the server explicitly revokes it. Server-side session state management is not optional at SL 3–4 — it is the enforcement mechanism that makes termination real.

 

**Implementation Reality**

Legacy OT systems on vessels — particularly older SCADA platforms and integrated bridge systems — frequently lack server-side session management entirely. Retrofitting this capability requires either middleware solutions that intercept and manage session state externally, or vendor engagement to upgrade authentication architecture. Neither is trivial in a class-approved, operationally constrained environment. 🔒

 

What session termination events does your vessel's CBS architecture currently handle — and have you verified server-side invalidation, not just client-side token removal?

 

IACS UR E27

📌 Post 41/41 in my IACS UR E27 series — breaking down all 41 requirements