IA-2(10): Single Sign-on

IA-2(10) requires you to provide a single sign-on (SSO) capability for the systems, applications, or services defined in your organization-defined parameter (ODP). To operationalize it quickly, pick an enterprise identity provider, standardize SSO protocols, onboard the in-scope apps, disable local logins where feasible, and retain tight evidence that users authenticate through the centralized identity service.

Key takeaways:

• Scope first: define exactly which apps/services must use SSO (your ODP), then enforce it consistently.
• Implement SSO as a control, not a convenience: require centralized authentication, reduce standalone credentials, and monitor exceptions.
• Evidence wins audits: keep SSO configs, app enrollment lists, exception approvals, and authentication logs mapped to IA-2(10).

The ia-2(10): single sign-on requirement is easy to “say yes” to and surprisingly easy to fail in an assessment. The failure mode is rarely technical; it’s scoping, exceptions, and missing proof that SSO is actually required and operating. IA-2(10) is an enhancement under NIST SP 800-53’s Identification and Authentication family. It expects a real SSO capability, meaning users authenticate through a centralized mechanism instead of collecting separate usernames and passwords per application.

The control statement is short, but implementation choices are not. You need to define what “for X” means in your environment (the organization-defined parameter), decide which identity provider is authoritative, pick the federation standards your applications must support, and set rules for when local authentication is allowed. You also need operating discipline: onboarding, offboarding, break-glass access, service accounts, third-party-managed apps, and legacy systems that cannot federate.

This page is written for a Compliance Officer, CCO, or GRC lead who needs requirement-level guidance: what the control means, who owns what, the steps to implement, and what auditors ask for.

Regulatory text

Control requirement (excerpt): “Provide a single sign-on capability for {{ insert: param, ia-02.10_odp }}.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator interpretation:
You must (1) define the scope captured by your organization-defined parameter (ODP), and (2) ensure users can authenticate once via an approved identity service to access that scoped set of resources without separate credentials per resource. The assessment focus is usually: “Show me which apps are in scope, show me they’re federated to your IdP, and show me you actually require SSO rather than merely offering it.” (NIST SP 800-53 Rev. 5)

Plain-English interpretation of the requirement

IA-2(10) means: users should sign in through one centralized identity system (your SSO/IdP) to access the in-scope applications and services. Practically, this reduces password sprawl, improves access control consistency, and makes authentication events visible in one place for monitoring and investigations.

SSO alone does not automatically mean “secure.” Auditors still expect strong authentication (often MFA elsewhere in the control set) and good access governance. IA-2(10) is about centralizing the act of authentication for the defined scope.

Who it applies to

Entity types

• Federal information systems
• Contractor systems handling federal data (NIST SP 800-53 Rev. 5)

Operational context (where this shows up in practice)

• Systems with multiple internal apps, SaaS tools, administrative consoles, developer platforms, and customer-support tools
• Environments where access must be removed quickly when people change roles or leave
• Organizations with third-party-hosted applications where local accounts tend to proliferate

Typical control ownership

• Control owner: IAM / Security Engineering (primary), with GRC as control manager
• Supporting owners: IT Operations (endpoints and directories), Application Owners (each app), HR (joiner/mover/leaver triggers), Third-party risk team (SaaS contract and integration requirements)

What you actually need to do (step-by-step)

Use this sequence to get IA-2(10) operating and auditable.

1) Define the organization-defined parameter (ODP) scope

Write down, in plain terms, what “for {{…}}” means for your environment. Common scoping patterns:

• All workforce-accessed SaaS applications
• All high-impact or moderate-impact systems
• All administrative interfaces (cloud consoles, CI/CD, support platforms)
• All remote access entry points (VPN/VDI/zero trust portals)

Deliverable: an “SSO in-scope services list” tied to system boundaries and owned by named application owners.

2) Select the authoritative identity provider and protocols

Decide the primary IdP and the federation patterns you will support across apps (for example, SAML/OIDC). The control does not dictate a brand; it expects a working capability.

Design decisions to document:

• The authoritative identity source (directory) and lifecycle process
• Federation standard(s) required for new apps
• How you handle apps that cannot federate (exception path)

3) Build an SSO onboarding standard for applications

Create a short, repeatable onboarding runbook. Minimum operational items:

• How an app is requested for SSO enablement
• Required attributes/claims (email, username, groups/roles)
• Group-to-role mapping standard
• Test procedure (positive authentication, denied access, session behavior)
• Change management and rollback steps

Tip for operators: treat each app as a mini-integration project with an owner, ticket trail, and a final “SSO required” setting flip.

4) Enforce “SSO required,” not “SSO available”

This is where many teams fail audits. If local login remains enabled, assessors may conclude SSO is optional. For each in-scope app:

• Configure the app to require federated login for standard users
• Disable local accounts where feasible
• Restrict any remaining local accounts to a small, approved break-glass population

If an app must retain local logins (legacy constraints, vendor limitation), document and approve the exception, then mitigate with monitoring and tight credential storage.

5) Integrate joiner/mover/leaver with SSO access

SSO becomes meaningful when deprovisioning is centralized:

• Ensure account provisioning and deprovisioning in the IdP drives app access (directly or via provisioning connectors)
• Ensure role/group changes are controlled and logged

6) Centralize logging and monitor exceptions

From an audit and incident-response standpoint, you need to show:

• Authentication events originate from the IdP for in-scope resources
• Exceptions are tracked and reviewed
• Break-glass access is rare and investigated

7) Operationalize third-party and vendor constraints

SSO often fails at the edges: third-party-managed platforms, contractors, support vendors, and acquired business units. Add to your third-party onboarding:

• SSO capability requirement in procurement/security review
• Integration responsibility (who configures what)
• Contractual expectation for standards support and audit logs (where feasible)

8) Map IA-2(10) to an owner and recurring evidence

Turn the control into a living requirement:

• Name the control owner and backups
• Define how often the in-scope list is reviewed
• Define what evidence is produced and where it’s stored

If you use a system like Daydream to run control ownership, reminders, and evidence collection, map IA-2(10) to the owner, the procedure, and recurring artifacts so audits become retrieval, not archeology.

Required evidence and artifacts to retain

Keep evidence that proves scope, enforcement, and operation:

Core artifacts (auditor-ready)

• ODP definition for IA-2(10) (what is in scope, what is out of scope, and why)
• In-scope application inventory with owners and SSO status (enabled/required/exception)
• SSO configuration evidence per key app (screenshots or exported settings showing federation and “SSO required” behavior)
• IdP configuration (tenant settings relevant to SSO, federation apps list)
• Exception register for apps/users that cannot use SSO, with approvals and compensating controls
• Break-glass procedure and named accounts, with access controls and usage review records
• Authentication logs from the IdP demonstrating sign-ins to in-scope apps (sampled evidence is common in practice)
• Change tickets for onboarding and enforcement changes

Evidence hygiene rules (what exam teams look for)

• Evidence is dated, attributable, and tied to the same scope statement used in your SSP/control narrative
• Exceptions are finite, reviewed, and signed off
• App owners confirm their apps’ authentication mode

Common exam/audit questions and hangups

Expect these questions in IA-2(10) testing:

1. What is your ODP for IA-2(10)? If you can’t state it crisply, the assessor can’t test it.
2. Show the list of in-scope apps and which ones require SSO. Inventory drift is a common finding.
3. Pick three critical apps and prove SSO is required. Assessors often sample.
4. What about admins and break-glass? If local admin accounts exist, show governance and monitoring.
5. How do contractors and third parties authenticate? If they bypass SSO, document why and how you control it.
6. What’s your exception process? “We haven’t gotten to it yet” reads as “not implemented.”

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	How to avoid it
“SSO is available” but local login still works	Requirement reads as “provide” SSO, and assessors often expect enforced use for in-scope resources	For each in-scope app, flip the setting to require federation; restrict locals to break-glass only
No clear ODP scope	Control becomes untestable and you cannot prove coverage	Write the scope definition and tie it to a system boundary and inventory
Shadow SaaS not federated	Users create separate credentials outside IdP governance	Add SSO requirement into procurement and SaaS intake; monitor for new apps
Exceptions handled in email/Slack	No durable evidence trail	Maintain an exception register with approvals and review cadence
Break-glass accounts unmanaged	High-risk credential sprawl	Document the procedure, restrict access, and review usage logs

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t anchor your program on assumed penalties. Your practical risk is operational: without enforced SSO, you increase the chance of unmanaged credentials, delayed deprovisioning, inconsistent authentication policy, and thin investigation logs across SaaS and internal apps. IA-2(10) reduces those failure modes by making authentication centralized and provable. (NIST SP 800-53 Rev. 5)

A practical 30/60/90-day execution plan

Use phases rather than hard time promises; actual duration depends on app count, legacy constraints, and ownership.

First 30 days (Immediate)

• Confirm the IA-2(10) ODP scope and publish the in-scope inventory.
• Identify the authoritative IdP and federation standards for the program.
• Select a small set of high-value apps and implement SSO end-to-end with “required” enforcement.
• Stand up an exceptions register and break-glass governance.

Days 31–60 (Near-term)

• Build the SSO onboarding runbook and make it part of app intake/procurement.
• Expand SSO to remaining in-scope SaaS and internal apps; track completion per app owner.
• Integrate joiner/mover/leaver triggers so deprovisioning flows through the IdP.
• Centralize and validate IdP sign-in logging for sampled apps.

Days 61–90 (Stabilize and prove operation)

• Reduce exceptions by remediating legacy blockers or replacing tools that cannot support SSO.
• Formalize periodic access and exception reviews for in-scope applications.
• Prepare an audit packet: scope statement, inventory, configs, samples of logs, and exception approvals.
• If you manage controls in Daydream, assign the IA-2(10) owner, attach the runbook, and schedule recurring evidence requests so the control stays assessment-ready.

Frequently Asked Questions

Does IA-2(10) require every system to use SSO?

No. The requirement is “provide a single sign-on capability for” your defined scope (the ODP). Your job is to define that scope clearly and apply SSO consistently to everything inside it. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Is SSO the same as MFA?

No. SSO centralizes authentication; MFA adds an additional factor. Many organizations pair them, but IA-2(10) is specifically about providing the SSO capability for the scoped resources. (NIST SP 800-53 Rev. 5)

What counts as evidence that SSO is “provided” and operating?

Auditors usually accept a combination of (1) a scoped app list, (2) app/IdP configuration proof showing federation, and (3) authentication logs showing sign-ins routed through the IdP for sampled apps.

How do we handle legacy applications that can’t support SSO?

Put them in an exception register with a business rationale, documented compensating controls, and a plan to remediate or replace. Also restrict local accounts and monitor authentication closely to avoid uncontrolled credential sprawl.

Can we keep local accounts for administrators?

Sometimes you must, but treat them as break-glass: limited membership, strong credential storage controls, documented use criteria, and log review. If local admin becomes the norm, assessors may judge SSO as not effectively implemented for that system.

What if a third-party-hosted SaaS tool won’t integrate with our IdP?

Decide whether the tool can be out of scope under your ODP, replaced, or accepted under a formal exception. If you accept the exception, document the risk and compensating controls and make the decision traceable to procurement/security governance.