Skip to main content
Comply Defense
Category: Identity & Access Management

Single Sign-On

Also known as:
Simply put

Single sign-on (SSO) is an authentication method that lets a user log in once with a single set of credentials and then access multiple applications and websites without signing in again for each one. Instead of remembering and entering separate credentials for every system, the user authenticates a single time. This is intended to simplify the login experience across related but independent software systems.

Formal definition

Single sign-on (SSO) is an authentication scheme in which a user establishes identity through a single authentication event and is thereby granted access to multiple related yet independent applications, websites, or software systems using one set of credentials. In typical implementations, SSO relies on a trust relationship between the applications (relying parties) and a central identity provider that performs the authentication and asserts the user's identity to each connected system. Note that this evidence packet describes SSO at a general conceptual level and does not address specific federation protocols, assurance levels, or the assessment and authorization requirements applicable to CUI, DoD RMF, or FISMA systems; readers should verify implementation and control-mapping details against current authoritative sources.

Why it matters

Single sign-on directly shapes the security posture of any organization that operates across multiple applications, because it centralizes the point at which a user's identity is established. When authentication is consolidated into a single event, the credentials and the identity provider that back that event become high-value targets: a compromise at that central point can, in principle, cascade access to every connected relying party. For defense and public sector environments, this concentration of trust makes the governance of the underlying authentication process, and its mapping to applicable identity and access controls, a matter of careful scrutiny rather than convenience alone.

At the same time, SSO can support security objectives by reducing the number of separate credentials users must create and manage, which generally lessens the burden of password reuse and credential sprawl across independent systems. Because SSO relies on a trust relationship between connected applications and a central identity provider, the strength of the overall arrangement depends on how that trust is established and protected. It is important to distinguish SSO as an authentication convenience from the broader assurance requirements that govern access to sensitive information; using SSO does not by itself satisfy control or authorization obligations.

Readers should note that this evidence packet describes SSO at a general conceptual level. It does not address the specific federation protocols, identity assurance levels, multifactor requirements, or the assessment and authorization requirements that may apply to systems handling Controlled Unclassified Information, DoD systems under the RMF, or civilian agency systems under FISMA. Whether and how SSO can be deployed in a given environment, and how it maps to applicable controls, must be verified against current authoritative sources and any agency-specific tailoring.

Who it's relevant to

Information System Security Managers and IAM Practitioners
Those responsible for identity and access management need to understand SSO because it centralizes authentication and therefore concentrates trust in a single identity provider. They should evaluate how the trust relationship between relying parties and the identity provider is established and protected, and confirm, against current authoritative sources, how any SSO deployment maps to applicable identity and access controls rather than assuming the convenience of single-event login satisfies control requirements.
Compliance Officers and Auditors
Compliance and audit personnel should recognize that SSO is an authentication method, not a compliance outcome. Deploying SSO does not by itself demonstrate that assurance-level, multifactor, or authorization obligations are met. This evidence packet does not address the assessment and authorization requirements applicable to CUI, DoD RMF, or FISMA systems, so reviewers should verify how a specific SSO implementation is evaluated under the governing requirements for their environment.
Government Contractors and System Owners
Organizations operating across multiple applications may consider SSO to reduce credential sprawl and simplify the login experience for users. However, system owners should confirm whether SSO is permissible and how it must be configured for systems that handle sensitive information, since federation protocols, assurance levels, and control-mapping details are outside the scope of this evidence packet and may differ by agency, information type, and applicable regime.

Inside SSO

Identity Provider (IdP)
The authoritative service that authenticates a user once and issues assertions or tokens that relying services trust, forming the trust anchor of an SSO deployment.
Service Provider / Relying Party
The application or system that consumes authentication assertions from the IdP rather than authenticating the user directly, granting access based on the trusted token.
Federation Protocols
Standards such as SAML, OpenID Connect, and OAuth 2.0 that define how authentication assertions and authorization tokens are exchanged between the IdP and relying parties. Specific protocol suitability depends on the environment and should be confirmed against current implementation guidance.
Authentication Token / Assertion
The signed artifact passed from the IdP to a relying service that conveys the user's authenticated identity and session attributes, generally time-limited and validated by the receiving service.
Session Management
The mechanisms governing session establishment, lifetime, timeout, and termination across the SSO domain, which affect the scope of access granted after a single authentication event.
Relationship to Multi-Factor Authentication (MFA)
SSO addresses how authentication is shared across services, not the strength of the authentication itself; MFA is generally layered at the IdP to satisfy authenticator assurance requirements. Applicable requirements vary by system categorization and the relevant control baseline.

Common questions

Answers to the questions practitioners most commonly ask about SSO.

Does implementing SSO by itself satisfy identity and access management control requirements?
No. SSO is an authentication and access convenience mechanism, not a complete compliance solution. Control frameworks such as NIST SP 800-53 and the CUI requirements in NIST SP 800-171 address a broad set of identification and authentication, access control, and audit objectives that SSO alone does not fully satisfy. SSO can support several of these objectives, but implementers should map their SSO deployment against the applicable controls and baselines and verify coverage rather than assume that deploying SSO closes those control requirements. Confirm the specific control mapping against the current authoritative publication and any agency tailoring.
Is SSO the same thing as multi-factor authentication (MFA)?
No. SSO and MFA address different problems and are frequently combined rather than being interchangeable. SSO governs how a user authenticates once and gains access to multiple applications or services, while MFA governs the strength of the authentication event by requiring multiple factors. An SSO deployment may or may not enforce MFA, and enforcing MFA does not by itself provide single sign-on. Where a requirement calls for multi-factor authentication, implementers should confirm that MFA is actually enforced at the appropriate points and not assume that the presence of SSO satisfies it. Verify factor and authenticator requirements against the applicable guidance and any assurance-level expectations.
How should audit logging be handled across systems federated through SSO?
In most implementations, both the SSO identity provider and the individual relying applications generate audit records, and organizations generally need to capture and correlate events from both to reconstruct user activity. Relying solely on identity provider logs can leave gaps in application-level actions, while relying only on application logs can obscure the authentication context. Implementers should confirm which events are logged at each layer, whether records can be correlated to a single identity, and how retention and protection requirements apply, consistent with the applicable audit and accountability controls and any agency-specific requirements.
What happens to access continuity if the SSO identity provider becomes unavailable?
Because SSO centralizes authentication, the availability of the identity provider can become a single point of failure for access to connected systems. Implementers commonly consider availability, redundancy, and contingency measures for the identity provider, as well as documented procedures for access during an outage. The appropriate design depends on the criticality and impact level of the systems involved and on any continuity requirements in the applicable framework. Organizations should evaluate this against their own risk determination and confirm expectations with their authorizing official where relevant.
How should account provisioning and deprovisioning be managed in an SSO environment?
SSO centralizes authentication but does not by itself guarantee that account lifecycle actions propagate correctly to every connected application. Implementers generally need to confirm that creating, modifying, and disabling identities in the identity provider produces the intended effect across relying systems, so that removed or changed access is enforced promptly. Timely deprovisioning is particularly important for separated or reassigned personnel. Organizations should verify these behaviors against the applicable access control requirements and their own procedures rather than assuming propagation is automatic and complete.
Does an SSO deployment inherit the authorization status of the identity provider it federates with?
Not automatically. Authorization decisions apply to defined system boundaries, and connecting to or federating with an authorized identity provider does not by itself extend that authorization to the relying systems or to the overall SSO architecture. Assessment and authorization are distinct activities, and an Authority to Operate is time-bound and subject to continuous monitoring. Implementers should confirm how the SSO components fit within the relevant authorization boundary, what inheritance is actually documented, and what remains the responsibility of each system owner, verifying these determinations with the responsible authorizing official.

Common misconceptions

SSO is a security control that inherently makes systems more secure.
SSO is primarily an authentication convenience and centralization mechanism; it can reduce credential sprawl but also concentrates risk in the IdP. Its security value depends on the strength of authentication (for example MFA), session controls, and monitoring configured around it. Compliance with an access control requirement is not automatically satisfied by deploying SSO.
A single successful SSO login grants indefinite access to all connected services.
Assertions and sessions are generally time-limited and subject to timeout and re-authentication policies. Access scope should be governed by session management and authorization controls, and continuous verification remains appropriate rather than treating one authentication event as permanent trust.
Choosing any federation protocol satisfies applicable requirements equally.
SAML, OpenID Connect, and OAuth 2.0 serve different purposes and have different security properties. Suitability depends on the environment and the applicable control baseline or agency tailoring, which the reader should verify against current authoritative guidance.

Best practices

Enforce multi-factor authentication at the identity provider so that centralizing authentication does not weaken authenticator assurance for the connected services.
Configure and enforce session lifetime, idle timeout, and re-authentication policies rather than relying on a single login to persist access indefinitely.
Harden and monitor the identity provider as a high-value asset, recognizing that SSO concentrates authentication risk into a single trust anchor.
Select federation protocols (SAML, OpenID Connect, OAuth 2.0) based on the specific use case and confirm suitability against the applicable control baseline and current implementation guidance.
Log and monitor authentication events across the SSO domain to support continuous monitoring and detection, and confirm the specific logging expectations against the applicable requirements for the system.
Verify that SSO configuration is mapped to the relevant access control requirements for the system's categorization, and confirm any agency-specific tailoring against current authoritative sources rather than assuming SSO alone satisfies a control.