Every unique label combination usually becomes a separate time series, so cardinality increases storage, ingest volume, and query workload at the same time. That raises licensing or custom metric spend, makes aggregations slower, and can overload time series infrastructure when many dynamic labels arrive from autoscaling systems or user specific metrics.
Why This Matters for Security Teams
High cardinality is not just a cost issue. In observability, it can distort the very signals that security teams rely on for detection, triage, and root-cause analysis. When label sets explode, engineers often respond by dropping dimensions, sampling more aggressively, or narrowing retention windows. That may reduce spend, but it can also erase context needed to investigate outages, suspicious activity, or privilege misuse.
For security operations, the risk is operational blind spots. A platform that is saturated by noisy or highly variable labels may still look healthy on the surface while query latency climbs, dashboards lag, and alerts miss important patterns. This is especially problematic in cloud-native environments where autoscaling, ephemeral workloads, and user-level instrumentation all generate rapidly changing metrics. NIST Cybersecurity Framework 2.0 remains useful here because it emphasizes resilience, monitoring discipline, and governance over technical controls that are allowed to grow without review. NIST Cybersecurity Framework 2.0
In practice, many security teams encounter cardinality-driven observability failures only after an incident has already stretched the platform past its design limits, rather than through intentional capacity planning.
How It Works in Practice
Most observability backends treat each unique metric plus label combination as a distinct time series. That means a single metric can multiply rapidly when labels include request IDs, user IDs, container hashes, pod names, session tokens, or other values that change constantly. Storage grows because each series consumes index, metadata, and retention space. Ingest grows because the backend must process and route every new series. Query cost rises because aggregations must scan more series, often across more shards or partitions.
Security and platform teams usually feel the pain in three places:
Ingest pipelines slow down when too many new series arrive at once, especially during autoscaling events.
Query performance degrades when dashboards or hunts need to aggregate across high-volume label dimensions.
Licensing or usage-based billing increases when the platform counts active time series, samples, or custom metrics.
The practical control is to treat labels as a governed data model, not an ad hoc engineering convenience. That means reviewing which dimensions are required for operational diagnosis, which are useful only for debugging, and which should be removed or normalized before ingestion. Best practice is to preserve low-cardinality labels such as service name, region, environment, and outcome, while avoiding identifiers that change per request or per user unless there is a clear investigative need.
In mature environments, teams also enforce telemetry budgets, schema reviews, and alerts for series growth so that cardinality drift is detected before it affects response time or cost. Current guidance suggests that observability governance should be applied the same way as log retention or endpoint telemetry governance: by default, controlled and explicitly justified. These controls tend to break down when teams instrument multi-tenant SaaS systems with user-specific labels because the same metric pattern can multiply across every tenant, cluster, and release version.
Common Variations and Edge Cases
Tighter label control often reduces diagnostic flexibility, requiring organisations to balance lower cost against the loss of fine-grained troubleshooting detail.
There is no universal standard for how much cardinality is “too much,” because acceptable thresholds depend on backend architecture, retention period, query patterns, and budget model. A label set that is harmless in one platform may be expensive in another if the system indexes series differently or charges per active metric. That is why guidance is usually operational rather than absolute: control the dimensions that expand without adding real decision value, and keep the labels that support incident response, service ownership, and security correlation.
Edge cases matter. Short-lived debug metrics, per-user analytics, and tracing-derived labels can be valuable for limited windows, but they should not be promoted into always-on production metrics without review. Likewise, security teams sometimes need high-cardinality dimensions for investigations, but that need is better met through targeted logs, traces, or on-demand sampling rather than permanent metric expansion. The right answer is often a tiered telemetry strategy, not a blanket ban.
Where this guidance becomes less effective is in environments that depend on highly dynamic, multi-tenant workloads and have no schema enforcement at the instrumentation layer, because uncontrolled labels can appear faster than platform governance can remove them.
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 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 |
|---|---|---|
| NIST CSF 2.0 | GV.PO-1 | Cardinality governance depends on telemetry policy and ownership. |
| MITRE ATT&CK | T1078 | Credential misuse is often investigated through metrics and logs that need stable cardinality. |
| NIST Zero Trust (SP 800-207) | SC-4 | Telemetry must support trust decisions without becoming an unmanaged data source. |
Limit and structure observability data so monitoring supports access decisions without excess exposure.
Related resources from NHI Mgmt Group
- Why do leaked API tokens create such high cost risk in AI application platforms?
- Why do email platforms create such high identity risk during active exploitation?
- Why do workflow automation platforms create such high lateral movement risk?
- Why do high-cardinality metric tags create such a cost problem?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
