Single sign-on allows a user to authenticate once with an identity provider and then access connected applications without repeated logins. In B2B SaaS, SSO is usually a first enterprise requirement because it ties application access to the customer’s identity stack and simplifies control for IT teams.
Expanded Definition
Single sign-on, or SSO, is an access pattern where one successful authentication session is reused across multiple applications through a trusted identity provider. In enterprise IAM, it reduces password fragmentation and centralises policy enforcement, but it is not the same as broad access governance. SSO answers NIST Cybersecurity Framework 2.0 questions about authenticating the session, while entitlement design, lifecycle controls, and privileged access still need separate governance.
In NHI environments, the term is often used more loosely than it should be. Teams sometimes describe token exchange, federated login, or app-to-app trust as SSO, even though the operational risk profile differs. That distinction matters because the control plane for a human user portal is not the same as the control plane for an API key, service account, or agent. The most common misapplication is treating SSO as a complete identity control, which occurs when organisations assume federation alone prevents overprivileged access or credential sprawl.
Examples and Use Cases
Implementing SSO rigorously often introduces dependency on a central identity provider, requiring organisations to weigh simpler user access against greater blast radius if that trust anchor is misconfigured or unavailable.
- Employees sign in once to a corporate portal and then open CRM, ticketing, and finance tools without separate passwords.
- Partners access a B2B SaaS tenant through their own identity provider using federation, so the vendor does not issue local accounts.
- Administrators combine SSO with phishing-resistant authentication and conditional access, but still enforce separate privileged workflows for sensitive actions.
- Security teams review whether the application uses SSO for humans while service accounts and API keys are governed separately, as described in the Ultimate Guide to NHIs.
- Development teams use SSO for console access, then issue short-lived workload credentials through external trust frameworks such as NIST Cybersecurity Framework 2.0 aligned controls for downstream systems.
Why It Matters in NHI Security
SSO becomes a security issue when teams assume human identity patterns also protect machine identities. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, and 79% have experienced secrets leaks, with 77% of those incidents causing tangible damage, according to Ultimate Guide to NHIs. That gap is why SSO programs must be paired with inventory, rotation, offboarding, and privilege reduction for non-human identities.
When SSO is poorly implemented, a compromise of the identity provider can cascade into many connected applications, and incomplete session design can leave stale access behind after a user or vendor relationship ends. Good governance also requires separating user authentication from service authentication so that automation, APIs, and agents are not hidden behind shared human login assumptions. Organisations typically encounter the operational cost of SSO only after a lockout, breach, or failed offboarding event, at which point the term becomes operationally unavoidable to address.
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 and CSA MAESTRO address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL2 | SSO depends on authenticator assurance for the initial login session. |
| NIST CSF 2.0 | PR.AA | Identity and access management covers federated authentication and session control. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification beyond a single login event. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | SSO does not replace controls for secrets, tokens, and machine identities. |
| CSA MAESTRO | Agentic workflows need distinct authentication and authorization boundaries. |
Set the SSO entry point to an assurance level that matches application risk and required phishing resistance.
