TL;DR: OT environments need security controls that work before execution, on constrained devices, and without cloud dependence, according to Crytica Security, because delayed detection can let malware alter control logic or trigger cascading outages. Deterministic, lightweight monitoring becomes the practical answer when uptime and legacy hardware leave no room for noisy or resource-heavy tools.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Crytica Security's blog post: OT cybersecurity needs pre-execution detection because resource-constrained legacy systems cannot tolerate delayed, cloud-dependent, or heavy monitoring.
Why it matters: This matters for OT, IAM, and resilience teams because defenders need controls that fit fragile systems while still limiting malware impact before it reaches execution or persistence.
Context
Operational technology security is constrained by uptime, limited compute, and systems that cannot absorb intrusive tooling. In many plants, substations, and other critical environments, the problem is not only whether a threat is detected, but whether the control itself can operate without disrupting the device it is meant to protect.
Traditional IT security assumptions break down when devices are rarely patched, may be semi-isolated, and need to keep running for years with minimal change. That creates a governance gap: visibility must be continuous, but the tooling must be far lighter than what enterprise endpoints usually carry. The same constraint logic also applies to critical infrastructure identity security, where access and monitoring controls have to fit operational reality rather than idealised architecture.
This starting position is typical for OT, not exceptional, which is why security design has to begin with the environment’s operating limits before it can meaningfully address malware risk.
Key questions
Q: How does pre-execution malware detection work on OT devices?
A: Pre-execution detection watches for unauthorised change before a payload runs, usually by comparing memory, code, or protected files against an approved baseline. In OT, that approach matters because even a short runtime window can be enough to alter a control process. The goal is not just faster alerting, but stopping malicious code before it can affect physical operations.
Q: Why does resource-heavy security software fail in OT?
A: Resource-heavy security software often fails in operational technology because control systems usually have limited CPU, memory, and network tolerance, and some devices cannot safely absorb agents that scan, inspect, or update too often. OT environments also depend on deterministic timing, so intrusive tools can disrupt process control, communications, or safety functions.
Q: What is the difference between behavioural detection and deterministic integrity checking?
A: Behavioural detection looks for suspicious patterns, anomalies, or deviations from a baseline, such as unusual process spawning or lateral movement. Deterministic integrity checking compares files, binaries, configurations, or system state against a known good value, hash, or policy and flags exact change. One is pattern-based, the other exact-match verification.
Q: What should teams do first when malware is found on a control system?
A: Teams should isolate the affected control system from trust relationships and remote access first, while preserving safety and process continuity. Then they should collect volatile evidence, identify the malware's scope, and coordinate containment with operations so that cleanup does not destabilise controllers, engineering workstations, or safety instrumented functions.
Technical breakdown
Why execution-based detection is too late for OT
Execution-based detection waits until malware has already started running, which is a poor fit for operational technology. In OT, a few seconds can be enough for injected code to alter a control loop, change process state, or disrupt a safety-sensitive workflow. The practical problem is not simply malware presence, but the point at which defenders can still stop it without impacting the process under control.
Practical implication: Shift detection left to memory injection or file change events so response begins before malicious code reaches runtime.
How lightweight monitoring fits constrained OT devices
OT assets often run on limited memory, older processors, and firmware-like environments where conventional agents are too heavy. Lightweight monitoring works only if it avoids dependence on continuous cloud connectivity, frequent updates, or large local footprints. In practice, the design constraint is as important as the detection logic, because a control that degrades device performance becomes an operational risk itself.
Practical implication: Validate security tooling against device resource limits before deployment, and reject controls that introduce latency or instability.
Why deterministic integrity checks outperform behavioural scoring
Behavioural detection relies on patterns, models, or thresholds, but OT environments often have too little variation for those approaches to be reliable. Deterministic integrity checking compares current code or protected files against an authorised baseline and alerts when an unauthorised change appears. That makes the decision explainable and easier to trust in environments where false positives create real operational cost.
Practical implication: Use baseline-driven integrity monitoring where process stability matters more than probabilistic scoring.
Threat narrative
Attacker objective: The attacker aims to manipulate or disrupt critical operational processes before defenders can stop execution.
- Entry occurs when malicious code reaches an OT device and is injected into memory or another protected execution path.
- Credential_harvested is not the dominant stage here; the critical step is unauthorised code placement before runtime rather than identity theft.
- Escalation follows when the injected code modifies or interferes with a process that controls physical or operational activity.
- Impact is a disrupted control loop, degraded availability, or a cascading failure across the connected infrastructure.
Breaches seen in the wild
- Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.
- Colonial Pipeline ransomware attack: A dormant VPN account with a leaked password and no MFA let DarkSide shut down a major US fuel pipeline for six days.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
OT security fails when defenders wait for runtime evidence. In these environments, the decisive control is not post-execution analysis but the ability to detect unauthorised change before the process is allowed to run. That shifts the control objective from finding malware to preserving operational state. Practitioners should treat pre-execution integrity as a core OT safety requirement, not an advanced enhancement.
Resource constraints are a governance issue, not just an engineering detail. Many security programmes assume agent-heavy tooling can be imposed on every endpoint, but OT devices often have no tolerance for that model. When a control cannot run reliably on the asset it is meant to protect, security policy has failed its fit-for-purpose test. Teams should evaluate tooling against device constraints as part of architecture approval, not after deployment.
Deterministic detection creates a more defensible assurance model for OT. Behavioural scoring can be useful in enterprise IT, but OT operators need alerts they can explain, trust, and act on quickly. That is why change verification and baseline integrity matter so much in safety-sensitive environments. The practical conclusion is that OT assurance should favour simple, provable signals over opaque probabilistic ones.
Crucial infrastructure monitoring should be designed around blast-radius reduction. The most useful OT controls do not promise perfect prevention; they reduce the chance that a single injected change can become a plant-wide or grid-wide incident. That makes visibility inside the device a strategic control point. Practitioners should prioritise monitoring that narrows the impact window before execution begins.
What this signals
Pre-execution integrity becomes the decisive OT control point. When malware can alter process state in seconds, the practical question is not whether a tool can detect threat activity eventually, but whether it can identify unauthorised change before execution. That shifts OT programme design toward integrity and timing rather than only signature coverage or retrospective triage.
Resource-fit testing should be treated like a security control. In constrained environments, a monitoring tool that taxes the device or depends on constant connectivity can create the same operational risk it was meant to reduce. Security teams should therefore make footprint, latency, and offline operation part of procurement and deployment decisions, not afterthoughts.
For practitioners
- Implement pre-execution integrity monitoring Deploy controls that alert when executable code or protected files change before runtime, especially on devices that control physical or safety-sensitive processes.
- Set resource-fit acceptance criteria Measure CPU, memory, latency, and reboot tolerance on representative OT hardware before approving any security tool for production use.
- Prioritise offline-capable monitoring Require monitoring that continues to function without internet access, cloud dependence, or frequent external updates in segmented and semi-air-gapped sites.
- Baseline protected binaries and files Maintain authorised file and code baselines for critical OT assets so unauthorised change can be detected deterministically rather than inferred from behaviour.
- Test alert fidelity under operational load Validate that alerts identify the exact device, file, or code region changed so operators can respond without adding noise to already fragile environments.
Key takeaways
- OT defence breaks down when monitoring starts too late to stop malicious code from altering a live process.
- The central constraint is not only threat sophistication but also whether the security control can run safely on fragile legacy hardware.
- Practitioners should prioritise lightweight, deterministic, offline-capable monitoring that detects unauthorised change before execution.
Related NHI Mgmt Group resources: OT Asset Visibility Guide · Critical Infrastructure Identity Security Guide · OT and ICS Identity and Access Guide · Device and IoT Identity Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0002; TA0005; TA0040 — Execution; Defense Evasion; Impact | The article centers on malware reaching runtime, evading traditional detection, and causing operational impact. |
| Recommendation — Map OT malware scenarios to execution and impact stages, then tune detections to catch change before runtime. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Continuous device monitoring and alerting are the core defensive themes in the OT environment described. |
| Recommendation — Use continuous monitoring to identify unauthorised change on OT assets before it affects operations. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The post relies on verifiable alerts that identify what changed, when, and where on critical systems. |
| Recommendation — Centralise and review integrity-relevant logs so unauthorised code changes are visible and actionable. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Runtime and file integrity monitoring align directly with system monitoring in constrained OT assets. |
| SC-45 — System Time Synchronization | Accurate timestamps are necessary for correlating alerts to device and process changes in OT investigations. | |
| Recommendation — Apply system monitoring controls that detect unauthorised changes without disrupting OT operations. Synchronise OT logs and alerts so change events can be correlated during incident response. | ||
Key terms
- Operational Technology: Operational Technology is the hardware and software that monitors or controls physical processes such as manufacturing lines, utilities, and transportation systems. Unlike standard IT, OT prioritises uptime and safety, so identity controls must be precise enough to reduce risk without interrupting essential operations.
- Pre Execution Detection: Pre execution detection is the ability to identify malicious activity before the payload fully runs. It covers indicators such as suspicious file transfer, archive delivery, staging to disk, sandbox evasion behavior, and script preparation. This control point matters because stopping malware early can prevent persistence, encryption, and data theft.
- Deterministic Detection: Deterministic detection identifies a component from concrete source artefacts such as imports, configuration, API calls, or string constants. It is valuable in audit-heavy environments because it produces repeatable findings that can be traced back to specific code locations and reviewed without relying on model scores or inference guesses.
- Runtime Integrity: Runtime integrity is the assurance that what a system executes matches what defenders expect at the moment of execution. It matters because malware or exploit code can change memory, cache, or process behaviour without changing the on-disk file, which makes artifact-based checks incomplete on their own.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course if you are responsible for identity governance across human, machine, and autonomous systems.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org