Primary Key

Expanded Definition

A primary key is the stable identifier a system uses to distinguish one record from every other record. In NHI and IAM contexts, the key distinction is permanence: a usable primary key should not depend on attributes that can drift, be reassigned, or be shared across entities. That is why email addresses, display names, and similar mutable labels are weak choices for identity systems.

For non-human identities, the primary key often maps to an issuer plus subject pair, or to another immutable identifier asserted by the identity provider. That makes the record traceable across lifecycle events such as rotation, delegation, and offboarding. This aligns with the identity governance emphasis in the NIST Cybersecurity Framework 2.0, where reliable identity data supports access control and auditability. In practice, definitions vary across vendors when platforms conflate an internal database key with an external identity claim, so teams must confirm whether the term refers to storage design or identity governance.

The most common misapplication is treating a mutable operational label as the primary key, which occurs when account records are keyed to email, hostnames, or human-readable aliases that later change.

Examples and Use Cases

Implementing primary keys rigorously often introduces migration overhead, requiring organisations to weigh schema stability against the cost of remapping downstream systems and logs.

• A service account is indexed by an immutable directory identifier rather than the name of the application that uses it.
• An OpenID Connect subject claim, combined with issuer, anchors a workload identity even when the service name, team, or environment label changes.
• An api key record is tracked by an internal surrogate key while the exposed token value remains rotatable and revocable.
• A secrets inventory links each credential to a stable record ID so audit trails remain intact after rotation or reassignment.
• During offboarding, the identity record is removed or disabled without losing historical linkage to prior access events.

NHIMG research on the Ultimate Guide to NHIs shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why record stability matters. The same lifecycle logic is reflected in NIST Cybersecurity Framework 2.0, where trustworthy identity data supports continuous governance and response.

Why It Matters in NHI Security

Primary keys matter because NHI environments are high-churn systems: credentials rotate, workloads scale, and integrations change faster than human identity records usually do. If the key is unstable, teams lose the ability to prove which identity held which permission at a given time. That breaks access reviews, complicates incident response, and weakens least-privilege enforcement.

The operational risk is not theoretical. NHIMG reports that only 5.7% of organisations have full visibility into their service accounts, and 71% of NHIs are not rotated within recommended time frames, which means many environments already struggle to preserve trustworthy identity lineage. A poor primary key design makes those gaps harder to detect because duplicates, stale entries, and renamed entities blend together in logs and inventories. This is also relevant to federated identity models, where the authoritative source must remain consistent across systems and audit boundaries.

Organisations typically encounter the impact only after a compromise, failed audit, or broken automation reveals that the identity record cannot be reliably matched to the activity that occurred, at which point the primary key becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why has identity replaced the network perimeter as the primary security boundary?
• What is the primary security risk of static credentials?
• Why is NHI discovery and inventory the primary goal of NHI security?
• What are the key NHI security metrics every CISO should track?