Security teams should treat SAML 2.0 as the default unless they have a very specific legacy constraint. It improves message signing, encryption, metadata exchange, session handling, and logout support. SAML 1.1 can still work for basic SSO, but its limited bindings, weaker standardization, and thinner attribute model make it harder to operate securely at enterprise scale.
Why the SAML Version Decision Matters
For a security team, this is not just a compatibility question. SAML version choice affects how assertions are signed, how metadata is exchanged and trusted, how session state is handled, and how cleanly single sign-on and logout behave across providers. If you continue supporting SAML 1.1, the real issue is whether that legacy dependency is constrained enough to justify the operational and security trade-offs.
Security teams should separate “still works” from “still supportable.” A platform can authenticate successfully on SAML 1.1 and still create avoidable friction around federation hardening, partner onboarding, and secure lifecycle management. SAML 2.0 is the better baseline because it gives you a more complete federation model rather than a narrower SSO path.
One useful way to evaluate the decision is to ask whether the older integration is a true business dependency or merely an inherited implementation. If the only reason to keep SAML 1.1 is that no one has prioritized migration, that is usually a maintenance problem, not a security exception.
What SAML 2.0 Gives You That SAML 1.1 Does Not
SAML 2.0 is materially stronger for enterprise federation because it standardizes the parts operators actually rely on at scale. That includes richer bindings and profiles, better metadata handling, clearer trust relationships between identity provider and service provider, and more consistent support for signed and encrypted assertions. Those features make it easier to operate SSO with fewer custom exceptions.
The practical advantage is not only cryptographic. Better standardization reduces integration drift, which matters when you have many applications, multiple identity providers, or third-party partners. With SAML 2.0, teams can usually express the intended trust and session behaviour more cleanly, which lowers the chance that each application ends up with a one-off security interpretation.
Logout and session handling also matter. In real deployments, partial sign-out and stale sessions create user confusion and security blind spots. SAML 2.0 does not eliminate those problems, but it gives teams a better-defined model to work with, especially when combined with stronger session governance on the application side. For teams modernizing federation, the Workforce Identity Security Guide is a useful companion for thinking about SSO, federation, and session theft together.
When a SAML 1.1 Exception Is Defensible
Keeping SAML 1.1 is defensible only when the legacy constraint is concrete and bounded, such as a vendor, platform, or internal application that cannot be upgraded without disproportionate disruption. Even then, the exception should be narrow, documented, and time-limited rather than treated as a standing architecture choice.
The key question is whether the older protocol sits on a controlled edge or in a broadly reused enterprise pathway. A single isolated application with limited data exposure is a different decision from a federation pattern that spans many users, partners, or sensitive systems. The broader the blast radius, the weaker the case for preserving the older standard.
If you do keep it temporarily, look for compensating controls that reduce the operational burden of the weaker standard. That usually means tighter application scoping, stronger surrounding authentication policy, better monitoring of unusual sign-in behaviour, and a migration plan that is owned like any other security debt. The OpenID Connect Core 1.0 specification is not a SAML replacement by itself, but it is a useful reference point when teams are evaluating whether a modern federation path is available alongside legacy SSO.
Risk and Threat Considerations
The main risk of staying on SAML 1.1 is not that every deployment is immediately unsafe, but that older federation patterns are harder to standardize, monitor, and harden consistently. That creates room for weak signing assumptions, brittle integrations, and session handling gaps that become more visible as the environment scales.
Failure mechanism: Limited protocol features and inconsistent implementation behaviour can leave teams with fragmented trust configuration, weaker operational visibility, and more custom exceptions around assertion handling, logout, and attribute exchange.
Impact: The result is higher exposure to misconfiguration, harder incident response, and a larger chance that one legacy integration undermines the security posture of the broader federation estate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | SAML version choice affects workforce federation and user authentication assurance. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | SAML is often used for partner and external user federation, not just employees. | |
| IA-5 — Authenticator Management | The question turns on how credentials, assertions, and session trust are managed over time. | |
| Recommendation — Use IA-2 to require stronger federated authentication for workforce access. Apply IA-8 to govern external-user federation and trust requirements. Use IA-5 to enforce stronger lifecycle and handling rules for federation credentials and assertions. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Modern federation alternatives are often evaluated alongside legacy SAML choices. |
| Recommendation — Compare the legacy SAML path against modern federation requirements before preserving it. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Federation version decisions directly affect identity governance and trust management. |
| A.8.5 — Secure authentication | SAML version selection changes the strength and standardization of authentication flows. | |
| Recommendation — Document identity trust rules and review legacy federation exceptions under identity management controls. Require secure authentication controls for all federation paths, including legacy ones. | ||
Practitioner Guidance
What to prioritize: Treat SAML 2.0 as the default unless the legacy application has a documented, bounded dependency that cannot be removed in the current cycle. The decision should be owned by identity and application security together, because the risk is architectural as much as it is technical.
What to verify: Confirm whether the SAML 1.1 dependency is isolated or reused across multiple applications, whether signed and encrypted assertions are consistently enforced, and whether logout or session handling creates residual access after user sign-out.
Decision rule: If the integration supports sensitive systems, broad workforce access, or partner federation, treat migration as the safer choice even when SAML 1.1 still functions. If you must retain it, put a sunset date and an exception owner on the record.
Practitioner takeaway: The important judgment is not whether SAML 1.1 can still authenticate, but whether its narrower and less standardized design is worth carrying as ongoing security debt when SAML 2.0 is available.
Related resources from NHI Mgmt Group
- How should security teams decide whether to keep a legacy SEG or move to an API-based email security model?
- How should security teams decide whether to keep a managed SOC or move to AI-assisted investigations?
- How should security teams decide whether to keep VDI or move to an enterprise browser?
- How do security teams decide whether to keep legacy search workflows or move to a piped query model for investigations?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
