---
title: "SAML at the Post-Quantum Crossroads"
date: "2026-04-24T12:00:00-07:00"
lastmod: "2026-04-24T12:00:00-07:00"
description: "SAML is still the enterprise SSO default, but XML Signature complexity, aging implementation stacks, and post-quantum migration pressure make it a poor long-term default for new deployments."
summary: "OpenID Connect is mature, standardized, and widely deployed, but SAML remains the enterprise SSO default because it is familiar, explicit, and deeply embedded in procurement and operations. That familiarity now hides a harder problem: XML Signature complexity, aging implementation stacks, limited post-login integration, and post-quantum migration pressure make SAML difficult to defend as the long-term enterprise baseline. The industry needs a secure enterprise OIDC profile and a credible migration path for existing SAML federations."
slug: "saml-at-the-post-quantum-crossroads"
tags:
  - "SAML"
  - "OpenID Connect"
  - "OAuth"
  - "IAM"
  - "Enterprise SSO"
  - "Post-Quantum"
  - "IPSIE"
---


For most enterprise identity teams, the post-quantum migration timeline will not arrive as a clean architecture decision. It will arrive as a deadline, and it will land on a SAML estate built for a different era.

OpenID Connect is not new. The OpenID Foundation [ratified the core specification in February 2014](https://openid.net/2014/02/). In October 2024, [nine OpenID Connect specifications were published as ISO/IEC international standards](https://openid.net/10-years-on-openidconnect-published-as-iso-spec/). The protocol is mature, widely deployed, and built on the OAuth 2.0 stack with more than a decade of enterprise deployment behind it.

And yet SAML is still the enterprise default for SSO.

SAML persists because enterprises built their buying and operating models around it. RFPs require it by name. Compliance teams know how to evaluate it. Identity teams know the rituals: exchange metadata, upload certificates, map attributes, test login, document the break-glass path, and move on. SAML also has a security intuition enterprises value. The trust boundary is explicit, the IdP certificate is pinned, and the customer controls the relationship in a way that feels concrete. These are not irrational preferences. They reflect properties SAML delivers and that OIDC, deployed carelessly, does not always match.

The problem is that the familiarity that makes SAML feel like the conservative choice has made it harder to see where it has stopped being one.

XML Signature complexity has produced a vulnerability class that smart implementers keep falling into. [The 2012 research](https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/somorovsky) that found critical wrapping vulnerabilities in eleven of fourteen SAML frameworks was not an isolated event. The same class of flaw surfaced in [major disclosures in 2018](https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations), in [CVE-2024-45409](https://nvd.nist.gov/vuln/detail/CVE-2024-45409), and again in 2025 ruby-saml authentication bypasses including [CVE-2025-25291](https://rubysec.com/advisories/CVE-2025-25291/) and [CVE-2025-25292](https://rubysec.com/advisories/CVE-2025-25292/). Most enterprise SAML implementations depend on libraries assembled in the early-to-mid 2010s, now maintained unevenly, with much of the institutional XMLDSIG expertise gone from the organizations that depend on them.

Post-quantum cryptography turns that deferred problem into a fixed deadline. NIST finalized its first post-quantum signature standards in August 2024: [FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final) and [FIPS 205 (SLH-DSA)](https://csrc.nist.gov/pubs/fips/205/final). Federal agencies are inventorying authentication dependencies. Enterprise identity migrations can take years when they touch thousands of integrations. Organizations treating post-quantum migration as a future problem are already spending the planning window.

SAML is not broken. Enterprises should not rip it out overnight. But it should no longer be the default for new enterprise SSO, and existing estates need a migration plan before the deadline is imposed rather than chosen.

# Why SAML Still Wins

SAML remains dominant because the enterprise buying and operating model was built around it.

Many RFPs still ask for SAML by name. Compliance teams know how to evaluate it. SaaS vendors know that if they do not support SAML, they may lose enterprise deals before a security architect ever reads their OIDC documentation. Identity teams have years of runbooks for exchanging metadata, rotating certificates, mapping attributes, testing IdP-initiated and SP-initiated login, and recovering from lockouts.

For browser-based workforce SSO, SAML is often boring in the best sense: it is well understood, broadly supported, and easy for enterprise administrators to reason about. SAML has not failed. The environment around it has.

There is also a security intuition behind SAML that should not be dismissed. In a typical SAML deployment, the service provider pins trust to an IdP signing certificate or metadata document controlled by the customer. The customer can often bring their own PKI, rotate keys through a known administrative process, and reason about the blast radius of a compromised signing key in a way that feels concrete.

OIDC, by contrast, is often perceived as more dynamic. The relying party discovers issuer metadata, follows a JWKS URL, and validates JWTs against keys published by the issuer. That model is mature and secure when implemented correctly, but it can feel less tangible to enterprise buyers. A certificate uploaded into an admin console looks like a boundary. A URL that returns keys looks like a dependency.

OIDC also carries residue from early consumer login deployments: OAuth-shaped flows that were not clean OIDC, with tenancy assumptions very different from enterprise SSO.

Large multi-tenant providers compounded the perception problem. With some providers, personal accounts and enterprise accounts share the same issuer infrastructure and signing keys. The isolation model depends on the relying party validating tenant-specific claims correctly and using them safely in subject resolution, account linking, and authorization. That can be secure, but it is subtle. SAML's customer-specific IdP trust relationship is easier to explain in a procurement review.

Enterprise users also expect SSO dashboard tiles to launch applications directly, a pattern SAML IdP-initiated login made familiar. OIDC supports comparable experiences, but vendors that implement the flow poorly leave customers with the impression that OIDC is the problem rather than the implementation.

That is why SAML keeps winning. It is familiar, explicit, widely supported, and easy to require in procurement.

But enterprise familiarity is not the same thing as long-term safety. The question is no longer whether SAML can keep working. It is whether SAML should keep absorbing new enterprise identity requirements that its trust model was never designed to carry.

# The Assertion Ceiling

SAML is a presentation layer for authentication. The assertion is the relationship.

When a user logs in, the IdP constructs an assertion encoding what it knows about that user at that moment: a subject identifier, authentication context, and whatever attributes the integration was configured to include. The service provider validates it, maps the claims into a local session, and moves on. That is the protocol boundary. There is no ongoing connection, no shared API surface, and no standardized way for the service provider to query the IdP after the assertion is consumed.

That boundary matters because the enterprise identity graph is larger and more dynamic than any assertion can carry. The organizational context that enterprise applications actually need — reporting structures, cost center assignments, entitlements across systems, device posture, group memberships that change as people move roles — cannot be practically embedded in a login-time assertion. Either the IdP preloads every attribute every application might ever need, or each application maintains its own copy through a separate provisioning channel, or it works with incomplete information about the user it just authenticated.

The constraint extends beyond data richness. An application that needs to verify current entitlements before authorizing a sensitive operation cannot query the IdP through SAML. A service that wants to publish an access event back to the identity system has no standard SAML channel to do so. A policy engine that wants to evaluate real-time identity context at authorization time cannot call the IdP the way it would call any other API. Each of these capabilities requires a separate integration with a proprietary vendor API, a custom side channel, or nothing happens.

OIDC changes this because the service provider is an OAuth client. The IdP is an authorization server that can expose APIs the SP is entitled to call: richer profile queries, organizational data, entitlement lookups, event subscriptions. The authentication exchange is an entry point, not a ceiling. What modern enterprise security needs after login — dynamic authorization context, identity event subscriptions, real-time risk signals — can be delivered through the same trust relationship that authenticated the user.

This is part of what IPSIE is defining: not just how OIDC handles SSO, but how the IdP's API surface covers entitlements, lifecycle events, risk signal sharing, and the enterprise identity relationships that cannot live in an assertion. SAML provides no equivalent foundation.

That integration ceiling is one category of SAML risk. The second is more technical but equally structural: it lies in the implementation substrate that most of the world's SAML integrations are actually built on.

# The XML Problem

The issue is not that SAML is old. Old protocols can be excellent. The issue is the surface area created by XML and XML Signature.

[SAML 2.0](https://www.oasis-open.org/standard/saml/) is an OASIS standard for XML-encoded identity assertions, and its security depends heavily on correct XML canonicalization, reference resolution, ID handling, signature validation, and claim extraction. The relying party must not merely check that some signature is valid. It must ensure the signed element is the exact element whose claims are processed. That distinction sounds obvious until you look at the history of XML Signature wrapping and SAML validation bugs.

XML Signature signs specific nodes within a document, not the document as a whole. A wrapping attack inserts a second, unsigned copy of the assertion outside the signed scope. If the validator and the application disagree about which element to read, the signature check passes against the legitimate element while the application consumes claims from the attacker-controlled copy. The signed element is valid. The claims the application acts on are not from it.

The classic 2012 USENIX paper ["On Breaking SAML: Be Whoever You Want to Be"](https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/somorovsky) analyzed 14 SAML frameworks and found critical XML Signature wrapping vulnerabilities in 11 of them. In 2018, [Duo Labs disclosed SAML vulnerabilities affecting multiple implementations](https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations), including OneLogin libraries, OmniAuth-SAML, Shibboleth, and Duo Network Gateway. In both cases, the consequence was the same: an attacker with a legitimate account in the same federation could authenticate as any other user, including administrators, by exploiting the gap between what the signature covered and what the application processed. The root problem was that XML processing and signature validation diverge in subtle ways, allowing an attacker to substitute unsigned elements while the signature check passes.

That is the risk shape SAML carries. The attack surface lives in the gap between "the signature verified" and "the application processed the signed claims." XML makes that gap large enough that smart implementers have repeatedly fallen into it.

The pattern did not stop with the 2018 disclosures. In September 2024, a critical authentication bypass (CVE-2024-45409) was disclosed in ruby-saml, a widely deployed library used by GitLab and other applications. The root cause was the same: the library failed to enforce that the elements it extracted claims from were covered by the signature it validated. An unauthenticated attacker could forge a SAML response and authenticate as any user, including administrators, without valid credentials. GitLab issued an emergency security release and urged immediate patching across its customer base. Additional critical ruby-saml disclosures followed in 2025, including parser differential flaws that again allowed signature wrapping. The twelve-year span from the original USENIX paper to the present has not resolved the structural problem. It has confirmed it.

The vulnerability record points to a structural supply-chain problem that is more serious than any individual disclosure.

Most SaaS SAML implementations were built on open-source toolkits assembled during the early-to-mid 2010s, when enterprise SAML support was a procurement gate and implementation speed mattered more than long-term maintenance posture. The dependency graph runs from the SaaS product down through a SAML library, through an XML processing library, and into platform XML infrastructure. Each layer has its own release cadence, its own CVE history, and its own patch requirements. When a SAML library releases a fix for an XML Signature processing vulnerability, SaaS vendors that pin library versions must evaluate the change, test their customizations, update their code, and ship a release. Many do not do this promptly. Some have forked the library and added local patches, making upstream adoption require manual reconciliation. Some are running library versions that were already outdated when the product launched.

The maintenance dynamic compounds the risk. SAML support is typically treated as a procurement feature: once the enterprise requirement is satisfied, the implementation joins the maintenance queue. In many organizations, the engineers who built the original SAML stack are no longer at the company. The XMLDSIG expertise required to safely evaluate a new vulnerability disclosure (to assess whether the reported attack path applies to the specific way the product constructs, signs, validates, and processes assertions) is not retained. A new CVE in a SAML library triggers a dependency update process, not a security design review, because the institutional context for a design review no longer exists.

The practical result is a long tail of implementations in various states of maintenance, running various library versions, with varying levels of signature-wrapping test coverage and varying institutional knowledge of why specific implementation choices were made.

This is what makes the XML problem structurally different from a standard software vulnerability. It is not one flaw in one implementation that can be patched. It is a property of XMLDSIG that creates a high-complexity validation problem for every implementation, reproduced across Java, Python, Ruby, PHP, and .NET, across different teams, in different decades, sustained indefinitely by a supply chain that treats SAML as a procurement checkbox rather than a security subsystem.

# Post-Quantum Raises the Stakes

Post-quantum cryptography changes the SAML conversation because authentication signatures are squarely in the migration scope.

NIST finalized its first post-quantum signature standards in August 2024: [FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final) and [FIPS 205 (SLH-DSA)](https://csrc.nist.gov/pubs/fips/205/final). NIST's draft transition guidance, [IR 8547](https://csrc.nist.gov/pubs/ir/8547/ipd), identifies RSA, ECDSA, and EdDSA as quantum-vulnerable signature standards and sketches a migration path away from them. Cloudflare has published a [2029 target for full post-quantum security](https://blog.cloudflare.com/post-quantum-roadmap/) across its infrastructure, including authentication. The direction is not speculative. The question for enterprise SAML estates is not whether authentication signatures need to move, but whether the SAML implementation substrate can execute that migration.

The planning arithmetic is not comfortable. Federal agencies are already expected to inventory cryptographic dependencies. Enterprise identity platform procurement and migration cycles can run years for anything touching thousands of integrations. If algorithm deprecation requirements harden around 2030, the window to begin planning is already open. Organizations that start this cycle will have chosen their timeline. Organizations that wait for a hard regulatory requirement will have it imposed.

For organizations subject to federal compliance requirements, the framing is more concrete. NIST's draft transition plan points federal agencies and the broader market toward retiring quantum-vulnerable public-key signatures on a defined horizon. Federal contractors operating under CMMC or FedRAMP should expect those expectations to flow into assessments and procurement. If that pressure arrives before the SAML implementation stack in production can support ML-DSA or SLH-DSA, the enterprise SSO infrastructure chosen for its auditability becomes a compliance liability. The audit posture SAML was selected to maintain becomes the reason migration is urgent.

For browser SSO, the core dependency is assertion integrity: can the service provider prove that the IdP signed the exact assertion the application is about to trust? In the most common SAML deployment, the IdP signs assertions with an RSA or ECDSA key, and the service provider validates that signature against a known certificate. Migrating to ML-DSA or SLH-DSA means updating the signing algorithm in the IdP, distributing new public key material to every service provider's trust configuration, updating the SAML library to implement the new algorithm, updating the XML Signature algorithm identifiers used in assertions, and ensuring every validation path in every relying party correctly processes the new key type and signature format.

For bilateral SAML integrations, that is a coordination problem multiplied across every integration in every deployment. For large academic and research federations (InCommon in North America, eduGAIN across Europe) the coordination scope is far larger. These federations connect hundreds of institutions and applications through centralized metadata authorities. A post-quantum migration requires coordinating algorithm changes across participants with widely varying technical capacity, update timelines, and institutional processes. The centralized metadata model that makes SAML federation manageable in normal operations becomes an amplification factor for migration risk when a disruptive algorithm transition is required.

There is also a retroactive exposure, though it applies to a specific subset of deployments. Most SAML integrations sign assertions for integrity but do not encrypt them for confidentiality. For deployments that do use encrypted assertions, if that traffic was intercepted and stored (a viable approach for a well-resourced adversary with patience), those assertions become decryptable once quantum capability is available. This is the harvest-now-decrypt-later risk applied to identity data: names, email addresses, group memberships, entitlements, and authentication context recorded across every SSO login. For most enterprise SSO deployments the sensitivity of this data is lower than for financial or health records, but the exposure is real and is specific to SAML assertion encryption rather than general TLS traffic.

OIDC is built on OAuth, which has continued to evolve under active security pressure. [RFC 9700](https://datatracker.ietf.org/doc/html/rfc9700) updates the OAuth 2.0 security baseline based on more than a decade of deployment experience, and [OAuth 2.1](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/) is consolidating those lessons into the core authorization framework by requiring PKCE, removing weaker grant types, and tightening redirect URI behavior. That matters because OIDC inherits an ecosystem that is still actively narrowing unsafe optionality.

OIDC and OAuth also sit on top of the JOSE family of standards (JWT, JWS, JWK, JWKS), which are designed for algorithm extensibility. A new signature algorithm requires a new JWK key type, a new JWKS entry, and updated validation logic. The ecosystem plumbing (discovery, key rotation, JWKS caching, metadata) is already built to accommodate algorithm transitions. When post-quantum algorithm support arrives, the deployment path through JOSE will be narrower than through XMLDSIG in existing enterprise SAML stacks, because the extensibility points are designed in rather than retrofitted.

That is not a protocol purity argument. JOSE implementations will also require significant work: library updates for new algorithm types, key management infrastructure changes, and validation path updates across every token-consuming service. The post-quantum migration for OIDC is not free. But there is a material difference between an ecosystem where algorithm agility is an ongoing engineering concern and one where most implementations are in maintenance mode.

The supply-chain debt described in the previous section does not diminish for post-quantum migration. It intensifies. The same SaaS organizations that have not kept their SAML library dependency current for routine CVE patches will face a more complex migration: new algorithm support requiring new library versions, new key management, new certificate infrastructure, and coordination with every customer integration. Unlike a routine CVE patch, there is no option to defer indefinitely. When migration timelines become binding, the organizations that deferred longest carry the most concentrated coordination risk.

# Why Migration Is Hard

Post-quantum migration does not create new migration obligations for SAML estates. It converts deferred maintenance into a hard deadline.

Saying new SSO integrations should use OIDC is the easy part. Migrating the existing estate is not.

Most enterprise applications in production already have established SAML federations. Those integrations are tied to user identifiers, group mappings, role assignments, SCIM provisioning, app sessions, break-glass processes, help desk runbooks, audit expectations, and contractual support language. Changing the SSO protocol is not a refactor. It is an operational event with outage risk.

From the customer's perspective, the upside often looks small. If the migration goes perfectly, users may see one extra redirect or no visible change at all. If it goes badly, users are locked out, the help desk floods, executives cannot access critical apps, and the identity team owns the incident.

This is why SAML persists even when everyone in the room agrees that OIDC is the modern direction. The migration cost is immediate and local. The security benefit is long-term and systemic. The person approving the migration carries the outage risk while the benefit accrues to a future operating model.

Vendors keep implementing SAML because customers require it. Customers keep requiring SAML because vendors support it and their existing estate runs on it. New vendors that would prefer to implement OIDC still worry that excluding SAML will shrink their enterprise TAM. If they expect to support SAML eventually, they implement it early and add yet another SAML stack to the world.

The missing ingredient is not a better argument for OIDC. It is a migration path that is explicit, standardized, and low-risk enough that the people approving migrations can trust it, and that vendors can build to without inventing a bespoke solution for every customer.

A single enterprise SAML integration may depend on a NameID format, custom attribute mappings, group-to-role rules, SCIM provisioning assumptions, certificate rotation procedures, IdP-initiated launch behavior, session timeout expectations, and help desk recovery paths. None of those show up in a simple protocol comparison chart. Every one can break during migration.

# What Would Make SAML Defensible

The argument is not that SAML is bad and OIDC is good. OIDC has its own failure modes, and a careless OIDC deployment can be worse than a careful SAML deployment. The argument is that SAML's long-term risk is structurally harder to retire.

That argument would be weaker if the SAML ecosystem had broad XMLDSIG conformance tests, maintained post-quantum-capable libraries across the major language stacks, standardized migration-safe subject continuity, and made cryptographic algorithm transition operationally boring. If enterprise SAML deployments could show current dependency hygiene, signature-wrapping regression coverage, clear key rotation procedures, and a tested path to post-quantum signatures, SAML would be easier to defend as a long-term default.

That is not the ecosystem most enterprises actually have. They have working integrations, aging libraries, undocumented mappings, fragile account-linking assumptions, and operational knowledge distributed across vendors, administrators, and runbooks. The exact Q-day does not matter for this argument. What matters is that identity migration has a long dependency chain, and most SAML estates are poorly positioned for coordinated algorithm migration.

# The Crossroads

The enterprise technology industry has been at this junction before, and the pattern is familiar. SHA-1 certificate deprecation looked optional until browser vendors coordinated a hard deadline and the long tail of non-compliant sites failed publicly. TLS 1.0 and 1.1 removal was deferred across the industry until browser cutoffs made non-compliance a user-visible problem rather than a future risk. In each case, organizations that treated the transition as somebody else's future problem were the ones scrambling when the deadline arrived. The technology to migrate had existed for years. The pressure to act had not.

What distinguished the transitions that went well from the ones that did not was not just urgency. It was whether the migration path was built into the technology itself. SHA-2 and SHA-1 could coexist during transition because certificate chains support multiple signature algorithms simultaneously. TLS negotiation allowed servers to support both old and new protocol versions during rollout before old versions were disabled. The transitions that succeeded with the least disruption were the ones where parallel operation was possible: old trust and new trust recognized simultaneously, with a defined handoff point rather than a hard cutover.

One path is to continue treating SAML as indefinitely safe because it is familiar. That path says the existing enterprise estate is too large to move, XMLDSIG problems are manageable with careful libraries, and post-quantum migration can be handled later when requirements become concrete. It is a coherent position in the short term. The integrations work. The audits pass. The security team has other priorities.

What that path looks like in five to ten years is less comfortable. Post-quantum migration timelines convert deferred XMLDSIG maintenance debt into a coordinated emergency. Organizations with hundreds or thousands of SAML integrations face cutover pressure across a supply chain where library versions are old, institutional knowledge is gone, and the vendors they depend on are also scrambling. Meanwhile, the enterprise security baseline continues to shift beyond login toward continuous access evaluation, shared risk signals, and identity-aware authorization, and SAML-only deployments remain structurally unable to participate in that shift without a separate OAuth integration bolted on the side. The integrations still work. The security model does not keep pace.

The other path is to plan. Not because SAML stopped working, and not because every SAML deployment is insecure today, but because the combination of XML Signature complexity, supply-chain maintenance debt, limited post-login security integration, and post-quantum migration pressure makes it a poor long-term default. On this path the timeline is chosen, not imposed.

What that path looks like in five to ten years is also concrete. New enterprise SSO integrations run on OIDC by default, against a secure baseline profile that buyers can require and vendors can demonstrate conformance against. Migration tooling makes SAML-to-OIDC transitions low-risk and auditable rather than high-stakes cutovers. SAML continues to run where it runs, maintained as legacy-critical infrastructure, while the forward edge of enterprise identity runs on the OAuth stack that continues to absorb new security guidance. When post-quantum migration deadlines become binding, the most sensitive integrations are already on JOSE, and the remaining SAML estate is smaller and better mapped.

Planning means buyers stop writing RFPs that require SAML by name without also accepting secure OIDC profiles. It means vendors stop treating SAML as the inevitable enterprise requirement for all future customers. It means identity providers and application vendors develop migration patterns that preserve subject continuity, group and role mappings, session behavior, and recovery paths. And it means the industry builds conformance tests that define what secure enterprise OIDC actually means, including a transition story that does not ask every customer to accept a high-risk cutover.

# Two Things Would Help

The first is a clearer definition of secure enterprise SSO for OIDC.

The OpenID Foundation's [IPSIE Working Group](https://openid.net/wg/ipsie/) is working toward that: profiles for enterprise identity covering single sign-on, user lifecycle management, entitlements, risk signal sharing, logout, and token revocation, with a charter that explicitly prioritizes secure defaults. That work matters because "supports OIDC" is not a security claim. OIDC has its own failure modes: issuer mix-up, redirect URI mistakes, weak `state` or `nonce` handling, unsafe account linking, tenant-claim misuse, and JWKS caching errors. OAuth's recent evolution is the closest precedent: the ecosystem moving from broad protocol capability toward sharper secure-profile guidance through RFC 9700 and OAuth 2.1. Enterprise buyers need an equivalent baseline for OIDC SSO. Vendors need a target they can build to and demonstrate conformance against. Optionality is where interoperability and security both go to die.

The second is a real SAML-to-OIDC migration story.

It is not enough to tell customers to create a new OIDC application and cut over. Migration has to preserve the identity contract the application already depends on. That means mapping SAML issuers, NameIDs, attributes, groups, and tenant identifiers into OIDC issuer and claim semantics without breaking subject resolution. It means supporting staged rollout, dual configuration, telemetry, rollback, and test modes. It means giving administrators confidence that users, groups, roles, and sessions will survive the move. At minimum, a credible migration story needs to cover:

- Preserve the existing SAML subject binding so the application does not accidentally create a second account for the same user.
- Establish the OIDC issuer as the successor trust anchor for the same enterprise relationship.
- Map SAML attributes, groups, and tenant identifiers into OIDC claims without changing application authorization semantics.
- Support parallel validation during rollout so administrators can test the new OIDC path before disabling SAML.
- Give the application a way to distinguish an intentional protocol migration from accidental or malicious account linking.

The industry does not yet have a standard answer to any of these requirements. Each vendor that has attempted SAML-to-OIDC migration has invented its own approach, with its own subject-mapping logic, its own account-linking semantics, and its own untested edge cases. That bespoke improvisation is what makes migration feel more dangerous than it should be, and it is why some migrations that appeared to succeed produced silent account-linking errors that only surfaced later.

I published a draft profile to address this directly: [OpenID Connect SAML Migration Profile](https://mcguinness.github.io/draft-connect-saml-migration/draft-mcguinness-saml-oidc-migration-profile.html). The goal is to make the migration path explicit enough that an existing SAML deployment can move to OIDC without each vendor inventing a bespoke, high-risk process. It provides a shared description of the relationship between the old SAML trust and the new OIDC trust that lets applications verify the migration is intentional rather than an accidental account-linking event. That specification is early. It needs review from the identity providers, application vendors, and enterprise architects who know where the real edge cases are.

# What to Do Now

Enterprise buyers should change procurement language now. If an RFP requires SAML, it should also accept a secure enterprise OIDC profile. Better: SAML should be treated as a legacy compatibility protocol, while new enterprise SSO requirements should require secure OIDC support with documented SAML-to-OIDC migration semantics. The more important question is not whether a vendor supports both protocols, but how they handle migration: does their OIDC implementation preserve subject continuity for accounts that currently authenticate via SAML, or does it require a high-risk cutover? That question, asked early in procurement, changes what vendors prioritize. Buyers should also inventory existing SAML integrations for the ones most likely to become blockers: custom NameID formats, fragile attribute mappings, manual certificate rotation, and undocumented group and role mappings are the integrations that make migration expensive.

Application vendors should prefer OIDC for new enterprise SSO, while treating existing SAML support as legacy-critical infrastructure that requires real maintenance, not just a checkbox. That means dependency tracking, XMLDSIG test coverage, signature-wrapping regression tests, and certificate-rotation hygiene. The test to apply: can you migrate a SAML customer to OIDC without creating a second account or disrupting their group and role assignments? If the answer is no, the OIDC implementation is not production-ready for enterprise migration.

Identity providers and standards groups should make the path boring enough that enterprise buyers can require it in procurement language and vendors can demonstrate conformance against it. IPSIE can define the secure enterprise OIDC baseline. Migration profiles can define how existing SAML relationships move without account-linking ambiguity or high-risk cutovers. Conformance tests can turn those expectations into something verifiable rather than aspirational.

The organizations that start now will have chosen their timeline. The ones that wait will have it chosen for them, by the next signature-validation disclosure, a supply-chain failure in a SAML library they forgot they depended on, or a post-quantum deprecation deadline that arrives before their XMLDSIG stack is ready to move.

# Get Involved

There are two places where the work described in this post is happening and where outside perspective matters most.

## OpenID Connect SAML Migration Profile

The [OpenID Connect SAML Migration Profile](https://mcguinness.github.io/draft-connect-saml-migration/draft-mcguinness-saml-oidc-migration-profile.html) is an early-stage draft, not a finished standard. The goal is to get the problem definition and requirements in front of people who will actually have to execute this migration, and find out where the approach is wrong before it goes further.

If you work on enterprise identity, one of these questions is probably worth your time:

- **Identity providers**: Does this profile describe what your migration tooling already does? Where does it conflict with your implementation, and where are the gaps?
- **SaaS application vendors**: If you support both SAML and OIDC today, does this profile give you a workable path to migrate existing SAML customers without a high-risk cutover? What is missing?
- **Enterprise architects**: If you are planning or deferring a SAML-to-OIDC migration, does this profile address the identity contract requirements that make migration feel risky?
- **Standards reviewers**: The subject-mapping semantics and trust relationship model should be challenged. If the approach does not hold for your deployment scenario, that feedback is exactly what shapes whether this becomes a useful standard.

Feedback and discussion are open on [GitHub](https://github.com/mcguinness/draft-connect-saml-migration).

## IPSIE Working Group

The [IPSIE Working Group](https://openid.net/wg/ipsie/) at the OpenID Foundation is defining what secure enterprise OIDC actually means in practice: profiles for SSO, user lifecycle management, entitlements, risk signal sharing, logout, and token revocation. That work is only as good as the enterprise requirements it is built against.

If you are an enterprise buyer with real deployment constraints, an identity provider with implementation experience, or a SaaS vendor who has navigated the gap between "supports OIDC" and "secure for enterprise," the working group needs your input. The specifications produced there will become the baseline that procurement language can require and vendors can build to. Getting the requirements right now is easier than correcting them after conformance tests exist.

Information on participating is available at [openid.net/wg/ipsie](https://openid.net/wg/ipsie/).