The uncomfortable arithmetic of industrial intrusions is that the loud part happens last. Triton was found because a safety instrumented system tripped a plant into shutdown, and only then did anyone discover that the attackers had been working inside that environment for roughly a year. The 2015 attack on Ukrainian distribution utilities became visible when breakers opened, months after the initial spearphishing email. In both cases the network had been telling the truth for a long time. Nobody was listening to it.
That gap is not a failure of tooling budget. It is a failure of what gets watched. Most OT security programs monitor for events that a control system is designed to report: alarms, faults, failed logins on the handful of systems that log them. An intruder who is careful generates almost none of those. What they cannot avoid generating is traffic, and traffic in an industrial network is unusually honest. A PLC executing a scan cycle has a behavioral envelope so narrow that deviation is measurable rather than debatable.
Here are five signals that reliably precede a visible incident, and what each one actually looks like when you have the packets.
1. A Device Acquires a Peer It Has Never Had
The single most useful fact about an OT asset is its conversation graph. A pressure transmitter talks to one or two controllers. A PLC talks to its HMI, its historian, an engineering workstation during maintenance, and nothing else. A protection relay in a substation talks to a gateway. These relationships are set at commissioning and they are stable for years, because the process they serve is stable for years.
So when a controller that has spoken to four peers every day for eighteen months opens a session to a fifth, that is not an anomaly in the statistical sense. It is a structural change in how the plant is wired, and it happened without a change ticket.
This is the signal that catches lateral movement, because lateral movement is definitionally the creation of new peer relationships. It is also the signal most likely to be missed by rule based detection, since no rule was ever written for a pairing nobody anticipated. The Ukrainian utilities were operated through legitimate remote access from hosts that had every right to exist on the network. What those hosts did not have was a history of talking to the substation gateways.
The practical test: for each critical asset, can you produce the list of peers it communicated with last month, and does anyone own the answer to why each entry is on it?
2. Engineering Actions Outside Engineering Windows
Industrial protocols distinguish between reading process data and changing the process. Modbus function code 3 reads holding registers all day long. Function codes 5, 6, 15, and 16 write. DNP3 carries operate and direct operate commands that are meaningfully different from a class poll. S7comm has explicit stop CPU, start CPU, and upload or download block operations. EtherNet/IP over CIP separates get attribute from set attribute and forward open.
In a healthy plant, the write and program operations cluster. They happen during commissioning, during maintenance windows, during a recipe change, from a small set of engineering workstations, by a small set of people. The read operations run continuously.
A program download at 03:00 on a Sunday from a host that normally only reads is not subtle once you separate those categories. Neither is a configuration write to a safety controller. Triton is the case that makes this concrete: the attackers needed to interact with the Triconex safety system at the engineering layer, and that interaction was categorically different from the traffic that system normally carried. The wire showed it. The reporting path did not.
If your monitoring counts packets and sessions but does not decode function codes, you cannot tell a routine read from a controller reprogram. That distinction is the difference between normal operations and an attacker preparing to act on the process.
3. A Dormant Access Path Wakes Up
Every site has more remote access than its documentation shows. Vendor support tunnels negotiated into a maintenance contract, cellular routers installed in a cabinet during a turnaround, jump hosts built for a project that ended two years ago, a VPN profile still valid on a laptop that changed hands. These paths are usually idle, which is precisely what makes them useful to an attacker and invisible to a periodic audit.
The signal is not that the path exists. It is that a path with no traffic for four months suddenly carries a session, and the session arrives at an hour and from a source that does not match how that vendor has ever worked. The Oldsmar water treatment intrusion in 2021 traveled a path exactly like this: remote access software that was reachable, credentials that were shared, and a route to an HMI where a chemical setpoint could be altered. The access mechanism was not exotic. It was inventoried nowhere and watched by no one.
Treat every conduit crossing your Level 3 to Level 4 boundary as an asset with its own baseline. Idle is a behavior. Deviation from idle is an event.
4. Timing That Belongs to a Machine, Not a Process
Industrial traffic has rhythm. A polling loop produces intervals that are regular because a scan cycle is regular. Event driven traffic such as alarms is irregular because the process is irregular. These two profiles are easy to tell apart once you measure inter arrival times per flow rather than aggregate throughput.
Command and control traffic has its own rhythm, and it does not match either one. Beaconing produces intervals that are regular in a different way: consistent period, small and consistent payloads, often with jitter applied in a pattern that is itself distinctive. It shows up in flows that have no operational reason to be periodic, frequently from a host that also does legitimate work.
Related timing signals worth watching: DNS queries from assets that have no business resolving anything, sessions that persist far longer than any operational transaction requires, and traffic volumes that are steady when the plant is not running. A line that is down should be quiet. Traffic during a planned outage is one of the cleanest signals available, and one of the least monitored, because most teams stop looking when production stops.
5. Small Reliability Complaints That Nobody Connected
The last signal is not a packet pattern. It is a pattern in what operators report and dismiss.
An HMI that has become slow to update. A controller that dropped offline briefly last Tuesday and came back on its own. A historian gap of eleven minutes that got attributed to the network. A serial to Ethernet converter that needed a power cycle. Individually, each of these is written off as aging equipment, and often that is what it is. Collectively, clustered in time and located along a plausible path, they describe an environment where something is competing for resources it was never provisioned for.
The 2015 Ukraine attack ended with firmware on serial to Ethernet converters deliberately overwritten so operators could not reach field devices remotely. Attackers interact with fragile equipment, and industrial equipment is fragile by design tradeoff: deterministic, resource constrained, and intolerant of unexpected load. The maintenance log and the network baseline are describing the same environment. Very few organizations read them together.
Why These Signals Get Missed
The common thread is that all five are behavioral, and behavior requires a baseline that nobody has time to build by hand across thousands of assets. Most OT environments cannot even produce a current inventory, let alone a per device profile of protocols, peers, timing, and command patterns.
The collection method matters here. Active scanning is a poor instrument for this problem: many controllers respond badly to unexpected probes, and a scan tells you what a device will answer, not what it habitually does. Passive collection from a SPAN or mirror port with full packet inspection gives you protocol level detail, including function codes and command semantics, without putting a single frame onto the process network. Flow telemetry such as sFlow or NetFlow from the switches complements that, extending coverage across the fabric where mirroring is impractical and making the conversation graph visible at scale.
From there the profiling is mechanical. Every device has a normal envelope. Deviation from it is computable, and more importantly it is explainable: this asset, this new peer, this protocol, this command, this time, versus this much history. An alert that cannot survive the question "why is this abnormal" will be ignored by the third week, and correctly so.
What to Do This Week
You do not need a new program to test whether these signals would be visible to you today. Pick your three most critical assets and try to answer four questions with evidence rather than assumption.
Who did each one talk to in the last thirty days, and is every peer accounted for. When was the last write or program operation against it, from which host, and does a change record match. Which remote access paths can reach it right now, including the ones no diagram shows. And what does its traffic look like during a planned outage.
If those answers require a week of manual work, that is the finding. Intrusions in industrial environments are slow, and slow is an advantage only for the side that is watching. The evidence is already on your wire. The question is whether anything is reading it.