Identity Record

What an identity record is

An identity record is the durable directory object that gives an organisation a stable, governed representation of a person, service, or system. It is the anchor for lifecycle management, audit, ownership, and policy decisions, while the password, token, certificate, or other authenticator used at login is separate from the record itself.

That separation matters because the record is supposed to persist across password resets, MFA changes, and other credential churn. If a directory object is treated as if it were the credential, governance becomes brittle: the organisation can lose sight of who or what the account actually represents, or confuse recovery actions with identity changes.

Identity record in the directory model

Identity records usually sit in a directory, IAM platform, HR feed, CMDB, or equivalent source of truth. They carry the stable attributes that make governance possible, such as display name, unique identifier, department, status, ownership, and relationships to groups or applications.

In practice, the record is the object other systems reference when they need to answer “who is this?” or “what is this?” even when the login method changes. That makes the identity record a control plane object, not an access proof, and explains why it should be managed with strong naming, uniqueness, and reconciliation rules. For inventory and reconciliation patterns around stable identity objects, see NHI Inventory Reconciliation.

Why identity records differ from credentials

Identity records and credentials serve different functions. The record establishes existence and governance context; the credential establishes authentication at a specific moment. Mixing those concepts creates operational risk, because credentials are expected to rotate, expire, and be replaced, while the identity record should remain stable enough to preserve continuity and auditability.

This distinction becomes especially important when a person leaves, a service is decommissioned, or a system is renamed. The right question is not only whether a login secret changed, but whether the underlying record is still accurate, owned, and needed. In many environments, stale records outlive the systems they represent and become the basis for orphaned access, duplicate entitlements, or broken reporting.

How identity records support governance and lifecycle

Identity records support joiner-mover-leaver workflows, access reviews, entitlement mapping, and evidence collection. They help determine whether an account should exist, who approves it, which groups it belongs to, and when it should be removed or disabled.

Because the record is the durable reference point, it also underpins segregation of duties and traceability. If the record is inaccurate, every downstream control that depends on it becomes less trustworthy. That is why lifecycle events should update the record deliberately, rather than allowing ad hoc changes to accumulate across directories and applications. A broader governance view of identity ownership and operating model design is covered in Identity Security Programme Guide.

Common failure modes and control implications

Identity records fail when they duplicate, drift from the source of truth, lose ownership, or persist after the real-world entity is gone. The result is often overprovisioning, misleading audits, or weak incident response because responders cannot quickly determine which accounts still matter.

Another common failure mode is record fragmentation across identity providers, HR systems, cloud platforms, and application-specific directories. When those systems disagree, the organisation may preserve access that should have been removed, or remove a record that still supports a business process. Guidance on hardening the surrounding identity estate, including privileged and service objects, is reflected in Active Directory and Entra ID Hardening Guide.

Related resources from NHI Mgmt Group

• Why does a single authoritative identity record matter for IAM?
• When should teams require re-verification instead of trusting an existing identity record?
• What breaks when offboarding is not tied to the source identity record?
• What should identity and security teams review after a DNS record change?