TL;DR: OT security fails when detection only starts after malware executes, according to Crytica Security. Legacy devices need deterministic monitoring that catches injected code before it can touch a control process.
Editorial analysis by NHI Mgmt Group, based on content published by Crytica Security: “9 Benefits of RDAi™ for OT Cybersecurity”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: OT defence breaks down when monitoring starts too late to stop malicious code from altering a live process.
Glossary terms: Operational Technology, Pre Execution Detection, Deterministic Detection, Runtime Integrity
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A question worth separating out:
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.
👉 Read our full editorial: OT malware detection shifts to injection-time control in legacy systems