Is SAML 2.0 Still Relevant in 2026? An Honest Assessment

Is SAML 2.0 still relevant in 2026? Yes — but for a narrower job than either its advocates or its obituary writers claim. SAML 2.0 remains the entrenched standard for legacy enterprise SSO and B2B federation, and enormous amounts of working single sign-on run on it every day. At the same time, OpenID Connect has decisively won mobile, APIs, single-page applications, and effectively every new build. The interesting question in 2026 is not "SAML or not" — it's which workloads SAML still genuinely serves, how to harden what stays, and how to migrate the rest without breaking SSO for the applications that pay the bills.

This piece is the 2026 update of our original SAML 2.0 relevance assessment, rewritten from scratch for where enterprise federation actually stands today. The original asked whether a 2005-era protocol could survive the cloud transition; it did. This update asks the harder question — where SAML remains the right answer rather than merely a surviving one — and gives the honest boundaries in both directions.

What SAML 2.0 actually is, and why it refuses to die

SAML 2.0 — Security Assertion Markup Language — is an XML-based federation standard ratified by OASIS in March 2005. Its core transaction is simple: a user attempts to access a service provider (SP), the SP redirects the browser to the enterprise identity provider (IdP), the IdP authenticates the user, and the IdP sends back a digitally signed XML assertion stating who the user is and, optionally, attributes about them. The SP validates the signature against the IdP's published certificate and starts a session. No password ever touches the application.

That design solved the defining problem of 2000s enterprise IT — one login across a sprawling application portfolio, with the credential held in exactly one place — and it solved it well enough that the entire enterprise software industry standardized on it. ERP suites, HR platforms, finance systems, healthcare applications, government systems, and a full decade of B2B partner integrations were built with SAML as the federation interface. Procurement checklists demanded it. Compliance frameworks referenced it. Every major identity provider shipped it.

That installed base is why SAML refuses to die. Protocols with this much deployed surface don't get deprecated by blog posts; they get slowly surrounded, and their share of the portfolio shrinks as applications gain support for the successor and old systems retire. Directionally, that shrinkage is well underway — but "shrinking" and "gone" are very different claims, and enterprises that plan as if SAML is already gone break real SSO for real users.

Where SAML 2.0 remains the right answer

Three workloads keep SAML not just present but correct in 2026.

Legacy enterprise application SSO. The long tail of the enterprise portfolio — on-premises ERP modules, vertical line-of-business applications, older SaaS contracts, anything whose federation support was implemented between roughly 2006 and 2016 — speaks SAML and frequently speaks nothing else. These applications work. Their integrations are tested, certified in regulated environments, and embedded in audit narratives. Replacing a working, compliant SAML integration with an OIDC one delivers zero user-visible value while consuming real change budget and real regression risk. For this tier, operating SAML well beats migrating it on principle.

B2B federation. When two organizations federate — a manufacturer giving a supplier's employees access to a portal, a healthcare network federating with an insurer — the integration is governed by contracts, certificate exchanges, and two change-management bureaucracies. SAML's metadata-driven trust model was built for exactly this, and thousands of these agreements are live. Renegotiating a working cross-organization federation to swap protocols requires both parties to spend money for no functional gain, which is why B2B federation will likely be SAML's last stronghold long after workforce SSO has largely moved on.

Regulated and audit-frozen environments. In environments where every authentication path is documented in a compliance package — think validated systems in pharma, assessed environments in government supply chains — the cost of change includes re-assessment. A hardened, monitored SAML integration inside a frozen compliance boundary is often the lowest-risk option available, and the mature move is to schedule its replacement with the next platform refresh rather than force it early.

The common thread: SAML earns its keep where the integration is the asset — entrenched, certified, cross-organizational — not where the protocol itself is preferred. Nobody chooses XML canonicalization for fun in 2026.

Where OIDC has won, and why

OpenID Connect, finalized in 2014 as an identity layer on top of OAuth 2.0, has won everything SAML was never built for — and by now, essentially everything new.

One login, two protocols: OIDC takes the new estate and everything mobile or API-shaped, while hardened SAML holds the entrenched one.

The reasons are structural, not fashionable. SAML is XML with XML digital signatures, which means canonicalization, schema complexity, and a parser attack surface; OIDC is JSON and JWT, which every modern stack handles natively. SAML's browser-POST bindings assume a browser; OIDC's flows work identically for web apps, native mobile apps, and single-page applications, with PKCE solving the public-client problem SAML simply has no answer for. And SAML ends at authentication — it hands the application an assertion and leaves — while OIDC arrives together with OAuth 2.0 access tokens, so the same flow that authenticates the user also authorizes their API calls. In an architecture where every application is a client of a dozen APIs, that composition is decisive. The OAuth 2.0 vs OpenID Connect reference covers the token mechanics; the OAuth explained piece covers how the OAuth family threads into identity governance workflows.

There is also a quieter operational argument that rarely makes the protocol-war slide decks. An OIDC integration is discoverable — the IdP publishes its endpoints and keys at a well-known configuration URL, clients fetch them automatically, and key rollover propagates without a human in the loop. A SAML integration is a ceremony: metadata files exchanged by email, certificates pasted into admin consoles, and an expiry date that will one day pass on a certificate nobody is watching, taking SSO down with it. Ask any identity team where their federation outages actually come from and expired SAML signing certificates will be near the top of the list. That gap — self-service discovery versus managed ceremony — compounds across hundreds of integrations, and it is a real cost even when the protocol itself is working perfectly.

Just as telling: the specification ecosystem moved. PKCE, token exchange, financial-grade API profiles, continuous-access evaluation work — all of it builds on the OAuth/OIDC stack. SAML 2.0 has been essentially frozen since ratification. A finished standard is not a dead one, but it is one where no new capability will ever land, and architects should price that in.

The decision map: which protocol for which workload

Put the two previous sections together and the decision stops being ideological. The question is never "which protocol is better" — it's "which protocol does this specific workload already speak, and what does changing that cost."

Use-case fit, not protocol loyalty: SAML keeps the entrenched and cross-organizational; OIDC takes mobile, APIs, and everything new.

Two failure modes show up in real programs, one per direction. The first is premature rip-out: a modernization mandate declares SAML legacy, teams start forcing OIDC onto applications that support it badly or not at all, and the program stalls with broken SSO and angry application owners. The second is habitual SAML: a team that has always configured SAML relying parties stands up new integrations on SAML in 2026 because the runbook exists — accumulating fresh instances of exactly the debt the enterprise is trying to retire. The decision map exists to stop both. New integrations default to OIDC and need a written justification to be SAML; existing SAML integrations default to staying and need a business trigger — app upgrade, contract renewal, platform refresh — to migrate.

Hardening the SAML that stays

If SAML remains in the architecture — and for most enterprises it will for years — it must be operated as a hardened legacy surface, because its XML foundation carries attack classes OIDC deployments simply don't have.

XML signature wrapping (XSW). The signature in a SAML response covers a specific element, but XML documents can be restructured so the SP's signature validation finds and validates the original signed assertion while the SP's business logic processes a different, attacker-injected assertion elsewhere in the document. This class of attack was demonstrated against a wide range of real SAML implementations in published research and still resurfaces in new integrations. The mitigation is precise: validate exactly the element the signature covers, process only that element, and reject documents whose structure deviates from the expected schema — never "find a valid signature anywhere, then trust the document."

Assertion replay. A SAML assertion intercepted in transit or recovered from logs is a bearer credential for its entire validity window. Mitigations are configuration, not code: short assertion lifetimes (NotOnOrAfter measured in minutes, not hours), one-time-use enforcement by caching consumed assertion IDs, strict audience restriction so an assertion for one SP can't be presented to another, and InResponseTo validation so unsolicited responses are rejected outright.

XML parser risks. Any SAML consumer is an XML parser exposed to semi-trusted input, which means the classic parser attacks — XML external entity injection (XXE), entity-expansion denial of service — apply. Parsers in the SAML path must have external entity resolution disabled and hard limits configured. This is table stakes, and it's still missed.

Signing-key custody. Every mitigation above assumes the IdP's signing key is actually secret. The "Golden SAML" technique — steal the federation signing key, mint arbitrary assertions for any user to any SP — is a documented post-compromise pattern against federation servers, and it bypasses MFA entirely because the forged assertion is the proof of authentication. Signing keys belong in HSMs, certificate rotation belongs on a calendar, and assertion volume anomalies belong in monitoring.

None of this is exotic. Every mitigation listed is well understood and supported by mainstream SAML libraries and IdPs. The honest observation from the field is that they are unevenly applied — especially in integrations configured a decade ago and untouched since. A one-day audit of every production SAML relying party against this list is among the cheapest security work an identity team can do in 2026.

The audit has a prerequisite most teams discover the hard way: a complete inventory. SAML integrations accumulate over years, across admin consoles, and outlive the people who configured them — which means the first pass usually turns up relying parties nobody currently owns, certificates within weeks of expiry, and at least one integration still accepting unsigned requests because a 2015 troubleshooting session relaxed the setting and nobody put it back. Inventory first, then harden, then put certificate expiry and assertion-volume anomalies on a dashboard someone actually looks at.

Coexistence and migration: the IdP-brokered pattern

The realistic end-state for most enterprises is not "SAML eliminated" but "SAML contained." The pattern that gets there without breaking SSO is IdP brokering.

Consolidate federation onto an identity provider that speaks both protocols natively. Users authenticate once — ideally with phishing-resistant, FIDO2-compatible credentials — and the IdP federates outward to each application in whichever protocol that application speaks: OIDC to the modern estate, SAML to the legacy and B2B estate. The user never knows the difference; the protocol boundary becomes an implementation detail of each application integration rather than an architectural fault line.

Brokering converts migration from an event into a backlog. Inventory every SAML relying party and tag each one: OIDC-capable now (the app already supports OIDC — migrate at the next low-risk change window), OIDC-capable after upgrade (schedule with the application's own upgrade cycle), or SAML-forever (no OIDC on the vendor roadmap, or a B2B/frozen-compliance integration — apply the hardening checklist and stop feeling guilty). The first two categories burn down over quarters on the application teams' schedules; the third gets operated deliberately. The legacy IAM modernization playbook covers the broader sequencing discipline this slots into, and the cross-platform identity piece covers keeping identity coherent while the estate spans protocols and platforms.

Broker both protocols at the IdP, migrate app by app on the application’s own schedule, and operate the SAML-forever remainder deliberately.

The unglamorous work inside each migration is claim parity. A SAML relying party consumes attributes — name formats, group memberships, entitlement strings — that the application's authorization logic silently depends on, and the OIDC integration must reproduce them as claims exactly before cutover. The migrations that go badly are almost never protocol failures; they are attribute-mapping failures discovered in production. Map the assertion attributes to ID token claims explicitly, test against the application's actual authorization paths, run the two integrations in parallel for a validation window, and only then retire the SAML relying party.

One more boundary worth drawing: brokering is for the workforce and B2B tier. Machine-to-machine and cloud-workload identity should not touch SAML at all — that layer belongs to OAuth 2.0 client credentials and cloud-native workload identity federation, covered in the multi-cloud identity management piece. If SAML assertions are flowing between services with no human in the loop, that's an architecture smell, not a coexistence pattern.

What Avatier ships toward this pattern

Avatier Identity Anywhere is built for the mixed estate this piece describes rather than for a purity story. The platform federates with the enterprise IdP over both SAML 2.0 and OpenID Connect, so it drops into either side of a brokered architecture without forcing a protocol decision. More importantly, its governance layer is protocol-neutral: lifecycle provisioning and deprovisioning, access requests, certification campaigns, and self-service operate across the application portfolio regardless of whether a given app's SSO rides an XML assertion or an ID token — which is exactly what makes the app-by-app migration backlog governable instead of chaotic. Authentication in front of either protocol can be phishing-resistant, with FIDO2-compatible credential support.

For teams that need to show their auditors the posture behind that claim, Avatier publishes its own at the Avatier Trust Center: SOC 2 Type II with zero exceptions, ISO/IEC 27001:2022 certified, PCI DSS v4.0.1 compliant, CSA STAR Level 1, NIST 800-53 Rev. 5 aligned, FedRAMP-aligned, and a signatory of the CISA Secure-by-Design Pledge. The SSO architecture piece on ICC covers the workforce SSO layer this federation work plugs into.

Where SAML genuinely should be retired

An honest assessment owes the other boundary too. SAML should be actively retired — not hardened, not tolerated — in four places. Anywhere a mobile or native app is involved: SAML's browser-POST model was never built for it, and the workarounds are all worse than OIDC with PKCE. Any API or service-to-service authorization: SAML has no answer for delegated API access, and bolting it on reinvents OAuth badly. Any new integration where both sides support OIDC: choosing SAML there is habit, not architecture, and it manufactures future migration debt at the moment of creation. And any deployment that can't meet the hardening bar — if an integration can't be configured for strict signature validation, short-lived one-time assertions, and sane parser settings, its continued existence is a risk decision someone should be signing, not a default.

Everything else — the entrenched enterprise portfolio, the B2B agreements, the audit-frozen integrations — SAML keeps, for years, and that's fine. Twenty years in, SAML 2.0 has earned an unglamorous verdict: no longer the future, still load-bearing in the present, and deserving of the same operational seriousness as any other system the enterprise actually depends on. Treat it that way and the protocol will retire on your schedule instead of an attacker's.