Customer-managed SSO is a model in which a SaaS application delegates user authentication to the customer’s identity provider. The SaaS still has governance responsibilities, including setup validation, minimum assurance enforcement, and lifecycle visibility through provisioning or deprovisioning signals.
Expanded Definition
Customer-managed SSO is a federation model in which a SaaS application trusts the customer’s identity provider for primary authentication, while the SaaS retains control over application-side governance decisions such as tenant setup, minimum assurance checks, and account lifecycle handling. In practice, it sits between simple delegated login and full identity outsourcing, because the application must still validate configuration, enforce session and claim requirements, and track who can still access the tenant after a user leaves the customer directory. Guidance varies across vendors on how much assurance belongs in the IdP versus the SaaS layer, so the operational boundary should be documented explicitly. For governance teams, the relevant question is not only whether SSO works, but whether the SaaS can prove that access is tied to a current, authoritative identity source and that deprovisioning signals are honored quickly. This aligns closely with the lifecycle and visibility emphasis in the Ultimate Guide to NHIs and the control thinking in NIST Cybersecurity Framework 2.0. The most common misapplication is treating customer-managed SSO as a complete access control solution when the SaaS tenant still has orphaned accounts, stale group mappings, or unenforced assurance requirements.
Examples and Use Cases
Implementing customer-managed SSO rigorously often introduces onboarding and validation overhead, requiring organisations to weigh tenant autonomy against the cost of misconfiguration and delayed offboarding.
- A B2B SaaS platform requires each customer to connect Microsoft Entra ID, Okta, or another IdP, then validates SAML assertions, group claims, and enforced MFA before enabling production access.
- An enterprise customer uses SSO to centralise employee authentication, but the SaaS also requires SCIM provisioning so that joiner, mover, and leaver events are reflected in application access without manual tickets.
- A regulated customer asks for step-up assurance on admin actions, so the SaaS checks authentication context and rejects sessions that do not meet the tenant’s policy baseline.
- A security team reviews the SaaS tenant after an audit and compares active accounts with current IdP membership, using the lifecycle approach described in the NHI Lifecycle Management Guide.
- A shared workspace product supports customer-managed SSO but still logs authentication failures, group sync drift, and admin changes for investigation under the Top 10 NHI Issues.
In identity federation design, vendor guidance and customer policy often diverge, so implementation teams should align the SaaS configuration with the IdP’s documented assurance model and the customer’s retention and deprovisioning requirements.
Why It Matters in NHI Security
Customer-managed SSO matters because NHI governance failures frequently start with trust assumptions that are too broad. A SaaS may authenticate users through the customer IdP and still accumulate excessive access paths through stale sessions, inactive group grants, or admin exceptions that survive directory changes. The same pattern appears in NHI environments when identity governance exists on paper but not in operational enforcement. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which illustrates how often identity state lags behind reality and why SSO visibility must include provisioning and deprovisioning checks, not just login success. For auditability, the SaaS should be able to show which accounts were created, why they remain active, and what signal disables them when the customer removes access. The governance expectations described in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives and the identity controls in NIST Cybersecurity Framework 2.0 both point to the same operational truth: authentication delegation does not remove the SaaS provider’s responsibility for control evidence. Organisations typically encounter the consequences only after a departed user still has tenant access, at which point customer-managed SSO becomes operationally unavoidable to fix.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Focuses on identities, credentials, and access enforcement across systems. |
| NIST SP 800-63 | IAL2 | Defines identity proofing and assurance concepts relevant to delegated authentication. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Emphasises lifecycle visibility and governance for identities used by applications. |
Track provisioning, deprovisioning, and tenant access evidence so SSO does not hide stale access.
Related resources from NHI Mgmt Group
- What breaks when customer-owned API keys are not lifecycle-managed?
- What are cloud managed identities and how do they help NHI security?
- How do third-party SaaS integrations create NHI risk and how should they be managed?
- What is the difference between managed identities and hardcoded secrets for AI agents?
