SSO only governs the identities and apps tied to the federation path. Risk remains when users authenticate through alternate flows, legacy accounts, external contractors, unmanaged devices, or AI agents that never use browser-based login. Those paths can bypass central policy, hide from audits, and retain access long after the original trust assumptions no longer hold.
Why This Matters for Security Teams
SaaS risk does not disappear when SSO is enabled because SSO only standardises one authentication path, not the full identity surface. Alternate logins, legacy local accounts, contractor access, device-bypassed sessions, and non-human identities can still reach the same data and workflows without passing through the same policy checks. That creates a gap between “centralised sign-in” and actual control over who or what is active.
Current guidance from NIST Cybersecurity Framework 2.0 still points teams toward continuous identity governance, not one-time federation setup. NHIMG research shows why this matters in practice: in the Ultimate Guide to NHIs, only 5.7% of organisations reported full visibility into their service accounts, which means the blind spot is often larger than the SSO estate itself.
In practice, many security teams discover identity risk only after an audit, breach, or account review reveals access that never touched the SSO control plane.
How It Works in Practice
SSO reduces password sprawl, but it does not eliminate identity fragmentation. In a typical SaaS estate, the federation path covers browser-based users, while separate paths continue to exist for API tokens, service accounts, SCIM sync accounts, mobile app sessions, shared departmental logins, and emergency local admin access. Each of those paths may have different lifecycle rules, logging depth, and offboarding triggers. If those identities are not tied back to a single inventory, the organisation may have “single sign-on” without single source of truth.
That is why SaaS governance has to extend beyond authentication into lifecycle and privilege management. The practical control stack usually includes:
- Inventorying all human and non-human identities, not just SSO-linked users.
- Separating local SaaS accounts from federated accounts and reviewing both.
- Rotating secrets and API keys on a defined schedule, then revoking stale credentials.
- Using conditional access and device posture checks so SSO sessions do not become blanket trust.
- Mapping contractor, partner, and automation accounts to owners, purpose, and expiry dates.
For SaaS environments with machine access, the issue is often not login but token persistence. The 52 NHI Breaches Analysis and the Snowflake breach both illustrate how stolen or overextended credentials can bypass user-centric controls entirely. NIST’s SP 800-53 Rev. 5 Security and Privacy Controls remains relevant here because it requires access control, auditability, and account management across the full identity lifecycle.
These controls tend to break down when SaaS applications allow shadow accounts, direct-token API access, or federated and non-federated identities to coexist without a shared governance model.
Common Variations and Edge Cases
Tighter identity control often increases operational overhead, so organisations have to balance stronger governance against application compatibility and admin effort. Some SaaS platforms support clean federation and deprovisioning, while others retain local break-glass users, service accounts, or vendor-managed access that cannot be fully centralised. Best practice is evolving, but there is no universal standard for how much residual non-SSO access is acceptable.
Two edge cases matter most. First, external contractors and partners may authenticate through their own identity systems, which means the SaaS tenant sees only a federated assertion, not the wider trust context. Second, automation and AI agents often bypass browser SSO entirely and authenticate with tokens or workload credentials, so they must be governed as identities in their own right. That is where poor visibility becomes dangerous: if the account cannot be traced to an owner, purpose, and expiry, it will outlive the job it was created for.
NHIMG data in the Top 10 NHI Issues shows that excessive privileges and stale credentials remain common, even in organisations that believe SSO has solved the identity problem. In those environments, the real failure is not authentication design, but incomplete lifecycle governance across all access paths.
Related resources from NHI Mgmt Group
- Why do cloud ERP environments still create identity and access risk even when workflow automation is in place?
- Why do shadow IT apps create identity risk even when users still have valid SSO access?
- Why do unmanaged SaaS apps create access risk even when SSO is in place?
- Why do standing privileges and stale access create hidden identity risk even when authentication looks strong?
