They often treat SAML as the whole SSO solution rather than one protocol that supports it. That leads to over-specific architecture decisions and weak comparisons with OIDC or passwordless options. Teams should start from the application and assurance requirements, then decide whether SAML is actually the right fit.
Why This Matters for Security Teams
SAML is often misread as a complete enterprise identity strategy when it is really one federation protocol with a narrow job: asserting identity between an identity provider and a relying party. That misunderstanding leads teams to overbuild around SAML assumptions, underinvest in assurance, and compare it poorly against OIDC or passwordless options. For identity architecture, the right question is not which protocol is “best” in the abstract, but which one fits the application, trust boundary, and risk model.
This matters because protocol choice shapes session lifetimes, assurance signals, user experience, and the operational burden on IAM teams. NIST’s NIST Cybersecurity Framework 2.0 emphasizes governance and risk-based control selection, which is exactly where SAML conversations often drift off course. NHIMG research also shows how identity mistakes compound elsewhere in the stack, including the Ultimate Guide to NHIs, where weak identity design is linked to excessive privilege and poor lifecycle control.
In practice, many security teams discover SAML limitations only after application onboarding, MFA exceptions, or federation failures have already forced an awkward redesign rather than through intentional architecture review.
How It Works in Practice
SAML remains common in enterprise SSO because it works well for browser-based access to legacy SaaS and internal applications that expect signed assertions and centralized authentication. The mistake is assuming that “supporting SAML” means an identity platform is inherently modern or secure. In reality, the enterprise design must still answer who authenticates, what assurance is required, how sessions are renewed, and whether the application can consume richer context than a simple federated assertion.
Teams usually get better results when they evaluate SAML alongside application constraints rather than as a default. For example, if a service needs native mobile support, API access, or shorter-lived tokens, OIDC may be the better fit. If the application only needs federated browser login, SAML may be perfectly adequate. Current guidance suggests treating protocol selection as one control layer inside a broader identity architecture, not as the architecture itself.
- Define the application’s access pattern first: browser, API, mobile, partner federation, or admin access.
- Map assurance requirements next: MFA, device posture, step-up authentication, or phishing-resistant factors.
- Choose the protocol that matches those requirements, rather than forcing every app into a SAML pattern.
- Validate whether the IdP, the app, and the session model all support the same logout, renewal, and revocation expectations.
This aligns with NHIMG guidance in the Top 10 NHI Issues, which shows how identity decisions fail when teams focus on a single mechanism instead of lifecycle and governance. It also helps to study real breach patterns in the 52 NHI Breaches Analysis, where stale trust and weak identity boundaries repeatedly surface as root causes. These controls tend to break down in mixed estates with older SaaS apps, custom SAML integrations, and inconsistent session governance because the weakest relying party dictates the design.
Common Variations and Edge Cases
Tighter identity standardization often increases migration cost and operational overhead, so organisations have to balance modernization against app compatibility and delivery timelines. That tradeoff is where SAML misunderstandings become expensive: teams either preserve SAML everywhere for convenience or rush to replace it without accounting for application behaviour and user impact.
One common edge case is the “SAML-only” legacy application that cannot consume OIDC tokens or modern conditional access signals. In those environments, SAML may remain the right choice, but the surrounding controls matter more than the protocol itself. Another case is hybrid identity, where different apps legitimately need different protocols. Best practice is evolving toward protocol-by-use-case, not protocol-by-policy.
Teams should also separate authentication from authorization. A successful SAML assertion does not guarantee least privilege, strong session control, or correct downstream authorization decisions. Where the business expects stronger assurance, step-up authentication, device-bound access, and privileged session controls may be needed regardless of protocol. NHIMG’s research on Why NHI Security Matters Now reinforces the broader point: identity design fails when teams assume one layer solves the whole problem.
There is no universal standard for when SAML should be retired, but there is broad consensus that it should not be treated as the identity strategy itself.
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 | Identity assertions must match access context and assurance needs. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Misapplied federation creates weak identity boundaries and overtrust. |
| NIST AI RMF | Risk-based identity decisions fit the AI RMF's governance-first approach. |
Align protocol choice to access requirements and verify federation trust before granting access.
