Because security tools cannot reason over data they cannot parse consistently. Industrial protocols, raw machine states, and firmware logs often arrive in different shapes, so a control built for structured events will miss context or drop the feed into noise. That is why collection and normalisation are security enablers, not back-office tasks.
Why unstructured OT telemetry weakens control effectiveness
Security controls work best when they can compare events against a predictable schema, but OT data often arrives as vendor-specific protocol fields, raw device states, free-form logs, or partially captured records. That makes correlation, policy evaluation, and alert tuning brittle. Normalisation is therefore part of the control surface, because it determines whether the control can see what happened at all.
How bad data shape turns good controls into partial controls
Unstructured telemetry does not just reduce analyst convenience. It changes the behaviour of detection and enforcement itself. A rule that expects consistent asset IDs, timestamps, state transitions, or command verbs may fail to match, while a broader rule may over-alert because it cannot separate routine process noise from genuine deviation. The result is lower signal quality, weaker baselining, and more blind spots across industrial zones and conduits.
In OT environments, this is especially painful because many meaningful security questions depend on context that is easy to lose: which controller generated the event, whether a write action was authorised, whether the reading reflects a real process change, and whether the source is a sensor, gateway, historian, or engineering workstation. If that context is fragmented, the control may still run, but it cannot reliably decide what is normal, suspicious, or urgent.
What security teams need to build around the telemetry layer
Collection design matters as much as the control itself. Teams should standardise ingestion where possible, preserve protocol context, map raw fields to a stable asset and event model, and retain the original record for investigation and forensics. For OT, that often means combining passive collection, protocol decoding, and asset inventory so the security stack is operating on meaning rather than on disconnected fragments.
That is why frameworks that emphasise control depth and OT segmentation are useful here. NIST SP 800-82 Rev 3, OT Security Guide is a practical reference for understanding why architecture, segmentation, and environment-specific monitoring need to reflect industrial realities, while CISA Industrial Control Systems resources are useful for aligning detection and defensive planning to the kinds of constraints OT operators actually face. At the control level, NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant because audit, access, integrity, and configuration controls all depend on receiving usable event data.
Risk and Threat Considerations
Poorly structured ot telemetry creates a real security exposure because it can hide abnormal commands, suppress correlation across systems, and make alerting depend on human interpretation instead of control logic. In practice, that increases the chance that an attacker, a misconfiguration, or a failing process will look like routine operational noise until the window for action has narrowed.
Failure mechanism: Telemetry arrives with inconsistent schemas, missing fields, or ambiguous device context, so detection rules, baselines, and correlation engines cannot reliably interpret the event stream.
Impact: Controls miss meaningful deviations, produce noisy alerts, and provide weaker evidence for incident triage, which reduces both prevention and response quality in industrial environments.
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 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | OT telemetry quality affects which events can be captured and correlated. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Normalized telemetry is needed to review and analyze OT audit records effectively. | |
| SI-4 — System Monitoring | System monitoring in OT depends on parseable telemetry with stable context. | |
| Recommendation — Define audit events that preserve OT context and support reliable correlation. Tune analysis workflows to handle structured and decoded OT event records. Monitor OT systems with normalized telemetry and source context preserved. | ||
Practitioner Guidance
What to verify: Confirm that every OT data source can be mapped to a stable asset identity, protocol type, and event taxonomy before you treat it as a trusted control input. If a feed cannot support correlation at that level, it should not be the sole basis for detection or automated response.
What good looks like: The control layer should see a consistent event shape even when devices speak different protocols. That usually means preserving the raw source, normalising only the fields you can trust, and measuring how much context is lost during ingestion.
Practitioner takeaway: In OT, visibility is not just about collecting more telemetry, it is about turning messy telemetry into operationally meaningful data, or every downstream control becomes less precise than it appears.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org