Security teams should choose the protocol that matches their architecture, trust model, and application mix. LDAP and Kerberos often fit internal or legacy environments, while SAML and OpenID Connect are more common for federated and modern web or mobile use cases. The right choice depends on interoperability, token handling, audit needs, and how much control the identity provider must retain.
Why This Matters for Security Teams
Choosing an SSO protocol is not just a compatibility decision. It shapes token lifetimes, auditability, trust boundaries, and how much control the identity provider retains across legacy, web, mobile, and service-to-service workloads. In mixed environments, the wrong choice often creates hidden exceptions: LDAP for one app, SAML for another, OIDC for a third, and bespoke exceptions for the rest. That fragmentation is exactly where policy drift, weak session handling, and inconsistent logging appear.
The practical issue is that SSO is only as strong as the least-governed application in the path. NHI Management Group has repeatedly shown how identity gaps become operational risk, including in incidents like the Schneider Electric credentials breach, where credential and access handling became part of the exposure surface. For broader identity governance context, the NIST Cybersecurity Framework 2.0 remains a useful baseline for access, governance, and monitoring expectations. In practice, many security teams discover protocol mismatch only after an integration has already forced an insecure workaround.
How It Works in Practice
A mixed application estate usually needs a protocol selection model, not a single universal standard. The first question is whether the app is human-facing, browser-based, mobile, legacy, or machine-accessing other systems. SAML is often strongest for enterprise browser SSO and assertion-based federation. OIDC is usually better for modern web and mobile applications because it is built on OAuth 2.0 patterns, is easier to consume in APIs, and generally handles token-centric architectures more naturally. LDAP and Kerberos can still be appropriate for internal directories, workstation authentication, and legacy applications that expect direct domain trust.
Security teams should evaluate each application against a short control set:
- Does the application support browser redirects, tokens, or only directory bind authentication?
- Does the identity provider need to preserve central session control or just assert identity?
- How will the app validate logout, token expiry, and revocation?
- What audit evidence is needed for sign-in, role assignment, and session termination?
- Will the protocol support MFA, conditional access, and future ZTA alignment?
For identity governance and downstream credential risk, NHI Management Group’s Ultimate Guide to NHIs is especially relevant because protocol choice also affects how service accounts, API keys, and automation tokens are issued and monitored. If a mixed environment includes service identities or automation, the protocol decision should not stop at humans. Current guidance suggests aligning SSO with NIST Cybersecurity Framework 2.0 functions for identity governance, access control, and continuous monitoring, while using protocol-specific controls to preserve least privilege and traceability. These controls tend to break down when a legacy application can only accept static directory binds but the organisation expects modern session revocation and auditable federated access.
Common Variations and Edge Cases
Tighter protocol standardisation often increases migration cost, requiring organisations to balance security consistency against application compatibility and delivery speed. There is no universal standard for every environment, so the right answer is often a hybrid with clear boundaries. For example, a legacy internal app may remain on LDAP or Kerberos while customer-facing or workforce applications move to SAML or OIDC. That said, the boundary must be explicit, documented, and monitored, or the environment gradually accumulates exceptions that are harder to govern than the original mixed estate.
Two edge cases deserve special attention. First, some applications advertise SSO support but only accept it through brittle plugins or custom gateways, which can obscure logging and complicate incident response. Second, protocol choice alone does not solve identity sprawl across non-human identities. If the environment also includes API-driven workflows, service accounts, or third-party integrations, teams should treat SSO as one part of a broader identity architecture rather than a complete control plane. The current guidance from NHI Management Group is to prefer the protocol that fits the app, but to enforce one common policy layer for session policy, MFA, audit export, and deprovisioning. That approach reflects the reality highlighted in the State of Non-Human Identity Security: identity programs often look stronger on paper than they are in practice, especially when visibility is incomplete and controls are unevenly applied.
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, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | SSO protocol choice affects how identities are authenticated and linked to access. |
| NIST SP 800-63 | IAL/AAL/FAL | Federation and assurance levels matter when selecting between SAML, OIDC, LDAP, and Kerberos. |
| NIST Zero Trust (SP 800-207) | PL-3 | Zero Trust requires identity-aware access decisions across heterogeneous application paths. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Mixed environments often include service accounts and API identities tied to SSO design. |
| NIST AI RMF | GOVERN | Identity decisions need governance, accountability, and documented risk tradeoffs. |
Inventory non-human identities affected by SSO and eliminate protocol-specific shadow accounts.
Related resources from NHI Mgmt Group
- How should security teams choose an SBOM generation tool for mixed build environments?
- How should security teams choose an API testing framework for mixed REST, GraphQL, SOAP, and gRPC environments?
- How should security teams choose a threat intelligence platform for cloud and application environments?
- How should security teams deploy phishing-resistant passkeys in regulated environments without relying on a cloud identity provider?
