Identity security needed a system of record first, not another detector

At a glance

What this is: The article argues that identity security is missing the foundational recording layer that endpoint, network, and cloud security had before detection matured.

Why it matters: IAM, IGA, PAM, and NHI teams need historical identity recordkeeping because current-state visibility alone cannot support audit evidence, anomaly ranking, or clean offboarding.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Hydden's analysis of why identity security needs a system of record

Context

Identity security is not failing because teams lack more detectors. It is failing because identity data still arrives as disconnected exports, not as a continuous record of what changed, when it changed, and which accounts belong to the same person or service. That is why access reviews, privileged cleanup, and incident reconstruction keep turning into manual evidence-gathering exercises rather than governed workflows.

The problem shows up across human identity, NHI, and privileged access programmes. Current-state visibility can tell you what exists now, but it cannot prove persistence, change history, or ownership across legacy systems, directories, local accounts, and service credentials. For broader NHI governance context, see the Ultimate Guide to NHIs.

Key questions

Q: What breaks when identity teams rely only on current-state visibility?

A: Current-state visibility cannot prove how long access existed, who changed it, or whether a risky state already survived previous reviews. That leaves audit evidence, incident reconstruction, and privileged cleanup dependent on manual exports instead of a durable identity record. The result is slower remediation and weaker accountability across IAM, IGA, and PAM.

Q: Why do identity programmes need historical recordkeeping as well as detection?

A: Detection needs context to rank anomalies, and context comes from history. Without prior state, ownership, and change timing, every identity event looks isolated. A historical record lets teams distinguish a routine change from privilege creep, stale access, or an account that should have been revoked long ago.

Q: What do security teams get wrong about identity visibility in modern environments?

A: They often treat directory completeness as the same thing as identity visibility. In reality, many of the highest-risk access paths are application-native, ephemeral, or inherited from integrations that never pass cleanly through central IAM records.

Q: How should organisations build a usable system of record for identity?

A: They should collect identity changes from the systems that grant access, normalise accounts to a single subject, and preserve every change instead of overwriting the last known state. That gives IAM and PAM teams a durable basis for recertification, cleanup, and incident analysis.

Technical breakdown

Why identity visibility is not a system of record

Identity visibility is a snapshot of current entitlements and attributes. A system of record preserves the timeline: what the identity looked like yesterday, who changed it, which system asserted it, and how long the state persisted before review. That distinction matters because identity risk is often temporal, not just structural. A dormant service account, a lingering admin role, or a revoked user that remains enabled are all time-bound failures that disappear when only the latest state is retained.

Practical implication: identity teams need historical change capture, not just inventory exports.

Why detection breaks without identity history

Detection in identity security depends on ranking anomalies against a meaningful baseline. If you do not know which identities are privileged, how they were provisioned, or what changed last week, every alert looks equally urgent. That creates noise and hides the events that matter, such as privilege expansion, account reactivation, or access that survived multiple reviews. The architectural issue is not simply insufficient telemetry. It is missing identity context across systems.

Practical implication: correlate detection with entitlement history before tuning alert workflows.

Why identity data is harder to normalise than endpoint or cloud data

Endpoint and cloud security benefited from stable collection surfaces, common protocols, and relatively clean identifiers. Identity environments are messier. Mainframes, LDAP directories, local Unix accounts, SaaS tenants, and custom applications all emit different data, and many do not record change events at all. They also lack a shared identifier that says a local admin account, a cloud role, and an HR record belong to the same subject. Without reconciliation, the record remains fragmented.

Practical implication: build identity correlation into the data layer before expecting governance tools to work consistently.

NHI Mgmt Group analysis

The identity market is solving the wrong layer first. Detection, posture, and visibility are useful, but they all sit above the missing base layer: the record of what happened to identity over time. That inversion explains why programs keep buying point tools while still struggling with audit evidence and access cleanup. The practitioner conclusion is simple: treat historical identity recordkeeping as the prerequisite, not the finishing touch.

Current-state visibility cannot answer the questions auditors and responders actually ask. Knowing what exists now does not reveal what existed in March, who changed it, or how long a risky state persisted. Access review evidence, revocation validation, and incident reconstruction all depend on those historical answers. The practitioner conclusion is that any identity control without change history is structurally incomplete.

Identity data fragmentation is the real governance failure mode. When finance, HR, directory services, cloud roles, and local accounts cannot be reconciled to the same subject, ownership becomes ambiguous and remediation stalls. That is why excessive privilege, orphaned accounts, and stale service access recur across programmes. The practitioner conclusion is to unify identity lineage before expecting downstream controls to perform.

Identity blast radius: the record determines how far a bad state can spread before anyone sees it. If persistence, ownership, and change timing are invisible, a single access issue can survive multiple review cycles and multiple tools. The issue is not just that teams miss findings. It is that they cannot rank or contain them fast enough. The practitioner conclusion is to make historical identity context the core control plane for governance.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• Another finding from the same research shows that 71% of NHIs are not rotated within recommended time frames, which helps explain why identity history matters so much.
• For the broader control model, Ultimate Guide to NHIs shows why visibility, lifecycle, and Zero Trust need the same underlying record.

What this signals

Identity programmes will keep underperforming until history becomes part of the control plane. A live inventory is useful, but governance decisions depend on persistence, lineage, and state change. That means IAM and PAM teams should expect more pressure to unify review evidence, access telemetry, and identity ownership into one historical layer.

Recordkeeping will become the differentiator between operational security and administrative noise. Teams that can reconstruct access over time will triage faster, defend audit decisions better, and remove stale privilege with less manual effort. Teams that cannot will keep scaling spreadsheets rather than control.

The practical shift is toward identity observability with memory. Once organisations can preserve access history, they can connect recertification, incident response, and offboarding to the same evidence base, which is where governance finally becomes measurable.

For practitioners

• Establish a historical identity record layer Capture identity changes continuously across directories, SaaS, cloud roles, local accounts, and privileged systems so you can answer what changed and when. Use the record as the source of truth for reviews and investigations, not exported spreadsheets.
• Link accounts to one identity subject Reconcile employee records, service accounts, roles, and local identities into one lineage model so ownership and accountability survive system boundaries. Without subject matching, remediation queues stay fragmented and stale access remains hidden.
• Rank alerts using identity history Feed detection workflows with entitlement history, ownership, and change timestamps so anomalies are scored against context rather than treated as equal. This improves triage for privilege drift, dormant access, and reactivated accounts.
• Use the record to shorten access review cycles Base recertification on the full access timeline, including when rights were granted, modified, and last used, so approvals are evidence-led. That reduces the tendency to rubber-stamp stable-looking but risky access.

Key takeaways

• Identity security still lacks the historical record layer that endpoint, network, and cloud security had before their categories matured.
• Current-state visibility is not enough for audit, incident reconstruction, or privilege cleanup because it cannot explain change over time.
• Practitioners should prioritise identity lineage, change history, and subject reconciliation before expecting downstream governance tools to produce reliable outcomes.

Key terms

• Identity System of Record: The authoritative source that shows what access an identity actually has. For human, machine, or agent identities, the system of record is the place where entitlement state should be reconciled after request fulfilment. Without it, ticket approvals can diverge from real access.
• Identity Visibility: Identity visibility is the ability to see which identities exist, what they can access, and how those access paths relate across systems. In NHI programmes, it means correlating service accounts, tokens, certificates, and agents into one operational view so governance decisions are based on evidence, not assumptions.
• Identity Lineage: Identity lineage is the traceable relationship between a human owner and the non-human identities that person creates, authorises, or depends on. It allows security teams to connect service accounts, API keys, tokens, and AI agents back to accountable ownership for review, audit, and retirement decisions.
• Change History: Change history is the preserved sequence of identity events, including grants, revocations, modifications, and ownership updates. In identity governance, history is what lets teams prove duration, detect drift, and validate remediation. Without it, reviews and investigations rely on exports that may already be stale.

What's in the full article

Hydden's full article covers the operational detail this post intentionally leaves for the source:

• The identity system-of-record architecture the vendor says it is building for historical change capture.
• How identity records are reconciled across directories, SaaS, local accounts, and privileged systems.
• How access reviews, privileged cleanup, and alert context change when every identity state is preserved.
• What problems the vendor believes a record solves that point tools and exports do not.

👉 The full Hydden article explains the record model, identity reconciliation, and how it changes governance workflows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.