Every team that hears the phrase "identity system of record" asks why their existing vendors cannot do it. My IGA vendor says this is on their roadmap. My PAM vendor says the vault is the system of record for privileged accounts. My IdP already knows every user in the company. Why isn't one of them the answer?
They are each the authority in their own category. None of them were designed to hold the record of every identity.
What your IGA knows
Your governance platform knows the applications it has connectors for, in detail. Entitlements, review history, approvals, the lot. Connect 40 of your 300 applications and the inventory describes 40 applications accurately and says nothing at all about the other 260. The report is accurate and complete with respect to its own coverage. Coverage stalls for reasons we have written about separately in Why Pre-Built Connectors Leave Your Identity Coverage Incomplete.
This creates a circular problem. If you want to know what your governance tool is missing, you cannot ask your governance tool, because you would be checking its coverage against its own idea of coverage.
What your PAM platform knows
Your vault knows what is in the vault. It knows every checkout, every rotation, every session against the credentials it manages, and that history is genuinely authoritative. Being authoritative for the contents of the vault is precisely why it cannot tell you about the privileged account that was never vaulted. An unvaulted account has no relationship to the vault at all, so there is nothing for the vault to report. The local administrator on a Unix host, the database account with a static password, the cloud role somebody created for a migration in 2023: none of those exist as far as the vault is concerned.
Those are also the accounts most likely to still be there in a year, and the ones your auditors ask about. Regulatory requirements do not stop at the systems your PAM provider can connect to. Meeting them means starting from a list of accounts, and the vault cannot produce the part of the list it has never seen. We've discussed more on where those accounts hide in How PAM and IGA Platforms Miss Critical Identity Terrain.
What your IdP knows
Your identity provider knows what federates through it. The service account with a static key does not touch the IdP. Neither does the local account on the appliance, or the application that authenticates against its own user table, or the SSH key that has been on twelve hosts since before the current team was hired. Standing access that never passes through the IdP is invisible to the IdP by definition.
The shape all three share
Each tool's record stops exactly where its reach stops. That leaves you with at least three accurate records of three silos of your identity practice and no way to even understand the gaps between them. Two more limits come with that:
- Each tool models the identities it can manage. Anything it cannot manage is not simply missing from its analysis or report. It has nowhere to live in the data model. IGA stores Alice as an employee number and an AD account. The ERP stores her as USER_ID A_THOMPSON. The jump host stores a local user alice. The Claude agent that writes to the same ERP runs as a service principal with no employee number and no human to attach a review to. Those fields have no shared name and no system that treats them as the same identity, so a review can only certify the AD account. The ERP login, the local SSH account, and the agent's principal never enter the campaign. Mapping those fields into one identity is what puts the leftover accounts, including the one an agent is running as, in front of the same reviewer.
- Each tool keeps its own history. IGA's history is certifications and requests. PAM's history is checkouts and rotations. The jump host has no history IGA can read, only a local account that was there the last time the scheduled scan ran. But when identity changes are recorded as they happen, a reviewer can see that the local account appeared after the last campaign, and a PAM owner can see that the same account has been authenticating without ever being vaulted. That context is what lets a person or another tool decide what to do next.
What neutral actually means in practice
A record that can hold all of it has to belong to none of it. The record is not IGA's database, not the vault's, and not the IdP's. It can keep a Unix local account, an ERP user, and an Entra account in the same place because it does not have to force them into one vendor's object model. If the record lived inside IGA, it would only be able to store what IGA already knows how to name.
It collects what the IdP, IGA, PAM, HR, and the systems they cannot reach each asserted about an identity. It sends that picture back so IGA can review accounts it has no connector for, PAM can vault from a complete privileged list, and an analyst can open an alert with the account's history already attached. IGA still decides access. PAM still vaults. The IdP still authenticates. Each one does that job with accounts it could not see on its own. That is why the record has to sit outside any one of those tools.
If your governance platform covers 40 applications and you want to know what is happening in the other 260, schedule a demo.
Frequently asked questions
Can my IGA platform be my identity system of record?
Not for the whole environment. A record inside a tool can only hold what that tool reaches, so a platform connected to 40 of 300 applications produces an accurate inventory of 40 and is silent on 260. You also cannot use it to find its own coverage gaps, because you would be measuring its reach against its own view of what exists.
Isn't the vault the system of record for privileged accounts?
The vault is authoritative for the credentials it manages, and that history is trustworthy. It cannot speak to the privileged account nobody vaulted, because that account has no relationship to the vault. Since unvaulted standing privilege is the specific risk most privileged access programs are trying to eliminate, the record has to come from somewhere with wider reach.
Why can't the identity provider hold everything?
Because a large amount of standing access never passes through it. Local accounts on servers and appliances, service accounts with static keys, SSH keys, and applications with their own user tables all grant access without a federated login. The IdP is accurate about what authenticates through it and structurally blind to the rest.
What does a neutral system of record mean?
That it belongs to no single tool's territory. It collects from the IdP, the governance platform, the vault and HR, feeds all of them back, and never claims authority over access decisions. Neutrality is a requirement rather than a stance, because a record that competed with its sources for authority would stop being trusted by any of them.
Why does identity history have to live outside IGA, PAM and the IdP?
Each tool keeps the history of its own actions: certifications, checkouts, federated logins. A local account appearing after the last campaign never enters those logs. Recording changes as they happen, from every system, is what gives a reviewer or an analyst the context to act.