Recovery after a shipboard OT cyber incident: backups, integrity and safe return to service

Define the service that must be recovered

An OT system monitors or influences a physical process. Its recovery objective should name the service, its operating boundary and the evidence required to show that service behaves correctly. A pump-control computer, for example, depends on more than executable files: the current I/O mapping, connected equipment, power supplies, communications and the physical plant state all matter to its interpretation and outputs.

IMO's MSC-FAL.1/Circ.3/Rev. 4, dated 28 May 2026, distinguishes OT's physical role and calls for identifying system dependencies. Its functional elements operate concurrently, rather than as a one-way checklist. During recovery, new evidence may reopen the incident scope. The analytical focus here is the quality of recovery evidence; no isolation, restart or network-reconnection sequence is prescribed for a real vessel.

Preserve evidence while stabilizing the process

The need to preserve logs and volatile evidence can conflict with the need to keep machinery in a controlled condition. That conflict belongs in the vessel's incident and safety arrangements, with clear roles for operational and cyber specialists. An improvised reboot may remove useful evidence; keeping a compromised controller connected merely to gather more data can also prolong physical risk.

Record what was observed, what changed and who authorized the change. Keep the original data and the acquisition context separate from later interpretations. A recovered log with a new host clock is not automatically a continuous account of the incident. Where urgent process protection limits evidence collection, state that limitation explicitly so later investigators do not mistake an unavoidable gap for proof that nothing happened.

Ask what the backup actually contains

The phrase system backup can mean a disk image, application project, parameter export, historian data or only a vendor's installation media. These differ in what they can restore. A project file may omit firmware, licenses, certificates, user configuration or the precise version of a driver. A complete disk image can still contain changes made after an attacker gained access.

NIST SP 1339, finalized in June 2026, links OT backups with configuration changes, infrastructure dependencies and tested recovery. The practical question is whether the selected restore set reproduces the approved configuration needed now. Retaining several dated copies can help investigation, but age alone does not establish a clean point. The provenance, protection and known history of each candidate remain part of the evidence.

Separate byte identity from trust and suitability

A cryptographic hash can establish that two byte sequences match the recorded digest under the chosen algorithm. It does not establish that the reference image was free of compromise, that its origin was authentic or that it matches the equipment now installed. A manifest stored beside an attacker-modifiable image may reproduce the same mistake with complete internal consistency.

Trust in the reference requires independently protected provenance and appropriate assessment of the incident's reach. Suitability requires a comparison with the approved equipment and configuration baseline. These are logically different questions. A successful boot adds evidence that part of the software executes; it still does not test every control path, alarm, interlock or physical interface. Recovery records should state which question each check actually addresses.

Build an original evidence matrix

Consider eighteen fictional restore artifacts, numbered 01–18. All eighteen match their recorded byte digests. A separate revision check finds exceptions in 02 and 07, leaving sixteen revision matches. An interface check finds exceptions in 07, 11 and 16, leaving fifteen interface matches. These are assigned observations, not test results from a ship, and they are not independent success probabilities.

The exception sets overlap at 07. Their union contains 2 + 3 − 1 = 4 artifacts: 02, 07, 11 and 16. Only 18 − 4 = 14 artifacts pass all three stated checks, or 77.78% of the item count. Taking the smaller individual pass count, fifteen, would overstate joint coverage by one. The figure makes the overlap visible; the arithmetic cannot replace the missing substantive checks on those four items.

Do not turn a coverage fraction into permission

The fourteen-of-eighteen result is a count of evidence intersections. It is not 77.78% recovery, reliability or safety. The items have unequal consequences; in this invented set, 11 represents a critical interface discrepancy. Seventeen benign display files would not compensate for one unverified control function. A weighted score would still need a defensible model and could conceal a condition that must be satisfied outright.

Passing the three selected columns also says nothing about omitted requirements. If the reference image's trusted origin has not been established, eighteen byte matches leave that problem unresolved. If a plant-state test was outside scope, passing a static interface review does not imply that test occurred. Name the missing evidence and the affected service boundary instead of declaring a reassuring aggregate percentage.

Distinguish backup age from lost information

Suppose a fictional backup plan has a six-hour interval, but the selected usable snapshot was captured at 04:00 and the incident is detected at 11:30. The selected snapshot is 7.5 hours old, which exceeds the scheduled interval by 1.5 hours. That arithmetic describes the chosen capture's age at detection; it does not establish when compromise began, which changes were lost or when physical service can resume.

A more recent snapshot may be rejected for a documented reason, or the last scheduled capture may have failed. Either event breaks the assumption that nominal frequency bounds the usable restore point. Reconcile the changes made since the selected capture against controlled records. Recovery-point objectives, actual capture times, investigation uncertainty and restoration duration should have separate fields, rather than being compressed into one downtime number.

Reconcile restored state with the physical plant

A restored controller can remember an earlier mode while a valve, breaker or tank is now in another state. The mismatch is not cured by declaring the software version correct. Similarly, a valid parameter set may be inappropriate after a sensor or drive replacement. Evidence needs the approved configuration and safe, competent verification of relevant interfaces under the applicable equipment procedures.

NIST SP 800-82 Revision 3, CP-10, explicitly discusses how restored state variables can disrupt an ongoing physical process. Its CP-9 discussion also distinguishes backup testing resources from limited hash checks. These support keeping data restoration and process reconstitution separate. This article supplies no forced output, bypass, protective-setting change or live test recipe; those would require the vessel's controlled engineering and operational arrangements.

Make return-to-service evidence traceable

A useful recovery record connects the incident scope, selected images, trusted references, restored versions, identified discrepancies and completed verification to a named service boundary. It also states unresolved issues, restrictions and who owns the release decision. The record should distinguish a test environment from the actual installation; spare hardware can establish valuable compatibility evidence without reproducing every network or machinery condition onboard.

MSC.428(98) places cyber risk in the safety-management context and refers to the first annual Document of Compliance verification after 1 January 2021. That organizational expectation is not an acceptance test for one restored controller. Where class, flag, manufacturer or company requirements govern a change, their applicable scope must be established separately. A generic cyber checklist cannot confer operational authority on the recovery team.

Retain the limits after service resumes

Reappearance of expected screens and absence of alarms are observations, not proof that every malicious persistence mechanism is gone. Follow-up monitoring should relate to the investigated attack paths and restored service, while maintaining the necessary physical safeguards. A new discrepancy should be linked to the relevant image or configuration history so that further action is based on evidence instead of another blind restore.

The source check on 8 October 2026 used IMO Rev. 4 and NIST's final SP 1339 and SP 800-82 Rev. 3. NIST lists Rev. 4 of 800-82 as an initial public draft, not the final successor. The original numerical case establishes fourteen joint passes and a 7.5-hour snapshot age only. Clean trust, complete configuration and demonstrated physical function remain distinct claims requiring their own support before a real service is released.

Sources

1. IMO MSC-FAL.1/Circ.3/Rev.4: Guidelines on maritime cyber risk management. 28 May 2026; actual official PDF read 8 October 2026 — Sections 2–3; OT physical consequences, interdependencies and concurrent Govern/Identify/Protect/Detect/Respond/Recover functions
2. IMO Resolution MSC.428(98): Maritime cyber risk management in safety management systems. 16 June 2017; actual public resolution read 8 October 2026 — Operative paragraphs 1–2: SMS cyber risk and first annual DOC verification after 1 January 2021
3. NIST SP1339: OT Backup Quick Start Guide. Final June 2026; actual two-page public guide read 8 October 2026 — Backup integration with change management, dependencies, recovery exercises and testing
4. NIST SP800-82 Revision 3: Guide to Operational Technology Security. Final September 2023; checked 8 October 2026; NIST listing identifies Revision 4 only as an initial public draft with comments due 30 November 2026 — Appendix F CP-9/CP-10, printed pp 250–251: backup checks and physical process state on reconstitution