[IACS UR E26] Recovery – 17 Controlled Shutdown, Reset, Roll-back & Restart

IACS UR E26 - Controlled Shutdown, Reset, Roll-back & Restart

 

# Post 17/17 — Controlled Shutdown, Reset, Rollback & Restart

 

**What if a cyber incident response makes things worse — not better?**

In integrated OT environments, an uncontrolled shutdown can corrupt transaction states across connected systems, leaving your vessel in a condition that's harder to recover from than the incident itself.

 

**What UR E26 §4.5.3 Requires**

Every Computer-Based System (CBS) and its associated network must support four specific recovery capabilities: controlled shutdown, reset, rollback to a previous known-good configuration, and restart from a clean, read-only image. Critically, the standard distinguishes *controlled* shutdown from a hard power-off — connected systems must be allowed to commit or rollback pending transactions before stopping. Documentation for all four procedures must be accessible to crew without specialist intervention.

 

**Why This Matters on Ships**

Unlike a data centre, a vessel's OT systems — propulsion control, ballast management, ECDIS — are tightly coupled. A hard shutdown of one CBS mid-transaction can propagate inconsistent states across the integrated system, creating unsafe intermediate conditions at exactly the moment when safe recovery is most critical. ⚓ At sea, with no shore support, crew must execute these procedures correctly under pressure. The procedures need to work — not just exist on paper.

 

**IEC 62443 Technical Depth**

§4.5.3 directly implements IEC 62443-3-3 SR 7.4 (System Recovery and Reconstitution), which requires recovery to a *known secure state* — meaning security controls must be verified as intact, not merely that services are running again. The rollback capability is particularly significant here: dwell-time intrusions often involve stealthy configuration changes made weeks before detection. Rollback reverses those unauthorized changes; restart from a read-only image ensures a compromised running configuration is never reloaded. SR 7.4 cannot be satisfied by backup alone — the *procedures* to reach that secure state safely are equally required.

 

**The E26/E27 Layered Connection**

E26 Appendix II maps IEC 62443 SR 7.4 to both §4.5.2 and §4.5.3 together. §4.5.2 (covered in Post 16) defines *what* you recover to — the verified backup. §4.5.3 defines *how* you get there safely. E27 §4.1 item 27 carries SR 7.4 down to the system and component level, meaning equipment suppliers must design CBS with these controlled recovery mechanisms built in from the outset. 🔧

 

**Implementation Insight**

The hardest challenge in practice is restart timing. When one CBS restarts, connected systems must not enter unsafe intermediate states during the reload window. This requires explicit sequencing logic and tested recovery runbooks — not assumptions. Shipyards integrating multi-vendor OT systems must validate these sequences during commissioning, not after delivery.

 

**Engagement Question**

Has your organization actually *tested* a full rollback to a previous configuration in a live or simulated OT environment — and if so, what surprised you most?

 

📌 Post 17/17 in my IACS UR E26 series — breaking down all 17 requirements across the Identify → Protect → Detect → Respond → Recover framework

IACS UR E26