Category: Identity & Access Management
Single Sign-On
Also known as: SSO, Single Sign On, SSO authentication
Simply put
Single Sign-On (SSO) is a login method that lets a user sign in once with one set of credentials and then access multiple applications and websites without logging in again for each one. Instead of remembering separate usernames and passwords for every system, the user authenticates a single time to reach several related but independent services.
Formal definition
Single Sign-On (SSO) is an authentication scheme that allows a user to authenticate once with a single identity and set of credentials to gain access to multiple related yet independent software systems, applications, and websites. It centralizes authentication so that a single sign-in event establishes access across the applications configured to trust that identity, reducing the number of separate credential prompts a user encounters across connected systems.
Why it matters
Single Sign-On sits at the center of how organizations manage identity and access, which makes it a high-value control and a high-value target at the same time. By reducing the number of separate credentials a user must manage, SSO can lower password fatigue and the risky habits it produces, such as reused or weak passwords across many systems. It also gives an organization a central point through which access to multiple connected applications can be granted, monitored, and revoked, which is why it is often a foundational element of an identity and access management strategy rather than a standalone convenience feature.
Who it's relevant to
Security and IT leaders
For those responsible for identity and access management, SSO is often a foundational capability because it centralizes authentication and gives a single point through which access across connected applications can be established. A virtual or fractional CISO engaged in this area would typically advise on how SSO fits into the broader identity strategy and governance rather than administering the tooling directly, with the client organization retaining accountability for how access is granted and controlled.
Application and platform owners
Teams that own individual applications need to understand that SSO connects related yet independent systems through a shared trust in a central identity. Whether a given application participates in SSO, and how that trust is configured, may vary by provider and by the application, so scope and integration expectations should be defined explicitly.
End users and workforce
SSO directly affects the daily experience of users, who sign in once with one set of credentials and then reach multiple applications and websites without logging in again for each one. This can reduce the burden of managing separate passwords across many systems, which is one of the practical reasons organizations adopt it.
Inside SSO
Single Sign-On (SSO)
An authentication approach that allows a user to authenticate once and then access multiple applications or systems without re-entering credentials for each one. In plain terms, it reduces the number of separate logins a user must manage by establishing a single trusted authentication event that other services rely on.
Identity Provider (IdP)
The system that authenticates the user and issues trust assertions to connected applications. The IdP is the authoritative source of the authentication event; the applications that consume it delegate the login decision to this provider rather than validating credentials themselves.
Service Provider (SP) / Relying Party
The application or system that trusts the identity provider's assertion and grants access based on it. The service provider does not directly verify the user's credentials in an SSO flow; it accepts the token or assertion presented after authentication at the IdP.
Federation Protocols
The standards that enable the identity provider and service providers to exchange authentication and authorization information, commonly including SAML, OAuth, and OpenID Connect. The specific protocol used may vary by provider and application, and different applications may support different protocols.
Authentication vs. Authorization
SSO primarily addresses authentication, confirming who the user is. Authorization, which determines what the authenticated user is permitted to do within each application, is a distinct function that often depends on additional access controls and role definitions.
Governance and Scope Considerations for Security Leadership
SSO is typically addressed by a virtual CISO or fractional CISO at the level of strategy, policy, and risk governance, such as recommending SSO adoption, defining identity and access management principles, and aligning it with broader access control objectives. Hands-on configuration, administration, and operation of SSO tooling generally fall outside a typical vCISO scope unless explicitly contracted.
Common questions
Answers to the questions practitioners most commonly ask about SSO.
Does implementing SSO mean my organization no longer needs multi-factor authentication?
No. This is a common misconception. Single Sign-On consolidates authentication across multiple applications, but it does not by itself strengthen the underlying credential. In many deployments, SSO actually increases the importance of MFA, because a single compromised set of credentials can unlock access to every connected application. A virtual CISO typically advises that SSO and MFA be treated as complementary controls rather than substitutes, and that the primary authentication point be protected accordingly.
Is SSO the same thing as a password manager?
Not typically. A password manager stores and retrieves distinct credentials for each application, whereas SSO establishes a single authenticated identity that federated or integrated applications trust, often without a separate password per application. Conflating the two can lead to design errors. In advisory engagements, this distinction matters because the two approaches carry different trust models, failure modes, and governance implications, and the appropriate choice may vary by organizational maturity and application landscape.
What questions should we ask before selecting an SSO approach for our applications?
Common considerations include which applications support standards-based integration versus proprietary connectors, how legacy or unsupported applications will be handled, and where the identity provider will reside. A virtual CISO generally frames these as governance and risk questions rather than purely technical ones, and outcomes often depend on the organization's existing identity infrastructure, application portfolio, and stakeholder cooperation. Specific tooling decisions typically remain with the client's operational teams unless the engagement explicitly includes implementation support.
How does SSO affect our approach to offboarding users?
Centralizing authentication can simplify offboarding, since disabling a single identity may revoke access across connected applications. However, this benefit is often conditional. Applications that are not integrated with the SSO provider, or that retain local accounts, may still require separate deprovisioning. In many engagements a vCISO advises validating which systems are genuinely covered, so that assumptions about coverage do not create gaps. The design and testing of these processes typically fall to the client's operational teams.
What happens to access if the SSO provider becomes unavailable?
Because SSO concentrates authentication at a single point, its availability can affect access to many applications at once. Organizations often plan for this through documented fallback or emergency access procedures. A virtual CISO typically raises availability and resilience as governance concerns to be addressed during design, but the implementation, testing, and operational monitoring of any contingency arrangements generally remain the responsibility of the client organization unless explicitly contracted otherwise.
How should SSO fit into our broader security governance and compliance efforts?
SSO is often positioned within identity and access management governance rather than treated as a standalone project. It may support access control objectives referenced in frameworks and standards such as NIST CSF, ISO 27001, or SOC 2, but deploying SSO does not by itself demonstrate compliance or achieve certification. A virtual CISO typically helps map SSO to relevant control objectives and readiness efforts, while accountability for compliance decisions and any formal attestation remains with the client organization and its officers.
Common misconceptions
SSO is the same as multi-factor authentication (MFA) and eliminates the need for it.
SSO and MFA address different problems. SSO reduces the number of separate authentication events, while MFA strengthens the assurance of a single authentication event by requiring additional factors. In many engagements a security leader will recommend that SSO be paired with MFA, because concentrating access behind a single login can increase the impact if that login is compromised.
Implementing SSO makes an organization compliant with a framework or standard.
SSO can support access control objectives found in frameworks and standards, but it does not by itself confer compliance or certification. A virtual CISO can help position SSO as part of readiness efforts, though accountability for compliance decisions and the outcome of any audit or certification remains with the client organization.
A virtual CISO will deploy, configure, and run the SSO system.
A virtual CISO typically advises on whether and how SSO fits the organization's identity and access management strategy and risk posture, but does not usually perform hands-on tool administration or ongoing operation unless that work is explicitly included in the engagement scope. The value of this guidance often depends on organizational maturity, stakeholder access, and defined scope.
Best practices
Pair SSO with multi-factor authentication so that concentrating access behind a single authentication event does not become a single point of failure.
Clearly separate authentication from authorization, ensuring that access privileges within each connected application are governed by appropriate role and access controls rather than assumed from a successful login.
Define the SSO scope and engagement boundaries explicitly, distinguishing between strategic and governance guidance a vCISO typically provides and the hands-on configuration and operation that generally requires separate resources.
Position SSO as part of a broader identity and access management strategy rather than a standalone fix, and align it with the organization's documented access control objectives.
Treat framework and standard alignment as a readiness activity, describing how SSO supports access control objectives without asserting that it guarantees compliance or certification.
Keep legal and organizational accountability for SSO-related access decisions with the client organization and its officers, with the virtual CISO advising and directing rather than assuming that accountability.