Notifications
Clear all
Topic starter
18/08/2026 3:00 pm
TL;DR: Security data pipelines are emerging as a distinct control plane because SIEM costs, noisy telemetry, and inconsistent schemas are undermining both detection quality and operating efficiency, according to Axoflow. The shift matters because identity logs, cloud signals, and endpoint data now need upstream governance before they reach SIEMs and AI tools.
NHIMG editorial — based on content published by Axoflow: Security Data Pipelines: What Analysts, Customers, and Prospects Are Saying About Security Data Needs
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams decide which telemetry belongs in the SIEM?
A: Start with investigative value, not source count.
Q: Why do security data pipelines matter for identity and NHI logs?
A: Identity and NHI events are only useful if they are structured, complete, and comparable across systems.
Q: What breaks when telemetry is routed without policy controls?
A: Uncontrolled routing can duplicate sensitive events across systems, inflate cost, and create inconsistent retention or access rules.
Practitioner guidance
- Classify high-value telemetry before SIEM ingestion Define which identity, cloud, endpoint, and SaaS events deserve enrichment, normalization, or drop rules in the pipeline rather than downstream in the SIEM.
- Separate telemetry engineering from detection content Assign ownership for schema standardization, routing, and filtering to a pipeline team while detection engineers focus on use cases and alert logic.
- Standardize identity and NHI event schemas Normalize service account, OAuth, token, and authentication logs into a common structure so correlation and AI-assisted analysis can rely on consistent fields.
What's in the full article
Axoflow's full post covers the operational detail this post intentionally leaves for the source:
- Specific pipeline patterns for routing low-value logs to cold storage while preserving high-value security events for SIEM use
- Implementation detail on schema normalization and enrichment before data reaches detection tooling
- Practical examples of how unified telemetry reduces rework when replacing or adding analytics platforms
- Discussion of autonomous data-layer controls for cost management, compliance, and pipeline health monitoring
👉 Read Axoflow's analysis of security data pipelines as a SOC control plane →
Security data pipelines: what SOC and IAM teams need to change?
Explore further
18/08/2026 3:40 pm
Security data pipelines are becoming the control plane for telemetry governance. The article is right to frame this as a distinct architectural layer rather than a logging sidecar. Once security teams depend on dozens of sources and multiple consumers, control over routing, normalization, and retention becomes a governance decision with direct security impact. For identity-heavy environments, that governance layer must account for service accounts, OAuth activity, and other NHI signals as first-class telemetry.
A question worth separating out:
Q: What should organisations do first when building a security data pipeline strategy?
A: Start by identifying the telemetry classes that drive investigations and detections, then define how each class should be enriched, normalized, retained, or discarded. Prioritise identity, cloud, and endpoint signals that create the most investigative value. That creates a practical baseline before automation and AI use cases are added.
👉 Read our full editorial: Security data pipelines are becoming the control plane for SOC data
