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

Why This Matters for Security Teams

An IdP is excellent for federated sign-in, but it is not a complete inventory of identity. Local administrator accounts, application-native users, API keys, service accounts, and secrets embedded in code can all exist outside the IdP’s field of view. That gap matters because the attack path often starts where visibility is weakest, not where governance is strongest. NHI Mgmt Group research shows only 5.7% of organisations have full visibility into their service accounts, and 96% store secrets outside secrets managers in vulnerable locations.

That is why identity governance cannot stop at login events. A system of record for identities has to include creation, ownership, privilege, rotation, and revocation across both human and non-human identities. Otherwise, teams end up mistaking federated authentication logs for complete identity assurance. For broader control mapping, the NIST Cybersecurity Framework 2.0 reinforces the need to manage identity risks as part of ongoing protection and detection, not as a one-time directory exercise. The practical lesson is visible in incidents such as OneLogin API Key Vulnerability, where the exposed secret was not solved by normal IdP governance alone. In practice, many security teams discover their identity blind spots only after an API key, service account, or hard-coded secret has already been used in production.

How It Works in Practice

The safest operating model is to treat the IdP as one authoritative source, but not the only system of record. For federated human identities, the IdP can remain the primary record for authentication state, assurance, and group membership. For non-federated identities, organisations need a broader inventory that captures the identity object itself, where it lives, who owns it, what it can access, how long its credentials last, and when it was last rotated or revoked.

That usually means combining multiple sources into one governance view:

• IdP logs and directory data for federated accounts
• Cloud IAM and application admin stores for local and native accounts
• Secrets managers, CI/CD systems, and code repositories for keys and tokens
• Cloud audit logs for service account usage and privilege drift

The operational goal is not to duplicate every record in the IdP, but to make identity ownership and lifecycle visible across the estate. This is especially important where credentials are created outside normal joiner-mover-leaver workflows. NHIMG’s Ultimate Guide to Non-Human Identities is a useful reference for understanding why lifecycle control, rotation, and offboarding have to extend beyond traditional directory management. Where the evidence shows identity sprawl, as with Code Formatting Tools Credential Leaks, the remediation task is to find every secret and owner, then revoke or replace what the IdP never tracked.

In practice, teams should define the IdP as the source of truth for federated authentication, but use an identity governance or NHI inventory layer as the system of record for all identity types. These controls tend to break down in hybrid environments with legacy apps, shadow IT, and secrets embedded in developer tooling because those identities never enter the IdP lifecycle.

Common Variations and Edge Cases

Tighter identity centralisation often increases operational overhead, requiring organisations to balance visibility against administrative complexity. Current guidance suggests there is no universal standard for treating every identity as an IdP-managed object, because not every identity authenticates through federation. That distinction matters in environments with mainframes, SaaS admin accounts, shared platform credentials, or machine identities that are provisioned by automation rather than by an identity team.

One common edge case is a local account that exists for break-glass or application resilience. Another is a service account owned by a platform team but used by multiple workloads. These identities should still be in the record, but the record may live in a governance platform, CMDB, or secrets inventory rather than the IdP. The question is not where the record sits, but whether it is complete enough to answer who owns it, what it can do, and how to revoke it quickly.

Practitioners should also beware of assuming that SSO equals full visibility. A successful login can hide the larger risk of unmanaged credentials outside the IdP boundary, which is why incidents like Microsoft Entra ID Flaw are so instructive: strong federation does not eliminate the need to track every identity path. The right model is layered record-keeping, with the IdP as a major source, not the entire answer.

Related resources from NHI Mgmt Group

• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations treat AI service sessions like privileged non-human identities?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?