OT telemetry vs OT security: why pipeline design matters

At a glance

What this is: This analysis separates OT telemetry collection from OT security defence and shows that most visibility failures come from pipeline design, not the security tool itself.

Why it matters: For IAM and security practitioners, the lesson is that control effectiveness depends on complete, normalized data flow, which is just as relevant to NHI, human identity, and broader security telemetry programmes.

👉 Read DataBahn's analysis of why OT telemetry and OT security must be separated

Context

OT telemetry is the operational data stream produced by industrial systems, while OT security is the defensive layer that inspects, segments, and detects against attack. The article argues that these are separate functions, and that treating them as one leaves organisations with security tooling that lacks the data it needs to work effectively.

For security teams, the governance problem is familiar even outside OT: collection, normalization, routing, and analysis are different control layers. That distinction matters wherever telemetry feeds security decisions, including identity, NHI, cloud, and SOC programmes. In this case, the article's starting position is typical of many mature OT environments that have bought detection before solving data plumbing.

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 do OT environments need a telemetry pipeline as well as a security platform?

A: Because the pipeline decides what data exists, in what shape, and where it goes, while the security platform decides how to detect and respond. If collection and routing are broken, the defence layer cannot compensate. A mature programme needs both layers, with the pipeline feeding complete and usable telemetry into the detection stack.

Q: How should teams decide whether to fix data collection or buy more OT security tooling?

A: Start with a coverage review. If sources are missing, protocols are unparsed, or telemetry reaches the SIEM raw and unusable, the problem is collection and normalization. If the feed is complete but alerts are weak, the problem is detection. That distinction prevents budget from being spent on the wrong layer.

Q: What is the difference between OT telemetry and OT security in practice?

A: OT telemetry is the data produced by industrial systems, and OT security is the set of controls that defend those systems from attack. Telemetry is the input, security is the response. When organisations confuse them, they often buy monitoring before they have a reliable pipeline, which leaves both visibility and defence incomplete.

Technical breakdown

OT telemetry collection and normalization are pipeline problems

OT telemetry is raw machine output such as PLC readings, protocol traffic, asset logs, and configuration events. Those signals were built to support operations uptime, not security analytics, so they often arrive in inconsistent formats across Modbus, DNP3, OPC-UA, and similar protocols. Normalization is the step that converts that raw flow into a structure a SIEM or data lake can use. If the pipeline cannot collect, parse, and route the data without adding load or latency, downstream security tools receive partial visibility no matter how strong the detection logic is.

Practical implication: separate source onboarding and parsing work from detection engineering so telemetry coverage can be improved independently.

OT security tools consume telemetry, they do not create it

OT security platforms defend the environment by inspecting traffic, discovering assets, spotting anomalies, and mapping vulnerabilities. They depend on telemetry to do that work, which means their effectiveness is bounded by the quality of the feed they receive. A plant can have strong segmentation and still miss an intrusion if telemetry never arrives in a usable form. The security layer therefore sits on top of the pipeline layer, and the two must be engineered as complementary controls rather than competing purchase categories.

Practical implication: evaluate whether the current gap is data coverage or detection capability before buying another monitoring product.

Why SIEM visibility fails when enrichment happens too late

The article's central technical point is that enrichment should happen before data reaches the SIEM. If raw telemetry lands first and gets processed later, teams pay ingestion costs before they know whether the event has security value. Pre-indexed lookups, caching, and asynchronous enrichment keep the stream moving while adding context in flight. That changes the economics and the control outcome: enriched events can be routed to high-value retention, while routine or low-value data can be stored more cheaply without losing investigative usefulness.

Practical implication: move enrichment upstream so routing decisions are made on context, not raw volume.

Threat narrative

Attacker objective: The attacker benefits from unnoticed activity inside OT environments by exploiting the organisation's lack of complete, security-ready telemetry.

1. Entry occurs when a security team relies on a partial telemetry feed that misses plant-floor sources, protocols, or normalized context.
2. Escalation happens because OT security tools can only inspect what the pipeline delivers, so blind spots remain even when detection platforms are present.
3. Impact is delayed recognition of intrusion or maintenance abuse, with teams discovering the gap only after an audit or operational incident.

NHI Mgmt Group analysis

Telemetry enrichment is becoming a security control, not a plumbing task: once data feeds determine what a SOC can see and retain, the pipeline becomes part of the control stack. That changes procurement logic, because coverage gaps cannot be solved by adding another detector on top of a broken feed. Practitioners should treat enrichment, routing, and normalization as governed security functions, not just data engineering.

OT visibility failures often reflect control-layer confusion rather than tool weakness: many programmes buy detection before solving source onboarding, parsing, and protocol diversity. The result is an expensive illusion of coverage, where licenses are sized for visibility the environment does not actually produce. Practitioners should reframe the problem as a data governance issue first and a detection issue second.

Data plane and defence plane must be separated conceptually: OT telemetry describes what the environment is doing, while OT security decides what to do about it. Conflating those layers creates budget waste and operational blind spots. The named concept here is telemetry coverage debt: the accumulated risk created when security tools depend on data sources the organisation has never fully onboarded. Practitioners should measure that debt explicitly.

This same control distinction shows up across identity and NHI programmes: access governance, event logging, and secret lifecycle controls all fail when the underlying data pipeline is incomplete or untrusted. That is why telemetry quality matters to IAM, PAM, and NHI governance as much as it matters to OT. Practitioners should align security tooling with the data it truly receives, not the data it assumes.

What this signals

Telemetry coverage debt: teams that defer source onboarding and normalization create hidden operational risk that looks like a tooling gap until an incident exposes it. The smarter programme move is to treat data availability as a governed control objective, then measure whether collection and routing meet that objective across OT, identity, and cloud data flows.

Where OT telemetry, identity logs, and NHI events converge, the decisive question is not how many platforms are deployed but whether the organisation can trust the feed those platforms receive. That pushes practitioners toward pipeline governance, evidence-backed coverage reporting, and tighter alignment between security operations and data engineering.

For practitioners

• Map telemetry coverage before renewing tools Inventory every OT and IoT source, then document which feeds reach a SIEM, data lake, or detection platform in raw or normalized form. This reveals whether the real problem is source coverage, parsing, or detection.
• Separate collection gaps from detection gaps Run a renewal review that asks whether the failure is incomplete collection, malformed parsing, or weak alerting. Assign remediation to the correct layer instead of expecting one platform to fix all three.
• Push enrichment upstream of the SIEM Attach asset identity, protocol context, and threat intelligence during collection or stream processing so routing decisions happen before ingestion costs are incurred.
• Validate OT-safe collection methods Confirm that collection and normalization do not introduce load, latency, or protocol disruption that plant operations cannot tolerate.
• Route clean telemetry beyond the SIEM Send enriched OT data to a security data lake and any analytics tools that need it, so investigation and hunting do not depend on a single expensive destination.

Key takeaways

• OT telemetry and OT security are separate layers, and confusing them leaves organisations with incomplete visibility and misplaced spending.
• The real control gap is usually in collection, normalization, and routing, not in the detection tool sitting downstream.
• Practical improvement comes from fixing telemetry coverage debt before adding another monitoring platform to the stack.

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 Normalization: Telemetry normalization is the process of turning data from different security tools into a consistent format that can support one policy decision. It is essential when identity, endpoint, and asset systems all feed the same control plane, because conflicting data can otherwise create gaps or overblocking.
• Security data pipeline: A security data pipeline is the chain that ingests, filters, enriches, normalises, and routes telemetry before it reaches storage or analytics. In practice, it determines which evidence survives into detection, investigation, and compliance workflows, so it is part of the control environment, not just infrastructure plumbing.
• Telemetry Coverage: Telemetry coverage is the extent to which logs, events, and operational signals are captured from the systems that matter. Good coverage means the security team can investigate, correlate, and prove what happened without relying on partial or ad hoc evidence.

What's in the full article

DataBahn's full article covers the operational detail this post intentionally leaves for the source:

• How its collection layer separates source discovery, parsing, and enrichment across OT protocols
• How telemetry routing is used to reduce SIEM ingestion cost without losing investigative value
• How the pipeline is designed to avoid latency or load on OT environments
• How the data control plane maps sources, transformation, and routing across security destinations

👉 The full DataBahn article covers the pipeline architecture, collection mechanics, and routing logic in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the broader programmes they operate.