Subscribe to the Non-Human & AI Identity Journal

What do security teams get wrong about single sign-on protocols?

They often assume authentication protocol choice is the same as access control design. In reality, OIDC and SAML only establish identity and session trust. Organisations still need entitlement governance, monitoring, and revocation controls to prevent authorised sign-in from turning into inappropriate access.

Why This Matters for Security Teams

Single sign-on is often treated as a finish line when it is really only the start of access trust. OIDC and SAML can prove that a user authenticated, but they do not decide whether that user should retain a high-risk entitlement, reach a sensitive workload, or keep access after a role change. That gap is where breaches, privilege creep, and stale sessions persist.

This matters because identity systems are frequently optimised for login success while the attack surface sits in downstream authorisation, token lifetime, and revocation speed. NIST CSF 2.0 is explicit that access control and continuous monitoring are separate security functions, not a single checkbox, and the same lesson appears in NHI research such as Ultimate Guide to NHIs. In practice, the failure is not that SSO was deployed, but that it was mistaken for entitlement governance.

NHIMG research shows the operational cost of that blind spot: The State of Non-Human Identity Security reports that only 1.5 out of 10 organisations are highly confident in securing NHIs. In practice, many security teams discover access drift only after a vendor integration, token leak, or over-permissioned account has already been exploited.

How It Works in Practice

Security teams get better results when they separate authentication, session trust, and authorisation into distinct controls. SSO protocols establish who authenticated and, in some cases, how the session was asserted. They do not automatically enforce least privilege, contextual approval, segregation of duties, or time-bound access. That means the real work happens after the login event.

A practical design usually includes:

  • Central policy decisions for entitlement checks, not just IdP sign-in rules.
  • Short-lived sessions and token lifetimes that match risk, not convenience.
  • Continuous monitoring of login events, privilege changes, and anomalous reuse.
  • Rapid revocation paths for terminated staff, compromised accounts, and risky apps.
  • Periodic access review for SaaS, APIs, and privileged resources that sit behind SSO.

For control design, NIST guidance and the NIST Cybersecurity Framework 2.0 support the idea that identity proofing and access enforcement are not interchangeable. The same principle shows up in NHIMG’s Schneider Electric credentials breach coverage, where credential-based trust did not prevent downstream exposure once access was misused or overextended. The protocol did its job; the governance layer did not.

For practitioners, the most useful question is not “Is SSO enabled?” but “What happens after a valid assertion is accepted?” That includes which entitlements are issued, how long they persist, what gets logged, and how quickly the organisation can cut off access across every relying application. These controls tend to break down in federated environments with many SaaS tenants and unmanaged third-party apps because revocation and entitlement cleanup are slower than token reuse.

Common Variations and Edge Cases

Tighter SSO policy often increases operational overhead, requiring organisations to balance user convenience against revocation speed and auditability. That tradeoff becomes obvious in mixed estates where legacy apps, custom APIs, and cloud services do not all honour the same session or token rules.

There is no universal standard for this yet, but current guidance suggests a few recurring exceptions. Some organisations centralise authentication in one IdP yet leave authorisation inside each application, which creates inconsistent role models and fractured offboarding. Others rely on SSO for workforce identity but ignore service accounts, API keys, and automation tokens that bypass the SSO flow entirely. That is why NHI governance remains essential even when human sign-in is well controlled.

Another common edge case is third-party access. A partner may authenticate through SSO and still retain excessive application scopes, delegated OAuth permissions, or stale refresh tokens long after the business relationship changes. The visibility gap described in The State of Non-Human Identity Security is a reminder that sign-in telemetry alone does not reveal who can still act. Best practice is evolving toward continuous entitlement review, token hygiene, and conditional access policies that can be evaluated at runtime.

In short, SSO reduces password sprawl, but it does not remove the need for access governance. Organisations that treat authentication as the end state usually find out later that the real problem was never login, it was everything that remained open after login succeeded.

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 NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.AC-1 SSO proves identity, but PR.AC-1 governs how access is granted and enforced.
OWASP Non-Human Identity Top 10 NHI-03 Session and token misuse after SSO is a credential lifecycle risk.
NIST AI RMF GOVERN Identity trust decisions need governance, accountability, and monitoring.

Assign owners for federated access, define review cadence, and track revocation performance.