OT threat map: what reaches your plant, and what it costs you

Entry through the remote access path that exists so vendors and on-call engineers can work without driving to site. It is rarely undocumented; it is usually documented, approved, and far broader than anyone intends.

Mail to a corporate user, which is not OT at all. It matters because the enterprise network is where nearly every published OT intrusion began before moving down.

USB into an engineering workstation. Still current, because air-gapped plants move files somehow and the somehow is usually a memory stick in an engineer's pocket.

Compromise arriving inside legitimate vendor software, firmware or an integrator's laptop. The integrator's laptop is the one people forget, and it connects to everything.

Using the controller's own documented programming interface to run code. Nothing is exploited; the device is asked to do what it was designed to do, by someone who should not be asking.

Driving the HMI as an operator would, through stolen credentials or a hijacked session. Indistinguishable from legitimate use in most logs.

Scripting engines on engineering workstations and historians, used to automate the attack the way engineers use them to automate work.

Changing controller logic so the attacker's behaviour survives reboots, restores and staff changes, because the logic is now simply what the plant does.

Persistence below the logic layer, in device firmware, where reimaging the workstation and reloading the program changes nothing.

Standard escalation on the Windows hosts that run OT applications, which are often years behind on patches for entirely legitimate availability reasons.

Putting a controller into program or remote mode to permit changes, then returning it, so the window is brief and easily missed.

Clearing logs and artefacts on OT hosts, which is easy when logs are stored locally and never leave the device.

Passive listening on control networks, which is unusually productive because most industrial protocols carry no encryption and announce a great deal about the process.

Enumerating controllers and their roles, often using the same discovery functions engineering tools use.

Moving tooling deeper into the plant, usually through the paths built for legitimate file movement between levels.

Documented default credentials on controllers, HMIs and network gear, published in manuals anyone can download.

Watching the process to learn its normal behaviour, which is the prerequisite for changing it convincingly rather than obviously.

Historians, engineering document stores and project file repositories: the fastest route to understanding a plant without standing in it.

Command and control over protocols already permitted outbound, so nothing new has to be opened.

Stopping alarms reaching operators, so the process degrades with nobody told. Frequently paired with a manipulation technique rather than used alone.

Stopping the services that provide visibility and control, a common precursor to ransomware deployment in OT-adjacent environments.

Widening alarm thresholds so genuinely abnormal conditions read as normal. Quieter than suppression and considerably harder to notice.

Changing setpoints and tuning within ranges the system accepts, so the process moves somewhere harmful without anything rejecting the instruction.

Well-formed protocol commands from an unauthorised source. Most industrial protocols authenticate nothing, so a valid message is obeyed regardless of origin.

Production stops, whether deliberately or because the operator shut down on losing confidence. The second is far more common and is usually the right call.

The protective layer no longer protects. TRISIS is the reference case: malware written specifically to reach a safety instrumented system.

The process cannot run. In OT this is often the least bad outcome available and a legitimate protective response.