How should organisations govern access through identity providers without overcentralising risk?

Treat the identity provider as the trust broker, not the final authority. Define where authentication ends, where authorization begins, and which downstream applications must enforce their own permissions. Then connect provisioning, deprovisioning, and access reviews so the identity provider reflects current business need rather than historical access.

Why This Matters for Security Teams

Identity providers are often treated as the control plane for enterprise access, but that becomes risky when they also become the single point of failure for every downstream entitlement. The real issue is not centralisation itself, but overcentralisation without clear boundaries: authentication, provisioning, session trust, and application authorization get blurred together. That creates brittle governance, expands blast radius, and makes access reviews look complete even when application-level permissions remain unmanaged.

Current guidance suggests using the identity provider as the trust broker, then forcing each critical application to enforce its own authorization decisions. That is especially important for non-human identities, where access patterns change quickly and excess privilege accumulates silently. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which makes centralized identity without downstream control a dangerous illusion. See the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 for the broader governance framing.

In practice, many security teams discover the overcentralization problem only after a compromised token or stale entitlement has already been used to move laterally through multiple applications.

How It Works in Practice

Sound governance starts by separating concerns. The identity provider should authenticate the principal, issue or broker the token, and publish trusted attributes such as role, device state, or workload identity. It should not be the only place where final permission decisions live. Downstream applications and APIs need to evaluate whether the request is allowed in their own context, because the same identity can be legitimate for one workflow and dangerous for another.

A practical model uses three controls together: provisioning, policy enforcement, and review. Provisioning should be tied to business need and time bounds, not historical membership. Policy enforcement should happen at the point of use, using application-specific rules, scopes, or policy-as-code. Reviews should reconcile what the identity provider thinks is assigned with what applications actually permit. That is especially important for service accounts, API keys, and machine tokens, where standing access tends to linger long after the original use case ends. NHI Management Group’s Top 10 NHI Issues highlights how frequently excess privilege and weak rotation become operational failures.

• Use the identity provider to authenticate and broker trust, not to replace application authorization.
• Issue the minimum claims needed for the task, and keep tokens short-lived where possible.
• Let each sensitive application enforce its own permissions, especially for write, admin, and data-export functions.
• Reconcile identity-provider assignments against application entitlements on a fixed schedule.

External guidance from the OWASP Non-Human Identity Top 10 reinforces the same pattern: central identity is useful, but authorization must remain distributed enough to preserve least privilege. These controls tend to break down when legacy applications only trust coarse SSO claims because they cannot enforce context-aware authorization natively.

Common Variations and Edge Cases

Tighter identity-provider governance often increases operational overhead, requiring organisations to balance simpler administration against stronger application-level control. That tradeoff becomes sharper in mixed environments where SaaS, custom apps, and machine-to-machine workloads do not share the same authorization model. There is no universal standard for this yet, so current guidance suggests applying the principle consistently rather than forcing a single technical pattern everywhere.

One edge case is federated SaaS: the identity provider may handle sign-in, but the SaaS platform still needs its own roles, conditional access logic, and periodic entitlement review. Another is service-to-service access, where workload credentials may be minted centrally but enforced through per-API scopes or local policy. For those environments, the question is not whether to centralize identity, but how to avoid turning the IdP into a de facto super-admin for every application. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives are useful references for aligning lifecycle control with audit expectations.

The practical test is simple: if disabling an account in the identity provider would not actually stop a risky action in the application, the organisation has not separated trust from authorization well enough.

Related resources from NHI Mgmt Group

• How should teams manage access requests through the helpdesk without creating identity risk?
• How should organisations govern SaaS licenses alongside identity access reviews?
• How can organisations reduce identity risk without replacing every legacy system?
• How should organisations govern access when identity state changes daily?