TL;DR: AI speeds up cyber analysis but still infers compromise from patterns, and Crytica Security’s analysis argues that OT and IoT defenders need device-level detection because external signals can look normal after unauthorized change. In constrained environments, deterministic change detection is the control boundary that matters more than faster probability scoring.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Crytica Security's blog post: AI accelerates detection in OT and IoT, but only device-level change detection turns uncertainty into a concrete security event.
Why it matters: OT and IoT defenders need evidence they can trust before they isolate devices or interrupt physical processes, and that requires detection at the point where change actually occurs.
Context
AI-assisted detection in OT and IoT is often forced to work from incomplete evidence because embedded devices are hard to observe from the outside. When the sensor sits outside the system, the security team sees symptoms, not the actual instruction change, which leaves a gap between alerting and trustworthy action.
Device and IoT identity guide This gap becomes more serious when devices are constrained enough that traditional endpoint tooling cannot run inside them without affecting service. In that setting, the security problem is not only analysis speed but whether the detection model is physically close enough to the asset to see unauthorized change as it happens.
Key questions
Q: How should teams detect unauthorized change in OT devices?
A: Teams should detect unauthorised change by comparing the device state itself, such as firmware hash, configuration, logic, mode and approved setpoints, against a trusted baseline. Use authenticated polling, signed configuration records, asset inventory and change-control correlation, because packet inspection alone can miss local tampering, unauthorised downloads and silent logic changes.
Q: Why does behavioural AI struggle in OT monitoring?
A: Behavioural AI struggles in OT monitoring because industrial devices and processes are designed to be predictable, so normal operation often looks repetitive rather than richly varied. Small changes can be safety-relevant, while legitimate maintenance, batch cycles and failover can look anomalous, making models prone to false positives and missed context without process-aware baselines.
Q: How does deterministic detection differ from anomaly detection?
A: Deterministic detection looks for known conditions, rules or state deviations, such as an unauthorised firmware checksum or a prohibited PLC command. Anomaly detection learns a baseline of normal activity and flags departures from it, which can catch unknown issues but is less explainable and more sensitive to process changes in OT environments.
Q: What happens when OT alerts are based on external telemetry only?
A: If OT alerts rely only on external telemetry, they can miss what the asset itself is doing, including local logic edits, mode changes, unauthorised firmware loads and operator actions taken outside the monitored network path. External feeds are useful, but they need correlation with device state, controller logs and change records to avoid blind spots.
Technical breakdown
Why probabilistic detection stays uncertain in OT
Most AI-driven detection models infer compromise from behavioural deviation, similarity to known malware, or anomaly scoring. That works when the evidence is rich and the environment is stable, but those assumptions are weak in OT. Industrial and embedded systems change over time, and normal variation can look suspicious while malicious change can still look routine. The model therefore estimates likelihood rather than directly observing a security-relevant state change. In practice, that means the detection engine may be fast, but it is still interpreting ambiguous signals rather than verifying whether the device’s instruction set has been altered. See the IoT Security Guide.
Practical implication: Treat anomaly scoring as triage, not proof, when the system cannot observe the underlying device state directly.
How device-level change detection differs from behavioural analytics
Deterministic detection starts from a different premise: if an instruction set changes outside an approved process, that change itself is the event of concern. Instead of asking whether a file, process, or sequence resembles malware, the detector compares successive scans and identifies additions, deletions, or modifications that should not have occurred. That shifts the question from suspicion to validation. The value is not in predicting malicious intent, but in identifying unauthorized state change at the point where the device actually executes work. For OT and IoT, that is a more stable control boundary than externally inferred behaviour.
Practical implication: Anchor detection on unauthorized state change so the alert is tied to a concrete control violation, not a probabilistic estimate.
Why constrained devices change the security architecture
Embedded systems often cannot support heavyweight endpoint agents without creating performance or reliability problems, so security teams rely on network traffic, logs, and other external clues. That architecture creates a blind spot: a compromised device can continue to appear healthy while its internal instructions have already been altered. Lightweight on-device sensing narrows that blind spot because it places detection at the point of execution. The mechanism matters as much as the model. Without an in-device presence, even a sophisticated analytics layer is still reasoning about surface evidence rather than confirming what has changed inside the asset. See the Device and IoT Identity Guide.
Practical implication: Design OT monitoring around what the device can safely host, not around what the SOC wishes it could observe.
Threat narrative
Attacker objective: To alter an operational device in a way that avoids immediate certainty and delays defensive response.
- Entry occurs when an attacker, failed update, or unauthorized operator action changes the device state outside the approved process.
- Escalation happens when that altered instruction set continues executing while external telemetry still appears normal.
- Impact follows when defenders are forced to decide whether to isolate a device or interrupt a physical process without a deterministic trigger.
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.
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
Faster analysis does not remove uncertainty from OT detection: AI can accelerate triage, but when the underlying signal is behavioural it still leaves operators with a probability judgment. In OT and IoT, that is a governance problem as much as a technical one because response decisions can affect physical processes. Security teams need a detection model that turns suspicion into a verifiable event before they act.
Device-level visibility is the missing control in constrained environments: The core failure mode is not just poor analytics, but the absence of a trustworthy observation point inside the asset. When defenders only see network traffic and logs, they are always one step removed from the actual change. IoT Security Guide is relevant here because it frames the same operational reality: device constraints shape what controls are actually possible.
Deterministic detection creates a clearer security contract: If the instruction set changed outside an authorized process, the device has crossed a line that analysts can investigate without debating whether an anomaly is meaningful. That sharper contract reduces ambiguity for incident response, asset owners, and service operators alike. The practical result is better prioritisation, not just faster alerting.
OT detection gap: The real problem is the gap between observed behaviour and actual device state. When a control can only infer compromise from symptoms, attackers and operational failures can look alike until late in the response cycle. A control that detects unauthorized change at the device boundary narrows that gap and gives defenders a defensible basis for intervention.
AI belongs after detection, not before certainty: The strongest role for AI in this model is context enrichment after a concrete device change is found. That ordering matters because teams should not use probabilistic interpretation as the trigger for disruptive action in critical environments. The field should treat certainty of change as the prerequisite for orchestration, not a by-product of it.
What this signals
OT detection should move closer to the asset: As embedded systems become more constrained, the security model has to shift from remote interpretation to local verification. That changes procurement and architecture decisions because the question is no longer which analytics layer is smartest, but which control can actually observe the change where it occurs.
Detection certainty will matter more than alert volume: The next phase of OT security will reward tools that reduce ambiguity before response workflows begin. That means defenders should expect more scrutiny on whether a platform can confirm unauthorized device change, not merely score unusual activity.
AI will remain valuable, but only after a trusted event exists: The strongest operational pattern is deterministic detection first, then AI-assisted context and correlation. That ordering helps teams avoid acting on uncertainty in environments where a mistaken response can interrupt physical services.
For practitioners
- Monitor for unauthorized instruction-set changes Place detection logic at the device boundary so the alert is triggered by additions, deletions, or modifications that occur outside approved change management.
- Separate triage from isolation decisions Require a deterministic device-level event before taking disruptive response actions in OT or IoT environments, especially where service interruption has physical consequences.
- Test whether current tooling sees state or symptoms Validate whether network logs, status responses, and external telemetry are only inferring compromise, then document where that leaves blind spots in embedded assets.
- Keep AI in the investigation layer Use AI to correlate context after a concrete change is detected, rather than as the primary trigger for action in constrained operational environments.
Key takeaways
- AI can speed up cybersecurity analysis without eliminating the uncertainty that comes from inferential detection models.
- OT and IoT environments magnify that uncertainty because external telemetry can look normal even when internal device state has changed.
- The most defensible control is detection that verifies unauthorized change inside the device, then lets AI assist with context and response.
Related NHI Mgmt Group resources: IoT Security Guide · Device and IoT Identity Guide · IoT Security Buyer's 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 and OWASP API Security Top 10 address 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 | TA0007;TA0006 — Discovery; Credential Access | Behavioural alerts and unauthorized device change map to adversary activity detection and access abuse patterns. |
| Recommendation — Map OT anomaly workflows to ATT&CK and investigate for access abuse when device state changes unexpectedly. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and environments are monitored to detect potential cybersecurity events | The article is about whether OT monitoring can detect events at the point of change rather than by inference. |
| Recommendation — Use DE.CM-01 to verify that monitoring reaches the device boundary where change actually occurs. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The article contrasts evidence from logs with direct device change detection in constrained environments. |
| Recommendation — Correlate device-change alerts with logs and telemetry under CIS-8 to reduce ambiguity during response. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | SI-4 is directly relevant to monitoring device state and detecting unauthorized change in OT systems. |
| Recommendation — Apply SI-4 to monitor system state at the device level, not only through external symptoms. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article's constrained-device theme includes the risk of placing controls where they cannot operate effectively. |
| Recommendation — Treat unsupported or overlarge agents as misconfiguration risk when they cannot run safely inside the asset. | ||
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.
- Instruction Set: An instruction set is the complete set of machine commands a processor can execute. It defines the operations, registers, addressing modes and encodings available to software, and differs by CPU architecture. Security-relevant issues usually arise from how code is compiled, emulated or isolated across different instruction sets.
- IoT device: An IoT device is a network-connected physical device that collects, sends or acts on data, often with limited built-in security controls. Attackers exploit weak passwords, outdated firmware and exposed services to pivot into networks or steal data. Defenders should inventory devices, isolate them, patch them and monitor their traffic and identity.
- Anomaly Detection: Anomaly detection is the use of rules, statistics, or behavioural models to identify access patterns that differ from the expected baseline. In identity programmes, it helps surface compromised credentials, misuse of service accounts, and suspicious changes in authentication or access behaviour.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to broader security operations and risk decisions.
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