It fails when the asset cannot produce SIEM-ready logs or when the network traffic carries only protocol state rather than explicit security events. In those cases, traditional collection misses behavioural context, so defenders cannot tell whether a device is normal, compromised or misused. The control gap is telemetry design, not just log storage.
Why conventional log pipelines break down in OT and IoT
Traditional IT logging assumes systems can emit rich, security-oriented events and that defenders can normalize them into a SIEM. OT and IoT often do neither. Many assets are constrained, fragile, proprietary or vendor-managed, and they expose far less host telemetry than enterprise servers. The result is not just fewer logs, but a different evidentiary model: stateful protocol traffic, command sequences and device behaviour matter more than familiar authentication and audit records.
That is why the failure is usually at the telemetry design layer. If you collect only what an IT estate would normally produce, you miss the signals that show process deviation, unsafe control changes, unusual device commands or abnormal communications between machines.
What you have to observe instead of relying on SIEM-ready events
OT and IoT monitoring works best when it treats network and asset behaviour as the primary evidence source. In practice, defenders need protocol awareness, asset discovery, baseline behaviour and context about what “normal” looks like for a specific device or process. A packet stream that is meaningful in OT may tell you more than a sparse endpoint log, because it can reveal mode changes, write operations, polling patterns or unexpected peer relationships.
This is also where passive monitoring often beats intrusive agents. Many embedded devices cannot tolerate heavy collection, and some cannot run conventional security tooling at all. For those environments, the practical objective is to reconstruct intent from communications and operational patterns, not to force the environment into an IT logging model it was never designed to support.
For a broader operational security baseline around industrial environments, NIST’s OT Security Guide and CISA’s Industrial Control Systems resources both reinforce the same point: visibility has to fit the environment, not the other way around.
How defenders tell normal behaviour from compromise or misuse
The key question in OT and IoT is rarely “did the device log an event?” It is “does the device, the protocol conversation, or the process state now look different from its known-good baseline?” That means defenders should care about timing, sequence, frequency, directionality and allowable command sets, because those are often the only reliable indicators of abuse.
When logging is thin, a compromised asset may look operationally healthy until the surrounding telemetry is interpreted correctly. A device can be misused through valid protocol actions, an attacker can hide inside routine polling, and a malfunction can resemble hostile activity. Traditional IT logging fails here because it expects explicit security events, while OT and IoT often expose only operational side effects.
That is why asset inventory and protocol mapping matter as much as event collection. Without knowing what the device should talk to, what commands it should accept, and what behaviour is ordinary during a given process window, defenders cannot separate benign automation from misuse.
Risk and Threat Considerations
When telemetry is sparse, attackers do not need to suppress logs to remain hidden, they only need to operate inside the blind spots created by an IT-centric monitoring design. In OT and IoT, that can delay detection of unauthorized command execution, unsafe state changes, lateral movement through shared protocols, or covert persistence in devices that cannot generate useful audit trails.
Failure mechanism: A defender builds detection around host logs, authentication events and SIEM-normalized alerts, but the environment primarily exposes protocol state and device behaviour. The monitoring stack then misses the change in intent or process state that actually signals compromise.
Impact: Suspicious activity is discovered late, if at all, and the organization may only learn about misuse after operational impact, process deviation or unsafe equipment behaviour has already occurred.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | OT and IoT visibility depends on defining which events are collected. |
| AU-6 — Audit Review, Analysis, and Reporting | The question centers on missing behavioral context and weak detection. | |
| RA-5 — Vulnerability Monitoring and Scanning | Asset visibility gaps in OT and IoT affect exposure tracking and detection. | |
| Recommendation — Define event sources for OT assets and supplement them with protocol-aware telemetry. Analyze collected telemetry for process deviation and suspicious device behavior. Use safe monitoring methods suited to fragile OT and IoT assets. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Knowing what devices exist is foundational when logs are sparse. |
| CIS-8 — Audit Log Management | The question is about where traditional logging fails and what must replace it. | |
| Recommendation — Maintain an accurate inventory of OT and IoT assets before tuning detections. Collect and centralize only the telemetry sources that are meaningful for each device class. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | The answer depends on monitoring devices and connections, not just logs. |
| Recommendation — Monitor OT and IoT connections and device behavior for anomalies. | ||
Practitioner Guidance
What to prioritise: Start with telemetry design, not log volume. Define which assets can produce meaningful logs, which must be monitored passively, and which protocol fields or state transitions are actually security-relevant for each class of device.
What to verify: Confirm that your monitoring can answer three questions for each critical asset: what is it, what should it talk to, and what behaviours are normal for it. If you cannot answer those from the telemetry you collect, the detection model is incomplete.
Common mistake: Treating OT and IoT logging as a reduced version of IT logging. In these environments, less explicit logging does not mean less risk, it usually means more dependence on behavioural baselines, network context and asset knowledge.
Practitioner takeaway: The control objective is not to force SIEM-style logs out of devices that cannot produce them, but to build trustworthy visibility from the telemetry the environment can actually reveal.
Related resources from NHI Mgmt Group
- Why do traditional network controls often fail in OT and IoT environments?
- Where do traditional device profiling tools fail in mixed IoT and OT environments?
- Why do mixed IT, OT, and IoT environments make logging governance harder?
- How should organisations manage privileged access in IoT and ot environments?