SSO solves federation at the login screen, but it does not govern app discovery, unused licenses, dormant accounts, or unfederated tools. If an application sits outside the federated boundary, revocation through the IdP does not guarantee the account disappears everywhere it exists.
Why federation is only one slice of the access problem
SSO reduces password sprawl and centralises authentication, but it does not create a complete inventory of every place a user can still reach data. If an app is not integrated with the identity provider, or if the app keeps its own local account store, access can persist even after the main login path is controlled.
That is why the access-trust gap is broader than “can the user sign in?”. It also includes whether you can discover every app, map who actually has access, and remove access everywhere when role changes, employment ends, or a shadow tool appears outside the federated boundary.
A federated login flow is still useful, but it is only a control on the front door. OpenID Connect Core 1.0 shows the authentication layer SSO standardises; the remaining access problem lives in lifecycle and application governance.
Where the gap comes from in real environments
The gap usually appears when identity governance and application reality diverge. One team assumes the IdP is the system of record, while another team has added local admin users, service logins, vendor-managed access, or legacy accounts that never became part of the federation design.
That mismatch is common in SaaS estates, mergers, older line-of-business systems, and third-party integrations. A user can be deprovisioned centrally, yet still retain access through a local app account, a shared admin credential, or a token-based integration that was never tied back to the IdP.
SSO also says little about dormant accounts and unused licenses. Those are governance signals, not authentication signals, which is why Workforce Identity Security Guide is useful for the broader joiner-mover-leaver and federation picture, not just the login event.
When teams are selecting or hardening the control plane, Identity Provider and SSO Security Guide helps separate federation hardening from the separate problem of application coverage and trust monitoring.
What closes the gap after SSO is deployed
The practical fix is to treat SSO as one control in a larger access model. You still need application inventory, access recertification, automated deprovisioning, exception handling for unfederated apps, and explicit ownership for every system that sits outside the IdP boundary.
Revocation should be tested end to end. If a user leaves, the expected outcome is not just “the IdP account is disabled”, but “the account, session, token, license, and local app access are removed or blocked wherever that identity was recognised.”
That is also where integration design matters. IAM and Identity Provider Buyer's Guide is relevant because the capability question is not only “does it support SSO?”, but “does it support lifecycle, provisioning, and access governance across the app estate?”
For control alignment, RFC 6749: The OAuth 2.0 Authorization Framework is a useful reminder that delegated access and federated login are different problems, and they need different controls.
Risk and Threat Considerations
SSO can create a false sense of completeness if organisations equate successful federation with complete access removal. The main exposure is stale or hidden access, which can let former employees, contractors, or compromised third-party integrations continue reaching data after the central login has been disabled.
Failure mechanism: The federated boundary covers authentication, but not every application account, token, licence seat, or local admin path. When revocation is not propagated across all access paths, dormant or shadow access survives outside the IdP lifecycle.
Impact: Organisations can miss unauthorised access, fail audits, and delay containment after offboarding or compromise. The longer the gap persists, the more likely it becomes that unused access is abused, inherited by another user, or forgotten until an incident forces discovery.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | SSO centralises user authentication at the login layer. |
| AC-2 — Account Management | The gap is about accounts that remain active outside federated login. | |
| AC-6 — Least Privilege | Unused and over-broad access survives when SSO is mistaken for governance. | |
| Recommendation — Enforce centralized user authentication through the IdP and validate session handoff controls. Inventory, provision, disable, and review every application account across the full lifecycle. Restrict app permissions to the minimum needed and remove standing excess access. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Directly addresses access review, revocation, and account hygiene beyond SSO. |
| CIS-5 — Account Management | SSO does not replace lifecycle control for dormant or orphaned accounts. | |
| Recommendation — Maintain authoritative access inventories and revoke accounts that no longer have a business need. Automate account provisioning and deprovisioning across all applications, including exceptions. | ||
Practitioner Guidance
What to prioritise: Build an application-by-application view of whether access is federated, locally managed, or partially integrated. SSO coverage reports are not enough unless they are paired with authoritative app ownership and deprovisioning evidence.
What to verify: Test a real offboarding path for at least one federated app and one non-federated app. You want proof that the central disable action, local account removal, token revocation, and licence reclamation all complete, not just the IdP step.
Common mistake: Treating SSO rollout as an identity programme endpoint. In practice, SSO is a login simplifier, while the access-trust gap is closed by lifecycle control, inventory discipline, and exception handling for systems that federation never reached.
Practitioner takeaway: If you cannot answer where access still exists after the IdP says “no”, then SSO has improved authentication but has not solved access trust.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org