Cardinality

Expanded Definition

Cardinality in telemetry is a data-shape property, not a security control. It describes how many distinct combinations a metric or event field can produce once labels, attributes, or dimensions are attached. In observability and security operations, high cardinality is often useful at first because it preserves context, but it quickly creates scale pressure when every user ID, request path, container, device, or API token becomes part of the series key. That is why cardinality is usually discussed alongside ingestion limits, query performance, and retention cost rather than as a pure analytics concept.

Definitions vary across vendors on where the boundary sits between acceptable dimensionality and problematic series explosion, so the practical test is whether the data remains queryable, affordable, and operationally meaningful. NIST’s NIST Cybersecurity Framework 2.0 does not define cardinality directly, but its governance emphasis on visibility and continuous improvement makes telemetry hygiene relevant to security outcomes. The most common misapplication is treating all labels as harmless metadata, which occurs when teams export raw identifiers without considering how many unique series those attributes will generate.

Examples and Use Cases

Implementing cardinality rigorously often introduces a tradeoff between diagnostic precision and platform efficiency, requiring organisations to weigh richer troubleshooting context against higher storage and query costs.

• Application tracing includes a request ID, user email, and full URL path in every metric label, creating a rapidly expanding series count that obscures rather than clarifies service health.
• Security teams normalise account identifiers before export so that one identity does not generate thousands of distinct metric series across regions, tenants, or sessions.
• Container environments drop volatile labels such as pod UID or ephemeral file path when exporting to a central backend, keeping dashboards usable during autoscaling events.
• Detection engineering preserves high-value dimensions like role, workload type, or authentication outcome while removing low-signal uniqueness that would otherwise inflate telemetry costs.
• Platform teams use guidance from the NIST Cybersecurity Framework 2.0 to justify data minimisation decisions that support monitoring without overwhelming analytics pipelines.

Why It Matters for Security Teams

Security teams need to understand cardinality because telemetry overload can hide the very signals they are collecting data to find. Excessive uniqueness increases backend load, slows investigation workflows, and can force teams to disable useful fields altogether when retention budgets or query performance collapse. That creates blind spots in detection engineering, incident response, and compliance reporting. The issue is especially important in identity-heavy environments where usernames, service principals, API keys, device IDs, and agent identifiers can each multiply the number of series if they are exported without normalisation.

This matters even more in NHI and agentic AI deployments, where every workload or agent can emit distinct contextual attributes at machine speed. Without cardinality discipline, observability data becomes expensive noise instead of operational evidence. The stronger practice is to decide which identifiers belong in logs, which belong in metrics, and which should remain in a separate security record. Organisations typically encounter the consequences only after dashboards time out, costs spike, or a critical hunt query fails, at which point cardinality becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• High-Cardinality Authorization
• High-Cardinality Resource
• High-cardinality Data
• High-Cardinality Field