What do organisations get wrong when they treat SAML and SSO as the same control?

Why This Matters for Security Teams

SAML and SSO are often discussed in the same breath, but they solve different problems and create different control points. SSO is about user convenience and session reuse; SAML is about federation and transmitting identity assertions between an identity provider and a service provider. When teams collapse those concepts, they tend to stop at login success and overlook the harder questions of trust validation, assertion scope, session lifetime, and downstream authorization.

That mistake matters because identity compromise rarely stops at the first application. Once a session is accepted too broadly, attackers can reuse trust across multiple systems, including workflows that depend on the same sign-in chain. NHIMG research on Ultimate Guide to NHIs — Standards shows why identity controls need clear lifecycle and trust boundaries, especially when credentials and assertions outlive the intent that created them. The risk is not the protocol itself, but the assumption that a login experience equals a complete security control. In practice, many security teams discover this only after a federated session has already been reused in ways the original design never anticipated.

How It Works in Practice

Practitioners should separate three layers: authentication, federation, and access enforcement. SSO improves the user experience by reducing repeated logins. SAML carries signed assertions that a relying party uses to trust that authentication happened elsewhere. Neither one replaces authorization, and neither one should be treated as the final checkpoint for sensitive access.

A sound design usually includes:

• Strict issuer and audience validation for every SAML assertion.
• Short session lifetimes that limit how long a successful login remains useful.
• Explicit authorization checks in the application, not just at the identity provider.
• Step-up authentication for high-risk actions, even when SSO is already active.
• Logging that ties assertion use to the target application and the specific session.

This distinction is especially important in environments with service-to-service trust, partner federation, or delegated admin access. The Hugging Face Spaces breach is a useful reminder that identity assumptions can fail when secrets, sessions, or trust relationships are broader than intended. External guidance from the FATF Recommendations — AML and KYC Framework is not an SSO standard, but it reinforces the same operational lesson: identity assurance is only meaningful when it is bound to the right subject, purpose, and enforcement point. These controls tend to break down when legacy applications accept assertions without rechecking audience, expiry, or privilege context because the federation layer has been mistaken for the entire control boundary.

Common Variations and Edge Cases

Tighter federation controls often increase operational overhead, requiring organisations to balance convenience against assurance. That tradeoff becomes more visible in mixed estates where some applications support modern federation and others still rely on local sessions, header-based trust, or brittle password fallback.

There is no universal standard for every SAML deployment pattern, so current guidance suggests treating the protocol as one component in a broader access architecture. Common edge cases include:

• SP-initiated versus IdP-initiated flows, which can create different replay and audience risks.
• Multi-tenant applications where a single assertion may be valid for the wrong tenant if the mapping is weak.
• Long-lived browser sessions that survive beyond the useful life of the original assertion.
• Break-glass accounts that bypass SSO entirely and become invisible in routine review.

For governance programs, the right question is not whether SAML "is" SSO, but where each control starts and stops. The Ultimate Guide to NHIs — Standards is useful here because it frames identity as a lifecycle problem, not a single login event. That framing also aligns with modern federation guidance: trust must be revalidated at use time, especially when session reuse crosses business units, partners, or privileged workflows.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they treat human, machine, and AI identities the same?
• What do organisations get wrong when they treat compliance frameworks as the same thing?
• What do identity teams get wrong when they treat SOC and SOX as the same control problem?
• What do organisations get wrong when they treat passwordless as a single control?