How can organisations reduce risk when both SAML and OIDC are in use?

Why This Matters for Security Teams

When SAML and OIDC coexist, the risk is rarely the protocols themselves. The risk comes from inconsistent trust decisions: different token lifetimes, different claim sets, different audience rules, and different assumptions about who or what is being authenticated. That mismatch can create gaps in provisioning, offboarding, and monitoring, especially when non-human identities rely on federated access into SaaS, CI/CD, and internal apps. NHI management guidance from the Ultimate Guide to NHIs — Key Challenges and Risks is clear: excess privilege and weak visibility are common, and federation can amplify both if controls are not normalised. The most useful external baseline is NIST Cybersecurity Framework 2.0, which reinforces that identity governance must be consistent across systems, not fragmented by protocol. In practice, many security teams discover federation drift only after a stale account, overbroad claim, or misrouted token has already been used in production.

How It Works in Practice

The practical goal is to make SAML and OIDC behave like two transport options for the same identity policy, not two separate security models. Start by defining which application types use which protocol. For example, legacy workforce apps may remain on SAML, while modern services, APIs, and machine-to-machine workflows move to OIDC. Then standardise validation rules so every relying party checks issuer, audience, subject, signature, expiry, and intended use in a consistent way. Claims should be minimal and purpose-bound. If a claim is not needed for authorisation, it should not be issued. For NHI-heavy environments, align these protocol decisions with lifecycle controls: provisioning, rotation, offboarding, and monitoring. The Top 10 NHI Issues page highlights how frequently credentials are overexposed or left active too long, and that problem grows when federation rules differ between stacks. The Ultimate Guide to NHIs — Why NHI Security Matters Now also notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which makes inconsistency at scale especially dangerous. A workable pattern is:

• Use one policy baseline for acceptable claims, regardless of protocol.
• Map each app to one preferred protocol and document exceptions.
• Apply shorter token and assertion lifetimes where operationally possible.
• Log protocol, issuer, subject, and claim diffs for review and detection.
• Revoke or rotate credentials when an identity changes role, owner, or purpose.

This guidance tends to break down in environments with many custom integrations because legacy apps often cannot enforce modern audience and expiry checks consistently.

Common Variations and Edge Cases

Tighter federation policy often increases migration and support overhead, requiring organisations to balance standardisation against application compatibility. Some teams keep SAML for workforce SSO and OIDC for API access, which is reasonable, but current guidance suggests the control objective should still be the same: verify the identity, minimise the claims, and reduce the standing trust each protocol grants. There is no universal standard for this yet, so the safe approach is to treat any protocol-specific exception as a compensating control decision, not as a permanent design shortcut. The biggest edge case is machine and agentic access. If an AI agent, service account, or workload can request tokens autonomously, static RBAC alone is not enough; intent-based authorisation, short-lived secrets, and workload identity become more important than the protocol label. In those cases, OIDC may be the better fit for modern workloads, but SAML can still appear at the human control plane. The security issue is not “SAML versus OIDC”; it is whether both are tied to the same review, offboarding, and anomaly detection process. For additional protocol-aware governance, the OWASP NHI Top 10 is useful when autonomous workloads enter the picture, while NIST Cybersecurity Framework 2.0 helps anchor the operational controls. In practice, mixed SAML and OIDC estates fail when teams assume the identity provider is the control boundary instead of the application and workload policy that sits behind it.

Related resources from NHI Mgmt Group

• When should organisations use CIEM to reduce risk?
• How can organisations reduce risk from certificate sprawl and stale trust?
• How can organisations reduce risk from shared privileged accounts?
• When should organisations treat an NHI as a high-priority risk?