The industry spent a decade trying to watch the network. Attackers spent that decade learning to live somewhere else.
Galvanick Opinion by Blake Johnson.
December 17, 2025.
Where Attackers Live
The OT security market has matured over the past ten years. Network security monitoring tools now sit in thousands of industrial environments, providing asset discovery, protocol visibility, and anomaly detection. This represents real progress.
But when you look at where attackers actually operate during OT intrusions, a gap becomes clear: 99% of attacker activity occurs on workstations and servers – mostly invisible to network sensors. By the time an attacker deploys custom code against a controller, they have already spent weeks or months on Windows and Linux endpoints, exhibiting detectable behaviors.
The signals are there, but most organizations aren't instrumented to see them.
Why Current Tools Fall Short
The two obvious approaches to this problem both have significant limitations.
Network monitoring can't tell you whether to care. These tools excel at showing you what happens on the wire. They struggle to answer a more important question: should I care?
Someone just performed a program download to a controller. A maintenance technician doing their job and an attacker who has compromised an engineering workstation look identical based on network data alone. This ambiguity creates an impossible triage problem. Security teams face thousands of alerts, most representing legitimate activity. Without additional context, they either investigate everything or start disabling detection rules. Most drift toward the second option – the monitoring tool stays deployed but functions primarily as an asset inventory.
Traditional EDR carries operational risk. Endpoint Detection and Response tools could provide the visibility that network monitoring lacks. But EDRs install drivers at the kernel level, most maintain cloud connections, self-update, and are capable of autonomous actions. In OT environments, a kernel-level agent that can modify itself introduces a variable you cannot fully control into systems running physical processes. While some EDRs can run in monitor-only mode, the capability to take automated action remains and can be enabled through their control plane at any time. The security team gains visibility, but the operations team inherits risks they cannot quantify. You now have a hook into your critical control system assets at the kernel level providing direct access to a third party. For many organizations, this trade-off is a non-starter.
Defenders need endpoint data but cannot accept the risks that come with traditional endpoint tools in OT.
Endpoint Visibility Without Endpoint Control
You can get endpoint visibility without endpoint control.
The Windows and Linux systems operating in critical infrastructure and advanced industrial environments occupy an important position: process historians, jump hosts, engineering workstations, operator stations, PC-based HMIs, and DCS control servers. They run standard operating systems, communicate using standard protocols, and represent the narrowest path into operational assets in a well-segmented network. If your architecture follows best practices, the most straightforward paths an attacker can take into OT almost always run through these intermediary endpoints. They are where attackers want to be and where defenders should be watching.
Sensors that leverage built-in operating system APIs rather than kernel-level code can generate the telemetry that matters without introducing the same level of operational risk:
Process telemetry captures every command, every program launch, every argument, and process-to-process behaviors like memory access attempts that indicate the presence of attacker tooling.
File system telemetry tracks creation, modification, and deletion of files, including attribution to the process and user responsible.
Network telemetry from the endpoint complements network sensors with flow-level data attributed to specific processes and users.
This is the context network monitoring cannot provide: who did this, with what tool, and why.
Take the PLC download scenario. With endpoint visibility, you see the download originated from a known engineering application, launched by a logged-in user. Cross-reference with your maintenance system and you see a valid change ticket. Or you see it came from an unsigned executable dropped into a temp directory by a process injecting into other processes' memory, initiated by a new user with no open work orders. The network alert looks identical in both cases. The endpoint and broader context make the difference. Galvanick correlates this endpoint and network data with infrastructure and application data sources to tell the whole story to the analyst responding.
Catching Attackers Earlier
By the time an attacker interacts with a PLC or safety controller, they have already succeeded at the hard part: getting in, establishing persistence, moving laterally, and learning your environment. Detecting them at that stage means detecting them too late.
Endpoint visibility shifts detection left. You find attackers as they bring their tools into your environment. You see persistence mechanisms, credential theft, and lateral movement. You catch them while intervention still prevents impact.
The network got the first decade of OT security investment. In 2026, the organizations pulling ahead will be the ones instrumented to see where intrusions actually happen.
Blake Johnson is a Senior Engineer at Galvanick. His career has taken him from defending utility control systems, to responding to OT intrusions at Mandiant, to building one of the world’s largest industrial security programs at Amazon. He now focuses on OT threat detection.