4 OT Incident Types — And How to Read Which One Actually Needs Attention
Most OT incidents look nothing like Stuxnet. These four OT incident types show what teams actually deal with, and how to read which one to act on first.
4 OT Incident Types — And How to Read Which One Actually Needs Attention
When people talk about attacks on OT systems, they picture Stuxnet, or malware that takes a power plant offline. But what OT teams actually deal with day to day looks nothing like that — and often isn't an attack at all.
This article walks through four types of OT incident, what each one tells you, and why the one that looks mildest can sometimes be the one to act on first.
Four incident types and how urgent each usually is
1. Remote maintenance outside the approved window
Teams usually treat this as urgent because it's maintenance access outside the approved time window, which resolves to one of two things: a legitimate contractor connecting off-schedule without notice, or someone else using the contractor's remote access path.
What makes it dangerous is that remote maintenance channels tend to be legitimate entry points with full privileges, and they're usually watched less closely than other doors. If an attacker were shopping for a way in, this is the one they'd want.
2. A connection from outside the allow list
A client absent from the allow list attempts to connect to a gateway. In practice, the most common cause isn't an attacker — it's a new device engineering plugged in without telling IT, or a technician's laptop connected directly to the OT network.
Teams usually still treat it as urgent, though, because from the system's point of view there's no way to distinguish the technician from anyone else until a person checks.
3. Polling that drifts from its baseline
Polling cadence drifting from its normal baseline. This one is usually a technical problem rather than a security one — a device starting to fail, degraded cabling, unusual network congestion.
Teams usually give it lower urgency for that reason, but it's still worth looking at. Off-rhythm polling can be the first sign something has inserted itself into the path, and in other cases it's an early warning that a device is about to fail — which has its own value.
4. Cloud traffic that departs from the usual pattern
Outbound volume differing from the established pattern. At a plant that routinely ships telemetry to the cloud, a volume change might come from a software update, added sensors, or — in the worse case — data going somewhere it shouldn't.
Teams usually give this one lower urgency too.
A reading skill worth having: risk score isn't priority order
Incident lists usually come with a risk score, so the temptation is to work from the top down. But picture a list where the highest-scoring case is already acknowledged (ACK, meaning someone has picked it up) while a lower-scoring one is still Open.
That situation isn't a mistake. It reflects how teams actually triage: using several factors, not the number alone. An acknowledged case may be waiting on information from a contractor, while an Open one may have just landed.
The point is that risk score helps you sort, it doesn't decide for you. A team chasing the number alone will miss the low-scoring thing that genuinely matters — like a cloud egress deviation that's small but has recurred every night for a week.
What all four have in common
Look across them and you'll notice none is "malware detected," the thing security product marketing tends to lead with. Every one of them is a deviation from what used to be normal.
That's the core of OT security. OT systems do the same things the same way every day, unlike IT networks where user behavior shifts constantly. That consistency becomes an advantage: anything departing from the pattern stands out far more clearly.
For how the filtering pipeline narrows everything down to incidents like these, read How Deterministic Detection Rules Work in OT. For the bigger picture on why OT needs its own approach, see OT Security for Industrial Facilities.
How zcrOT handles incidents
zcrOT provides an Incidents view that groups related matches into a single case with a risk score, severity, status (for example Open, ACK or Closed), and a reference code you can trace back to the event-level evidence.
To see how the Incidents view works, open the zcrOT demo. To find out what it would surface on your own OT network, get in touch below or see zcrOT plans.
Get in touch
Want help deciding which event types should be Critical at your facility? Talk to our team — the consultation is free.