Notifications
Clear all
Topic starter
08/06/2026 4:55 pm
TL;DR: SAML is an open standard for exchanging authentication data, while SSO is the access experience it enables across applications and services; StrongDM’s guide explains how the two work together, how SAML assertions and trust relationships operate, and where OIDC or Kerberos may fit instead. SSO reduces password fatigue, but it also concentrates identity governance in the IdP and session controls.
NHIMG editorial — based on content published by StrongDM: SAML vs. SSO: What's the Difference and How They Work Together
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
Questions worth separating out
Q: How should security teams choose between SAML and OIDC for enterprise access?
A: Use SAML for browser-based enterprise federation where signed assertions and mature IdP trust are the priority.
Q: What breaks when SSO is treated as a substitute for access governance?
A: Access becomes easier to authenticate but harder to govern.
Q: How do identity teams know whether SAML federation is being trusted too broadly?
A: Look for service providers that accept assertions without strong request validation, weak certificate handling, or unusually long sessions.
Practitioner guidance
- Separate protocol selection from governance design Document which applications use SAML, OIDC, Kerberos, or native credentials, then define the assurance and lifecycle controls that apply to each path.
- Harden assertion trust checks Enforce certificate validation, signed assertions, audience restrictions, and short session durations for every SAML relying party.
- Align SSO with provisioning and de-provisioning Tie IdP access to joiner-mover-leaver workflows so access does not outlive the user relationship.
What's in the full article
StrongDM's full article covers the implementation detail this post intentionally leaves for the source:
- Step-by-step SAML flow diagrams for SP-initiated and IdP-initiated access
- Protocol comparison guidance across SAML, OIDC, OAuth, and Kerberos
- Implementation checks for certificate handling, session timeouts, and user provisioning
- Practical examples for web applications, enterprises, and cross-domain access
👉 Read StrongDM's guide to how SAML and SSO work together →
SAML vs. SSO in modern IAM: what teams get wrong?
Explore further
08/06/2026 6:48 pm
SAML is an identity transport layer, not an access governance model. The protocol moves signed identity claims between trusted parties, but it does not decide entitlement design, lifecycle offboarding, or privileged scope. That distinction matters because many organisations treat federation success as if it were governance success. It is not. Practitioners should separate authentication plumbing from access governance if they want reliable control over who or what can act in the environment.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
A question worth separating out:
Q: Who is responsible when SAML-based access goes wrong?
A: The service provider and identity provider both carry responsibility, but the accountability model must be explicit before federation goes live. Security, IAM, and application owners should agree on who manages trust metadata, who revokes access, and who investigates assertion failures. Without that clarity, federation problems become cross-team blind spots.
👉 Read our full editorial: SAML and SSO together: what identity teams need to know
