IdP-level governance is identity governance that only uses data exposed by the identity provider, such as group membership, app assignment, and login timestamps. It is useful for broad review workflows, but it cannot fully describe the permissions that exist inside applications or automation paths.
What IdP-Level Governance Covers
IdP-level governance uses the identity provider as its control plane for review and attestation. That means it can answer questions about who is assigned to which app, what groups they belong to, and when they last authenticated, but it stops at the boundary of the IdP’s own records.
For many organisations, that is still a useful starting point because the IdP is the most consistent place to see joiner-mover-leaver signals, application entitlements exposed through provisioning, and account activity trends. The limitation is structural, not merely operational.
Why It Is Useful for Broad Access Review
IdP-level governance works well when the goal is to confirm broad access patterns across many users or applications. It is efficient for access recertification, dormant-account review, and high-level entitlement checks because the data is centralised and relatively standardised. That makes it practical for recurring governance workflows where completeness across the directory layer matters more than application-specific depth.
In practice, it gives reviewers a common lens for questions like: is this user still assigned to the application, does the assignment still make sense, and has the account been inactive long enough to warrant follow-up? If the answer can be determined from the IdP alone, the workflow is fast and scalable.
Where Its View Ends
The key limitation is that the IdP does not describe the full permission model inside the target application. An app can grant far more through local roles, object-level permissions, workflow permissions, or embedded admin paths than the IdP assignment suggests. The same problem appears with automation, where a visible app assignment may not reveal the actual tool access, API scopes, or runtime rights used after sign-in.
That is why IdP-level governance should be treated as a governance layer, not a complete permission inventory. It can tell you that an identity reached the door, but not always what that identity can do after entering. Where the application or automation path has its own authorization model, that downstream layer must be reviewed separately. Identity Provider and SSO Security Guide is useful background on why IdP controls, federation, sessions, and token handling need to be hardened together.
What Good Governance Needs Beyond the IdP
Effective governance uses IdP data as an input, then validates the application side where permissions are actually enforced. That usually means checking whether app roles, local entitlements, service privileges, and delegated automation rights are aligned with the access the IdP makes visible. Without that second step, review outcomes can look complete while still missing the highest-risk permissions.
In other words, IdP-level governance is strongest when it is paired with application-native visibility and ownership. It is a review mechanism, not a substitute for entitlement truth. Where the security team needs a broader maturity path for identities, NHI Governance Maturity Model provides a useful way to think about governance depth, ownership, and lifecycle coverage. OneLogin API flaw (CVE-2025-59363) and Entra ID actor token flaw (CVE-2025-55241) also show why governance that depends on identity-provider data must assume the IdP itself is a critical security boundary.
Risk and Threat Considerations
IdP-level governance can create a false sense of completeness if organisations mistake directory-visible assignments for actual effective access. The main risk is blind spots: privileged application roles, embedded admin functions, API scopes, and automation rights can remain active even when the IdP record looks acceptable.
Failure mechanism: Reviewers approve or retain access based on the IdP’s directory view, while the application or automation layer retains broader permissions that are not represented in the governance evidence.
Impact: Excess access can persist, toxic combinations of permissions can go unnoticed, and a compromised account can have more operational reach than the governance report suggests.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | IdP-level governance is meant to support least-privilege access review. |
| AC-2 — Account Management | The term centers on reviewing assigned accounts and access relationships. | |
| IA-5 — Authenticator Management | IdP governance depends on the identity layer that manages sign-in and federation material. | |
| Recommendation — Validate effective permissions beyond IdP assignments before recertifying access. Reconcile IdP assignments with application accounts and remove unnecessary access. Review federation and authenticator handling that underpins IdP access decisions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | IdP governance is an access-control process for reviewing and approving access. |
| A.5.18 — Access rights | The term concerns how access rights are reviewed and maintained over time. | |
| Recommendation — Define review rules that verify access at the point where permissions are actually enforced. Recertify access rights using both IdP evidence and application-level entitlement checks. | ||
Practitioner Guidance
Why practitioners should care: Treat IdP-level governance as a useful control for breadth, not as proof of least privilege. It is best for finding obvious assignment drift, stale accounts, and broad exposure patterns, but it should not be the final word on who can do what inside the application.
Governance implication: Define which applications require a second-layer entitlement review, especially where local roles, API scopes, or automation rights materially exceed what the IdP exposes. The reviewer should know when the IdP is sufficient and when the application owner must attest to the deeper permission model.