OT telemetry vs OT security: why pipeline design matters

At a glance

What this is: NHI Mgmt Group's analysis, drawing on DataBahn's blog post: OT telemetry is a data pipeline problem and OT security is a defence problem, and treating them as one leaves monitoring tools underfed.

Why it matters: For IAM and security teams supporting OT, the key issue is that controls only work on the data they actually receive, so pipeline coverage and security coverage must be governed separately.

Context

OT telemetry is the operational data produced by industrial systems, while OT security is the set of controls used to defend those systems from attack. The distinction matters because a security stack cannot protect what it cannot see, and visibility in OT depends on collection, normalization, and routing choices that sit upstream of detection.

In hybrid plant environments, the governance problem is not only whether a tool can detect anomalies, but whether the telemetry ever reaches it in usable form. That creates an intersection with identity and access governance when telemetry sources, collectors, and downstream security tools all depend on service accounts, integration credentials, and tightly scoped access paths to move data safely.

Key questions

Q: What breaks when OT telemetry is not fully normalised before security tools use it?

A: Security tools lose context, coverage becomes uneven, and teams pay for detection on an incomplete feed. Normalisation is what turns raw protocol traffic and machine events into data that can be searched, correlated, and retained efficiently. Without it, the plant may be secure on paper but still blind to maintenance abuse or intrusion.

Q: Why does unstructured OT telemetry make security controls less effective?

A: 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.

Q: How do security teams tell whether the problem is coverage or detection?

A: Ask whether the missing evidence is data collection, parsing, or alert logic. If a device can go dark without the team knowing quickly, the likely issue is that telemetry never reached a system capable of alerting on it. If the data is present but no anomalies are flagged, the detection layer needs work.

Q: What should plants do before buying another OT monitoring platform?

A: They should confirm that the existing telemetry pipeline can collect from all relevant sources, normalise multi-protocol traffic, and deliver it without operational disruption. If those steps are incomplete, a new monitoring tool will still see a partial plant floor and simply cost more to operate.

Technical breakdown

OT telemetry collection is a pipeline function

OT telemetry is the raw operational signal from sensors, PLCs, RTUs, and industrial protocols such as Modbus, DNP3, and OPC-UA. Those sources were built to keep systems running, not to feed SIEMs, so the problem is volume, protocol diversity, and constrained environments that cannot tolerate disruptive polling or heavy agents. Collection alone is not enough. The data must also be normalized into a structure security tools can consume and routed to the right destination without breaking operations.

Practical implication: Design collection and normalization as an OT data pipeline, not as a feature hidden inside the security platform.

OT security consumes telemetry but does not create it

OT security includes segmentation, asset discovery, intrusion detection, and vulnerability management tuned for industrial environments. Those controls depend on telemetry to inspect traffic, identify assets, and spot abnormal behaviour. If the feed is thin or inconsistent, even a strong detection stack cannot distinguish maintenance from intrusion. The security layer therefore sits on top of the pipeline, not in place of it. This is why teams that buy detection without fixing collection still end up blind in parts of the plant.

Practical implication: Separate coverage failures from detection failures before you renew or replace an OT security platform.

Telemetry enrichment changes economics before it changes analytics

The article shows that enrichment and filtering are not post-processing chores. They are upstream decisions that determine what reaches the SIEM, what lands in cheaper storage, and what is discarded because it adds no security value. In industrial environments, where SIEM licensing is often volume-based, upstream enrichment can materially reduce cost while improving fidelity. That matters because a pipeline that routes by enriched value can preserve high-signal events without forcing every raw event into expensive retention.

Practical implication: Move enrichment before ingestion so routing decisions are made on context, not raw volume.

Threat narrative

Attacker objective: Exploit the visibility gap created by broken telemetry flow so activity inside the OT environment goes unseen or unclassified.

1. Entry begins when OT telemetry is left uncollected or arrives in a format the security stack cannot use, creating a blind spot rather than a direct attack path.
2. Escalation occurs when the environment has security tooling but no usable data feed, so alerts cannot distinguish routine activity from malicious activity.
3. Impact is a plant that appears monitored on paper but still cannot prove whether a device going dark is maintenance, failure, or intrusion.

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.
• Sumo Logic breach 2023: A compromised credential opened a Sumo Logic AWS account; customers were told to rotate API keys and stored credentials. No data impact was found.

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 visibility fails first at the pipeline, not at the alarm: the central governance mistake in this article is assuming that a detection platform can compensate for missing or unstructured telemetry. In OT, the security control is only as effective as the data feed underneath it. Practitioners should treat telemetry routing as part of the control plane, not as an implementation detail.

Telemetry enrichment is becoming a control boundary of its own: once OT signals must be normalized, filtered, and routed before they are useful, the pipeline starts making security decisions upstream of the SIEM. That changes governance because cost, fidelity, and detection quality now depend on one design layer. Teams should stop evaluating these pipelines as plumbing and start evaluating them as security infrastructure.

Identity governs the movement of OT data as much as the plant governs the machines: the article’s architecture depends on collectors, parsers, and downstream tools that all require controlled access, service credentials, and scoped permissions to move telemetry safely. That creates an identity governance angle for machine accounts and integration trust paths. Practitioners should inventory those access paths as part of OT telemetry governance, not after an incident.

Pipeline design is now a board-level cost and resilience issue: misrouted OT telemetry does not just reduce visibility, it inflates SIEM spend and hides coverage gaps until an audit or incident exposes them. The named concept here is telemetry visibility debt: the accumulated gap between where data exists and where security tools can actually use it. Practitioners should measure that debt before buying more monitoring capacity.

What this signals

Telemetry visibility debt: OT programmes now need a way to measure the distance between where operational data is generated and where security tools can actually use it. That gap often explains both blind spots and overspend, so pipeline design should be governed as part of the security architecture rather than treated as a logging detail.

When collection, parsing, and routing are fixed upstream, the security team gets a cleaner feed without changing the detection layer. That should shift procurement conversations away from feature parity and toward evidence of complete source coverage, protocol handling, and low-impact collection at the edge.

For practitioners

• Map OT telemetry sources separately from OT security tools Inventory PLCs, RTUs, industrial protocols, and any IoT-like sources that generate operational data, then document which ones currently reach a SIEM, data lake, or detection platform in usable form.
• Test whether telemetry is normalized before ingestion Check whether feeds arrive raw, partially parsed, or fully structured, because raw multi-protocol traffic creates separate parsing and routing problems before any detection logic can help.
• Separate coverage decisions from detection decisions Before renewing an OT security platform, identify whether the real failure is missing collection, weak normalization, or weak detection, and fix the earliest failing layer first.
• Validate that collection adds no OT operational burden Confirm that any collector, parser, or edge component will not add load, latency, or disruption that a plant operations team would notice during production.
• Route enriched telemetry beyond the SIEM Send clean OT data to a security data lake or other analysis layer as well as the SIEM, so investigations are not limited by one expensive retention point.

Key takeaways

• OT telemetry and OT security are different layers of the same environment, and collapsing them leaves detection tools underfed.
• The practical failure is usually upstream of the SIEM, where collection, normalisation, and routing determine whether security data is usable at all.
• Teams should assess pipeline coverage before adding more monitoring capacity, because better telemetry flow often produces faster gains than another platform.

Key terms

• OT Telemetry: Telemetry from operational technology includes continuous measurements from physical systems such as sensors, controllers, and industrial equipment. Unlike ordinary security logs, it describes how machines are behaving in real time, which makes it useful for both resilience and attack detection.
• Telemetry pipeline: A telemetry pipeline is the path security data follows from collection to analysis and retention. In mature environments it must preserve context, maintain throughput, and avoid introducing blind spots as sources, formats, and volumes change over time.
• OT Security: OT security is the discipline of protecting industrial environments from compromise, disruption, and unsafe behaviour. It includes segmentation, asset discovery, intrusion detection, and vulnerability handling, but all of those controls depend on receiving reliable telemetry from the plant floor.
• Telemetry Context Debt: Telemetry context debt is the growing gap between raw data volume and the contextual information needed to interpret it correctly. When source lineage, ordering, firmware state, and cohort data are missing, analysis becomes slower, less trustworthy, and harder to reproduce across teams.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps practitioners connect identity controls to the wider security and operational programmes they already run.