They keep SAML because migration is not only technical. It also affects trust relationships, compliance evidence, legacy application behaviour, and onboarding processes across many service providers. When those dependencies are already built around SAML assertions, replacing them can create more risk than value.
Why This Matters for Security Teams
Many enterprises keep saml after adopting OIDC because the real dependency is not just on an authentication protocol, but on the trust, evidence, and operational patterns built around it. SAML often remains embedded in legacy SaaS integrations, federation agreements, and audit workflows, while OIDC is introduced for newer apps and APIs. That split is common in hybrid identity estates and reflects the migration reality described in the Ultimate Guide to NHIs — Why NHI Security Matters Now.
The security issue is that protocol coexistence can hide inconsistent assurance levels, duplicated claim mappings, and different session lifetimes across applications. Teams often assume OIDC is a replacement for SAML, when in practice it is usually an addition. That means IAM teams must manage both trust models with clear policy, not just chase the newer standard. The NIST Cybersecurity Framework 2.0 is useful here because it frames identity as an ongoing governance problem, not a one-time protocol decision. In practice, many security teams discover SAML sprawl only after a federation breakage or compliance review exposes how many services still depend on it.
How It Works in Practice
Enterprises usually run SAML and OIDC side by side because each serves different application eras and different integration assumptions. SAML remains common for browser-based enterprise SSO, older SaaS platforms, and partners that expect assertion-based federation. OIDC is better suited to modern web apps, mobile clients, APIs, and workload-style interactions where JSON tokens and shorter-lived sessions are easier to consume.
In practice, migration is less about swapping one protocol for another and more about mapping trust relationships safely. Security teams typically need to preserve:
- Assertion or token claims that downstream apps use for authorisation
- Session length, logout behaviour, and reauthentication rules
- Attribute release policies for users, groups, and entitlements
- Compliance evidence for access reviews, MFA, and federation controls
That is why many environments keep SAML for stable, high-risk, or hard-to-change applications while introducing OIDC for new builds and cloud-native services. The choice is often driven by service provider readiness, not preference. This is also where NHI governance intersects with identity architecture: service accounts, API keys, and automation often sit beside human SSO flows, and the Hugging Face Spaces breach is a reminder that identity failures are rarely limited to one protocol or one user class. Current guidance suggests treating SAML-to-OIDC migration as a controlled coexistence plan with explicit trust boundaries, not a big-bang cutover. These controls tend to break down when federated applications have hard-coded SAML attribute dependencies or when partner-managed SP configurations cannot be updated in lockstep.
Common Variations and Edge Cases
Tighter protocol standardisation often reduces long-term maintenance, but it also increases migration cost and business disruption, so organisations have to balance modernisation against operational continuity. That tradeoff is especially visible where SAML carries legal, audit, or partner-facing commitments that OIDC alone does not immediately satisfy.
There is no universal standard for this yet, but best practice is evolving toward protocol choice by use case rather than by ideology. A few common edge cases explain why SAML survives:
- Large SaaS ecosystems where the vendor only supports SAML for enterprise federation
- Legacy apps that rely on signed saml assertion and do not accept OIDC token flows
- Brokered identity models where an IdP translates one protocol into another for downstream services
- High-assurance environments that require long-standing audit artifacts tied to SAML-based controls
For many teams, the right answer is not “replace SAML everywhere,” but “use OIDC where it improves developer and API integration, and retain SAML where the risk of change is higher than the benefit.” The migration plan should document which trust relationships are still anchored in SAML, which ones can move, and which ones must remain until the application or partner ecosystem changes. That is the practical approach reflected across identity governance guidance, including the NIST view that identity risk must be managed as a lifecycle issue rather than a protocol preference. In mature enterprises, the hardest part is usually not the OIDC rollout itself, but proving that every surviving SAML dependency is still intentional.
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.AA-01 | Identity proofing and access assurance fit protocol coexistence decisions. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Legacy SAML dependencies often mask weak NHI lifecycle control. |
| NIST AI RMF | Governance guidance applies to identity migration decisions affecting risk. |
Assess protocol migration as a managed risk decision with documented accountability and change control.
