Relationship Cardinality

Expanded Definition

Relationship cardinality is the number of related objects attached to a given object in an authorization graph. In NHI systems, that graph often connects workloads, service accounts, secrets, policies, entitlements, environments, and downstream resources, so cardinality directly shapes how much the engine must evaluate before it can return an answer. Higher cardinality usually means more candidate paths, more intermediate checks, and a larger performance footprint during authorization decisions. In practice, the term is most useful when discussing graph-based access models, policy evaluation cost, and load test realism.

Definitions vary across vendors because some teams count only direct edges, while others include transitive relationships, inherited memberships, or policy-derived links. That difference matters when comparing benchmarks or capacity plans. For governance, the important question is not just how many objects exist, but how many can influence a single authorization decision. The NIST Cybersecurity Framework 2.0 is useful as a broader reference point for managing system risk, even though it does not define relationship cardinality as a standalone control concept.

The most common misapplication is treating a low object count as low graph complexity, which occurs when transitive relationships and inherited access are omitted from evaluation.

Examples and Use Cases

Implementing relationship cardinality rigorously often introduces modeling and performance overhead, requiring organisations to weigh graph accuracy against query cost and operational simplicity.

• A service account linked to dozens of cloud roles creates high cardinality because one identity can trigger many entitlement checks during authorization.
• A secret referenced by multiple pipelines, environments, and runtime agents increases the number of objects that must be evaluated when access is requested.
• A policy graph that includes nested groups, inherited permissions, and resource hierarchies can dramatically expand the paths an engine must traverse.
• Load testing an authorization service should reflect real graph density, not just raw request volume, because sparse test data can hide latency spikes.
• In an NHI review, a single API key used across multiple applications may reveal unexpected coupling that raises both blast radius and evaluation cost.

For a broader NHI context on why graph sprawl becomes hard to see at scale, see the Ultimate Guide to NHIs. That guide also explains why hidden access paths and over-privileged identities are such persistent governance problems.

Why It Matters in NHI Security

Relationship cardinality matters because authorization graphs are only as trustworthy as the relationships they encode. When cardinality rises without controls, policy evaluation can become slower, less predictable, and harder to validate under stress. That creates a governance problem as well as a performance problem: overloaded graphs encourage shortcuts, stale edges, and incomplete testing. In NHI environments, those failures often collide with over-privileged service accounts and long-lived credentials, making the blast radius larger than teams expect.

This is especially relevant in organizations that already struggle with visibility. NHIMG reports that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which means graph size is often paired with poor inventory quality and weak entitlement hygiene. The result is not just slower authorization, but weaker confidence that the engine is evaluating the right relationships at all. The Ultimate Guide to NHIs highlights how those conditions compound across the NHI lifecycle. Organisaties typically encounter the cost of cardinality only after an outage, an access review failure, or a breach investigation, at which point the graph becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Who is accountable for third-party access when a vendor relationship ends?
• How should security teams handle third-party NHI access that outlives the vendor relationship?
• What do teams get wrong about RBAC, ABAC, and relationship-based access control?
• When should teams re-evaluate a verification vendor relationship?