Contain it in the pipeline first by deleting or rewriting the label before export, then fix the source instrumentation in the next code cycle. Do not rely on storage expansion as the primary response. That only delays the cost while leaving the growth mechanism untouched.
Why This Matters for Security Teams
A high-cardinality label in production is not just a telemetry nuisance. It can distort dashboards, increase storage and query costs, and overwhelm observability systems that depend on stable, bounded dimensions. The operational risk is that teams start treating symptom management as control maturity, when the real issue is uncontrolled data shape at the source. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports enforcing configuration and system integrity controls rather than allowing unbounded data growth to become a normal state.
Practitioners often miss that cardinality problems behave like a security and resilience issue once they reach production. They create blind spots in alerting, degrade incident triage, and can obscure whether the platform is seeing a real attack, a bad deployment, or a logging defect. In environments with shared pipelines, one bad label can affect multiple services and teams, especially when metrics and logs are aggregated upstream. In practice, many security teams encounter the impact of high-cardinality labels only after queries slow down, costs spike, or detection content starts failing rather than through intentional observability governance.
How It Works in Practice
The correct response is to stop the growth at the ingestion or export layer, then correct the emitting application or service. This means the pipeline should rewrite, drop, hash, or normalize the label before it reaches long-term storage. The goal is to preserve useful telemetry while preventing uncontrolled dimension explosion. The immediate fix is operational containment. The durable fix is source remediation in code, configuration, or schema.
Teams typically handle this in three steps:
- Identify the label key and confirm that it is the driver of the series explosion, not a legitimate business dimension.
- Apply a pipeline control such as allowlisting, relabeling, truncation, or field removal before export.
- Patch the emitting system so the label is bounded, deterministic, and consistent across releases.
From a control perspective, this is consistent with NIST SP 800-53 Rev 5 Security and Privacy Controls around configuration management and system monitoring, because the issue is not simply volume but control over what the system is allowed to emit. Security teams should also verify whether the label is used in alert rules, access logs, or anomaly detection, since removing it blindly can weaken detection logic. If the label is useful but overly granular, best practice is to preserve a reduced form, such as a category or tenant class, rather than the full raw value.
Teams should test the fix under realistic traffic and verify that cardinality returns to an expected baseline. This includes checking metric cardinality, index growth, pipeline memory use, and query latency after the change. These controls tend to break down when instrumentation is generated by multiple services with inconsistent schemas because the same label name can be emitted in different forms and evade simple pipeline rules.
Common Variations and Edge Cases
Tighter label control often increases engineering overhead, requiring organisations to balance observability detail against pipeline stability and cost. The best response can vary depending on whether the label comes from application code, a sidecar, or a shared collector. In some environments, a temporary rewrite is acceptable while a longer-term schema change is developed. In others, especially regulated or customer-facing systems, dropping the field may be safer than preserving unbounded data.
There is no universal standard for this yet, but current guidance suggests preserving only the minimum dimensions needed for operational decisions. If the label is tied to identity data, session identifiers, or tenant-specific context, teams should review privacy and access implications before retaining it in logs or metrics. If the label is introduced by an agent, automation layer, or AI-powered workflow, the same containment logic applies: tool outputs and execution traces must be constrained before they enter shared observability stores. For broader telemetry governance, mapping the response to NIST SP 800-53 Rev 5 Security and Privacy Controls helps teams document the control owner, fix path, and verification step.
The main edge case is when the label is genuinely high-cardinality by design, such as per-request tracing in short-lived analysis environments. Even then, it should usually be isolated from production-grade retention and routed to a separate store with explicit lifecycle limits.
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 surface, NIST CSF 2.0 and CIS Controls set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Label sprawl affects telemetry integrity and data handling discipline. |
| MITRE ATT&CK | T1020 | Excessive data generation can be abused to create noise and degrade monitoring. |
| CIS Controls | 8 | Centralized logging depends on controlled field design and log hygiene. |
| DORA | Operational resilience requires preventing observability blowups in production. |
Restrict telemetry fields and keep production data collection bounded and intentional.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
