Identity system of record fails when coverage stops at tool boundaries

At a glance

What this is: This is an analysis of why an identity system of record cannot live inside IGA, PAM, or an IdP, and why each tool only knows the identities it already reaches.

Why it matters: It matters because IAM, PAM, and NHI programmes cannot govern what they cannot see, and incomplete coverage leaves standing privilege and unmanaged identities outside review, vaulting, and authentication controls.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Hydden's analysis of why no single identity system can hold the full record

Context

An identity system of record is the authoritative place to understand what identities exist, where they live, and how they are connected across systems. The problem is not that IGA, PAM, or an IdP lack useful data. The problem is that each one only knows the identities inside its own control plane, which makes the broader environment look complete when it is not.

That gap matters most for non-human identity governance. Service accounts, local accounts, static keys, and application-specific credentials often sit outside the reach of any single tool, so reviews and vaulting only cover part of the actual estate. NHIMG's Ultimate Guide to NHIs describes how visibility, rotation, and offboarding break down when coverage depends on one vendor model instead of the full identity landscape.

The article's core claim is that neutrality is architectural, not rhetorical. A system of record that sits inside one product inevitably inherits that product's blind spots, which is why identity lifecycle and access governance must be anchored in a cross-system record rather than a single source of truth claim.

Key questions

Q: How should security teams build a single identity system of record across IAM, IGA, PAM, and cloud accounts?

A: Security teams should centralise identity data into one normalized record while keeping each source authoritative for its own domain. That record should combine accounts, users, groups, entitlements, and activity across human, machine, and agent identities. The goal is not to replace existing tools, but to make cross-domain questions and historical analysis possible from one trusted view.

Q: Why do existing IGA and PAM platforms miss parts of the identity estate?

A: Because both tools are authoritative only for the identities they already manage. If an account is never vaulted, never connected, or never modeled in the product, it has no place in that platform's record and therefore no visibility in its reports.

Q: What breaks when service accounts and local accounts sit outside the system of record?

A: Certification, offboarding, and audit workflows lose the ability to see those identities at all. That creates a false sense of completeness, while standing access, stale credentials, and orphaned accounts continue operating outside normal lifecycle controls.

Q: Should organisations use the IdP as the system of record for all identities?

A: No. The IdP is a strong record for federated authentication, but it cannot see local accounts, application-native credentials, or static keys that never pass through it. A complete record must include those non-federated identities and their history.

Technical breakdown

Why tool-bound identity records are inherently partial

An IGA platform only models applications it can connect to, and a PAM vault only models credentials it actually stores. That means the record is authoritative inside a boundary but incomplete outside it. In identity governance terms, the model is recursive: the tool can validate what it sees, but it cannot discover what it does not model. This is why coverage gaps persist even when each platform is technically correct about its own data. The failure is not corruption. It is scope limitation.

Practical implication: treat connector coverage and vaulted coverage as audit inputs, not as proof of complete identity visibility.

Standing access that never touches the IdP

An identity provider is authoritative for federated authentication, not for every access path. Local accounts, service accounts with static keys, SSH keys, and application-native credentials can all grant access without passing through the IdP. That means the IdP may have perfect login history while remaining blind to standing access elsewhere. For NHI governance, this is the crucial distinction between authenticated access and governed access. One is a login event. The other is an inventory and lifecycle problem.

Practical implication: build separate discovery for non-federated accounts and keys instead of assuming the IdP inventory is the full identity estate.

Why identity history must be external to any single control plane

IGA history, PAM history, and IdP history are each useful, but each records only the actions that occurred within that tool. A local account that appears between certification cycles, or a service principal that never enters PAM, will not be visible in those histories unless something outside the tool correlates events across systems. A neutral record solves for that by preserving identity state and change history across sources. That makes it possible to reason about lifecycle, ownership, and accountability without forcing every identity type into one vendor's object model.

Practical implication: correlate identity events across HR, IGA, PAM, and infrastructure logs before you rely on recertification or offboarding outcomes.

Threat narrative

Attacker objective: The objective is to exploit blind spots in identity coverage so unmanaged access persists outside review, vaulting, and authentication controls.

1. entry: The article describes identity exposure as a coverage failure, where service accounts, local accounts, and static keys exist outside the systems that claim to govern them.
2. escalation: Once an identity is outside the model, it can retain standing privilege, evade review cycles, and remain unvaulted or unobserved for long periods.
3. impact: The result is incomplete governance, with auditors, reviewers, and access owners acting on a partial identity inventory rather than the true estate.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity records fail when they are bound to the tool that holds them. A record inside IGA, PAM, or an IdP can be authoritative only for the identities that tool already sees. That means completeness is a property of coverage, not of confidence, and confidence is exactly where many programmes overreach. The implication is that identity governance needs a neutral data plane if it is to function across human, NHI, and autonomous estates.

Standing privilege is often invisible, not merely unmanaged. The article is right to separate vaulted privilege from privileged access that never enters the vault. That distinction matters because the control failure is not limited to rotation or checkout cadence. It is the assumption that privileged access can be governed after discovery when the discovery layer itself is incomplete. Practitioners must stop treating vault history as a whole-of-estate control signal.

Neutrality is a governance requirement, not a product position. A system of record that serves IGA, PAM, IdP, and HR without competing with them is the only model that can preserve cross-domain identity history. This is consistent with the broader NHI governance pattern described in NHIMG's Ultimate Guide to NHIs, where visibility and lifecycle are inseparable. The practical conclusion is that governance must begin with a shared identity ledger, not with another disconnected inventory.

Top 10 NHI Issues: identity sprawl is not just a scale problem, it is a record-keeping problem. When each system stores only its own view of the estate, the enterprise ends up with several accurate partial truths and no authoritative whole. That is the exact environment where offboarding gaps, stale access, and audit exceptions persist.

Cross-system correlation is the missing control plane. The article points to the real requirement: a place to reconcile identity state across applications, vaults, federated systems, and manual accounts. That is what makes lifecycle governance workable across service accounts, human accounts, and AI agents. Without correlation, every certification cycle is just a replay of the same incomplete picture.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Only 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• That visibility gap is why lifecycle controls must be anchored in a neutral identity record, not in whichever platform happens to own the highest-profile workflow.

What this signals

A neutral identity ledger is becoming a practical requirement for programmes that need to govern human, NHI, and machine access together. The more identity state is split across IGA, PAM, and IdP boundaries, the more likely it is that reviews certify only what the tool can see rather than what the enterprise actually runs. See Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs and NIST Cybersecurity Framework 2.0.

Coverage-bound identity control: if a platform cannot inventory an identity, it cannot govern its lifecycle. That is the operational test teams should apply to service accounts, application credentials, and any emerging agent identities before they are folded into recertification or offboarding workflows.

The forward signal is that IAM leaders will need a shared reconciliation layer more than another isolated control point. The governance conversation is moving from 'which vendor owns the record' to 'how do we preserve cross-system identity history well enough to make decisions with confidence'.

For practitioners

• Build a cross-system identity ledger Collect identity state from IGA, PAM, IdP, HR, and unmanaged infrastructure into one neutral record that can represent accounts the source tools do not share. Use it to reconcile local users, service accounts, application principals, and vaulted credentials.
• Measure coverage against the full identity estate Compare what each control plane knows with what actually exists in servers, cloud services, applications, and third-party integrations. Treat any gap between discovered identities and governed identities as a priority remediation list, not a reporting nuance.
• Separate authentication truth from governance truth Use the IdP for federated login evidence, PAM for credential custody, and IGA for access certification, but do not treat any one of them as complete inventory. Require correlation before offboarding, recertification, or audit attestation.
• Extend lifecycle review to non-federated identities Include local accounts, static keys, application-native logins, and service principals in the same review cadence as human accounts. If a credential never touches the IdP or vault, it still needs ownership, expiration, and revocation logic.

Key takeaways

• Identity systems of record break down when they are limited to the tool that owns them, because every product is only authoritative within its own boundary.
• Service accounts, local accounts, and static credentials are the most dangerous blind spots because they can remain outside review, vaulting, and authentication visibility.
• Practitioners need a neutral cross-system identity ledger if they want lifecycle governance, auditability, and offboarding to work across the full estate.

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.
• Neutral Identity Ledger: A cross-system record that collects identity facts from multiple sources without owning access decisions itself. It preserves state, ownership, and history so governance teams can reason about the full identity estate instead of one product's partial model.
• Plan Boundary: The point at which an agent changes method, scope, target, or impact class, such as moving from read-only analysis to a write or delete action. Governance should treat this boundary as a mandatory re-approval checkpoint.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.

What's in the full article

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

• How Hydden models a neutral identity record across IGA, PAM, IdP, and HR systems
• Examples of how different identity sources contribute partial but non-overlapping history
• Why a cross-system record can surface local accounts, service principals, and unvaulted privilege
• The practical implications for teams trying to reconcile identity ownership before audit or recertification

👉 The full Hydden post explains how identity records diverge across IGA, PAM, and IdP boundaries.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.