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.
Telemetry defines what OT can see, security defines what OT can do with it
OT environments need both layers because telemetry is the evidence plane, while the security platform is the decision plane. The pipeline determines which signals are collected from controllers, historians, endpoints and network segments, how they are normalised, and whether they arrive in time to be useful. The platform then correlates, prioritises and responds. If the pipeline is incomplete, delayed or dropped, the best detection content never sees the event.
That distinction matters most in OT because many assets are fragile, intermittently connected or vendor-managed, so “ingest everything” is rarely realistic. A useful pipeline preserves enough fidelity to support alerting without overwhelming analysts or disrupting operations, and it must keep time, source and context intact so the platform can make sense of the data. CI/CD pipeline exploitation case study is a useful reminder that control-plane weaknesses often start upstream of detection.
In practice, teams usually discover telemetry gaps only after an incident forces them to ask why the platform had nothing useful to work with.
How the pipeline and platform work together in practice
The telemetry pipeline is responsible for collection, filtering, transport, parsing and enrichment. In OT, that often means combining passive network visibility with carefully chosen logs from engineering workstations, jump hosts, historians and remote access points. The security platform consumes that stream, applies detections, and drives alert triage, incident response and reporting. Both layers have to agree on time synchronisation, asset identity, severity mapping and retention, or the resulting detections become noisy and hard to action.
The pipeline should preserve raw evidence where possible, then create analysis-ready views for the platform.
The platform should assume some telemetry will be delayed, lossy or partial, and detections should be written with that constraint in mind.
OT-specific context, such as process state, engineering change windows and asset criticality, should be added before the platform attempts prioritisation.
A good test is whether an operator can reconstruct what happened without leaving the tooling stack. If the pipeline drops sequence, context or timestamps, the platform may still generate an alert, but it will lack the evidence needed to distinguish maintenance, misconfiguration and malicious change. That is why pipeline health, parsing quality and coverage should be treated as operational security controls, not mere plumbing. The Guide to the Secret Sprawl Challenge illustrates how weak upstream handling of sensitive artefacts can create downstream visibility problems that security tooling alone cannot undo.
These controls tend to break down when OT traffic is highly proprietary, latency-sensitive or segmented across sites, because the pipeline is then forced to trade completeness against stability.
Coverage gaps, latency trade-offs and where the model breaks
Tighter telemetry collection often increases operational overhead, so organisations have to balance visibility against system fragility. OT rarely tolerates heavyweight agents or aggressive inspection everywhere, which is why many programmes rely on a blend of passive capture, selective logging and asset-tiering. There is no universal standard for how much telemetry is “enough”, but the decision should be driven by consequence: critical control paths, remote access, privileged changes and safety-relevant assets deserve the strongest coverage.
Edge cases matter. Some sites will have excellent network visibility but weak endpoint telemetry; others will have vendor remote support channels that bypass normal logging; others still will have data, but in formats the platform cannot reliably parse. In those environments, the pipeline is often the limiting factor even when the security stack is mature. That is also why timing matters: OT detections that arrive after a process has already moved out of state may still be useful for forensics, but they are weaker for prevention or interruption. The most reliable answer is to design for graceful degradation, not perfect collection. OWASP Non-Human Identity Top 10 is relevant where OT telemetry depends on service identities, tokens or integrations that must themselves be governed and monitored.
Practitioner takeaway: in OT, the platform can only defend what the pipeline successfully delivers, so coverage, quality and timeliness should be governed as first-class security outcomes rather than implementation details.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 8 — Audit Log Management | OT telemetry pipelines must collect, retain and protect logs for detection and investigation. |
| 12 — Network Infrastructure Management | OT telemetry depends on network paths, segmentation and transport reliability. | |
| 13 — Network Monitoring and Defense | The security platform consumes telemetry to detect suspicious OT activity. | |
| Recommendation — Centralise and protect OT logs so detections have usable evidence. Harden telemetry transport and segmentation to keep signals flowing. Use network monitoring to turn collected OT telemetry into alerts. | ||
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | OT needs continuous monitoring inputs from the pipeline to support detection. |
| RS.AN — Analysis | The platform must analyse telemetry that the pipeline delivers with enough context. | |
| Recommendation — Ensure monitoring coverage includes the OT telemetry pipeline. Analyse OT telemetry with asset and process context before response. | ||
| NIST Zero Trust (SP 800-207) | PR.AC-1 — Policy and Access Enforcement | Telemetry and security controls depend on enforced access and trust boundaries. |
| Recommendation — Enforce access boundaries around OT telemetry sources and collectors. | ||
| MITRE ATT&CK | T1020 — Data Exfiltration | Telemetry gaps can hide attacker extraction or misuse of OT data paths. |
| Recommendation — Map missing telemetry to possible exfiltration activity. | ||
Practitioner Guidance
What to prioritise: Start with the telemetry sources that cover remote access, privileged change paths, engineering workstations and the most safety-critical assets. Those paths usually determine whether an investigation has enough context to be trustworthy.
What to verify: Confirm that the pipeline preserves source, timestamp, asset context and ordering well enough for the platform to correlate events across sites. If those fields are inconsistent, the platform will over-alert or miss sequence-dependent activity.
Decision rule: If a control or sensor choice improves visibility but destabilises the OT process, reduce scope and keep the pipeline passive enough to be safe, then compensate with better enrichment and better prioritisation in the platform.
What practitioners underestimate: The hardest failure is not total loss of telemetry, but partial loss that looks complete enough to create false confidence. A pipeline that delivers some data reliably is usually better than an ambitious design that drops critical events during peak load or maintenance windows.
Practitioner takeaway: Treat the pipeline as the mechanism that makes detection possible, and treat the platform as the mechanism that makes the evidence actionable; neither layer is optional if the environment must be both observable and safe.
Related resources from NHI Mgmt Group
- Why do IoT and ot environments create different security risks from standard IT systems?
- How should security teams govern machine identities in OT environments?
- How should security teams govern machine identities in OT to IT environments?
- How should security teams govern remote privileged access in OT environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
