When teams rely only on the identity provider, they can lose sight of entitlements that exist outside its control. That creates an incomplete view of who can access what, especially for third-party systems with their own authentication state. The result is delayed revocation, weaker auditability, and a higher chance that access remains active unnoticed.
Why IdP-Only Access Management Leaves Gaps
Managing access only through the identity provider creates a blind spot the moment a system accepts its own local accounts, tokens, API keys, or delegated OAuth grants. The IdP may show that a user or workload is authenticated, but it does not automatically reveal every entitlement that exists downstream. That matters because auditability, revocation, and ownership all depend on seeing the full access path, not just the primary login point.
NHIMG research highlights how common this visibility gap can be: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. That is exactly the kind of condition where IdP-centric control looks complete on paper while active access still survives elsewhere. In practice, many security teams discover the gap only after a removal request fails to cascade through a connected system.
How the Access Model Breaks Down in Practice
An IdP can centralise authentication, but access decisions are often distributed across applications, SaaS platforms, partner portals, service accounts, and machine-to-machine integrations. Once those systems maintain their own authorization state, the IdP becomes only one control plane among several. If the team uses the IdP as the sole source of truth, it may miss non-expiring refresh tokens, dormant local accounts, cached sessions, or vendor-managed privileges that remain valid after an identity change.
The operational failure is usually not one dramatic misconfiguration. It is an accumulation of small inconsistencies: access granted outside the IdP workflow, revocation delayed because another admin console must be checked, and audit evidence split across systems that do not reconcile cleanly. That can create false confidence during access reviews because the directory looks clean even while the application still permits access.
For environments with third-party integrations, the problem becomes sharper. OAuth consent, SCIM drift, service accounts, and shared administrative models can all create entitlements that are not governed by the IdP alone. The control objective is therefore broader than login centralisation. Teams need a process that can answer who can access what, by which mechanism, and whether that access can be removed everywhere it exists.
- Authentication centralisation does not equal entitlement centralisation.
- Revocation must cover local and delegated access, not only directory-linked access.
- Auditability depends on correlating the IdP with downstream systems that enforce their own permissions.
That is why mature programmes treat the IdP as an important control point, but not as the whole access architecture. The Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both reinforce that lifecycle control, visibility, and revocation have to follow the credential or entitlement, not stop at the directory boundary. These controls tend to break down when downstream systems keep independent authorization state because the IdP cannot enforce removal it cannot see.
Common Variations and Edge Cases
Tighter central control often improves consistency but adds integration overhead, so organisations have to balance governance against the reality of heterogeneous platforms. Some applications support full federation and deprovisioning cleanly; others keep local roles, manual overrides, or vendor-side admin paths that do not map neatly back to the IdP. Current guidance suggests treating those exceptions as design constraints, not as temporary noise.
There is also a meaningful difference between human access and non-human access. Human accounts may be visible in the directory but still rely on app-local groups, while machine identities often depend on secrets, tokens, and service credentials that never appear as ordinary user sessions. If teams assume all access is mediated by the IdP, they can miss exactly the mechanisms that stay active the longest.
For that reason, the edge case to watch is any environment where access can be granted, refreshed, or renewed outside the directory lifecycle. That includes partner integrations, legacy SaaS, privileged admin portals, and automation tooling. The more exceptions a business has, the less credible an IdP-only operating model becomes as an assurance statement.
Risk and Threat Considerations
The material risk is incomplete control over effective access. When downstream systems preserve their own authorization state, revocation can fail to reach all active paths, leaving credentials, tokens, or local entitlements usable after the source identity should have been removed.
Failure mechanism: A recognised control weakness is trust in a single identity source while applications retain independent access state. Attackers and insider threats can abuse stale sessions, delegated grants, or unmanaged service credentials even after the IdP record changes.
Impact: Access remains active longer than intended, audit trails become fragmented, and organisations lose confidence that deprovisioning actually closes exposure across third-party and non-human access paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | IdP-only control misses non-human credentials and tokens outside directory scope |
| NHI-03 — Access Governance | The issue is incomplete visibility into effective NHI entitlements and revocation | |
| NHI-05 — Lifecycle and Offboarding | Delayed revocation is the core failure when access persists beyond identity changes | |
| Recommendation — Inventory and rotate all non-human credentials that remain valid outside the IdP. Map and review every downstream entitlement that the IdP cannot directly remove. Automate offboarding so removal reaches local accounts, grants, and shared credentials. | ||
| CIS Controls v8 | 5 — Account Management | Account control must extend beyond the directory to all active access paths |
| 6 — Access Control Management | Access decisions need enforcement across connected systems, not only the IdP | |
| Recommendation — Maintain an authoritative inventory of accounts and disable all redundant access paths. Enforce least privilege and verify that revocation propagates to each system. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Access control fails when authentication is centralised but authorization is fragmented |
| GV.RM — Risk Management Strategy | IdP-only governance leaves unresolved exposure from unmanaged downstream entitlements | |
| DE.CM — Continuous Monitoring | The gap is a monitoring blind spot across third-party and local access states | |
| Recommendation — Correlate authentication with downstream authorisation to prove effective access state. Treat unmanaged downstream access paths as explicit governance risks and remediation priorities. Monitor downstream systems for orphaned grants, stale sessions, and unmanaged tokens. | ||
Practitioner Guidance
What to prioritise: Inventory every system that can grant or retain access independently of the IdP, then separate “directory-managed” from “locally managed” entitlements. If a platform can authenticate a user, workload, or partner without checking the IdP on every access decision, it needs explicit revocation and audit handling.
What to verify: Confirm that deprovisioning removes access from local roles, tokens, refresh grants, API keys, and vendor consoles, not just the primary directory record. Evidence should show the removal path end to end, because a clean IdP state alone is not proof of access loss.
Decision rule: If the team cannot demonstrate where access is enforced after authentication, treat the environment as partially unmanaged and escalate the gap before relying on any access review or certification.
Practitioner takeaway: The real control objective is not directory cleanliness; it is proving that no downstream system can keep access alive after the source identity has changed.