Reconnecting OT Without Turning Recovery Into a New Incident
This chapter examines the moment when a ransomware recovery moves from isolated systems toward operational technology (OT) and the physical process. The focus is not a universal reconnection procedure; it is the reasoning that makes reconnection a gated decision: why a technically functional HMI, engineering workstation, historian, or gateway may still be unsafe, how assumed boundaries can fail, and why local operator and safety approval, monitoring, and rollback belong inside cyber recovery.
OT systems monitor or control physical processes. In manufacturing, that can include interfaces used by operators, engineering workstations that configure or communicate with equipment, historians that provide process visibility, gateways that bridge environments, and control components that influence what happens on a line. A recovered component does not need to be malicious to create danger. It can be misconfigured, connected to the wrong path, operating with untrusted credentials, or returning information that no longer matches the state of the process.
A functional OT component can still be unsafe
The first mistake is to treat “working” as a single condition. A recovered HMI may display screens and accept input, yet the data behind the screens may be stale or wrong. A historian may answer queries while its timeline cannot be trusted. An engineering workstation may launch its tools while carrying a compromised account or configuration. A gateway may pass traffic while exposing a path that responders believed was isolated. Technical function is evidence that a component is responding; it is not evidence that using the component is safe or appropriate for the proposed mission.
The consequences are different from those of a typical office application. A business application that shows an error may delay a transaction. An OT-facing component can affect visibility, alarms, commands, setpoints, and an operator’s understanding of a physical process. The sources do not say that every restored component will cause physical harm. They establish the more careful point that a loss of situational awareness or command pathways can be operationally serious even without direct physical destruction.
That relationship creates several distinct hazards. A recovered system may show an operator a state that is not current, leading the operator to make a decision with incomplete information. It may reconnect with permissions broader than the selected production mission requires. It may issue a configuration or command through a path that was not part of the intended recovery boundary. It may bring back a service account or engineering tool whose credentials were exposed during the incident. In each case, the component can be technically functional while its role in the physical process remains untrusted.
The correct response is not to declare OT untouchable until every enterprise system has been restored. Manufacturing may need a constrained capability before full enterprise recovery. The response is to define what the proposed mission needs from OT, isolate and validate the relevant components, and reconnect only the paths whose state and purpose are understood. A narrow, controlled operating condition can be more defensible than a broad reconnection made to demonstrate that the plant is “back.”
This is where the earlier recovery states become operational. Availability asks whether the component can communicate.