Single sign-on is usually sold to engineers as convenience: one login, fewer passwords. For a compliance program it does something more useful. It turns a dozen separate access controls into one, run in one place, with one log.
That only holds for the applications actually behind it. Most companies have SSO on their important tools and a long tail of apps with their own logins, plus a few side doors on the important tools that nobody closed. The audit risk sits in that tail and those side doors.
This article covers what SSO does for your controls, why SSO without provisioning leaves accounts behind, how to sort your applications into tiers, how to protect the identity provider itself, and what an auditor will test.
What SSO does for your controls
No framework requires single sign-on by name. What the frameworks require is a set of outcomes that SSO makes much easier to deliver and evidence.
Unique identity. PCI DSS Requirement 8.2.1 requires a unique ID for every user, and the HIPAA Security Rule requires unique user identification at 45 CFR 164.312(a)(2)(i). With SSO, the identity provider account is that ID everywhere.
Consistent authentication. One place to enforce MFA and session rules. Enforcing MFA for every user covers the factor and coverage questions in detail.
Registration and removal. SOC 2 CC6.2 asks that users are registered and authorized before credentials are issued, and that credentials are removed when access is no longer authorized. ISO 27001:2022 Annex A 5.16 covers the full life cycle of identities. A single disable action in the identity provider is the cleanest version of removal there is.
One sign-in record. Authentication events for every federated app land in one log, with one clock and one format.
One population. When you run an access review, the identity provider's app assignments are the starting list, rather than a dozen exports in a dozen formats.
The trust services criteria behind CC6 are covered in the SOC 2 trust services criteria explained one by one. The point here is narrower: SSO is the mechanism that lets one control satisfy several criteria at once.
SSO is not provisioning
This is the misunderstanding that produces the most findings.
SAML and OpenID Connect handle authentication. They answer "is this person who they say they are, right now?" They do not create or delete the account inside the application. When you disable someone in the identity provider, they can no longer sign in through SSO. Their account in the application still exists.
That matters in three ways:
Side doors stay open. If the app also accepts a password, or the user created an API token, the disabled identity provider account does not stop either.
Sessions outlive the disable. An existing session may stay valid until it expires. Some apps issue sessions lasting days or weeks.
The population is wrong. The application's user list still shows the person as active, and an auditor sampling that list will ask why.
Provisioning protocols, usually SCIM, close this gap. They create, update and deactivate the account inside the app when the identity provider changes. Where an app supports SSO but not SCIM, you need a manual deprovisioning step in your leaver checklist for that app, and a record that it happened.
Sort your applications into tiers
You will not get every app behind SSO and SCIM, and an auditor does not expect you to. They expect you to know which apps are where and to have a control for each tier.
| Tier | Login | Removal | Evidence to keep |
|---|---|---|---|
| Federated and provisioned | SSO only, local login disabled | Automatic via provisioning | Provisioning logs, app user list matching identity provider assignments |
| Federated only | SSO, account persists in app | Manual step on the leaver checklist | Ticket or checklist entry per leaver, app user list |
| Not federated | Local username and password | Manual, owned by a named person | App-level MFA setting, user list, removal record per leaver |
Start with the inventory. List every application that holds customer data, touches production, or can change either. Note its tier and its owner. Then work on moving the high-risk apps up a tier.
Close the side doors
Putting an app behind SSO is half the job. The other half is removing the other ways in.
Local password login. Disable it for everyone except a documented break-glass account, where the app allows that. Many apps keep the owner's password login active by default.
Personal API tokens. Tokens tied to a user often survive the user being removed from SSO. Check whether the app revokes them on deprovisioning, and if not, add revocation to the leaver step.
Session lifetime. Set an idle timeout and a maximum session length that fit the data the app holds. Long sessions mean a disable takes effect late.
Invitation flows. Some apps let any member invite outside users by email, creating accounts that never touch the identity provider. Restrict invites or review guest accounts on a schedule.
Protect the identity provider itself
Once SSO is in place, the identity provider is the most valuable system you run. Compromise of an identity provider administrator is compromise of every federated app.
Treat it accordingly:
Keep the number of identity provider administrators small, and review the list on the same cadence as production access.
Require phishing-resistant MFA for those administrators.
Retain the identity provider's admin activity log, and alert on changes to authentication policies, new administrators, and new federated apps.
Keep a break-glass path that does not depend on the identity provider being available, and test it.
Expect your auditor to treat the identity provider as an in-scope system in its own right, with questions about who administers it and how changes to it are approved.
What an auditor will test
For an SSO-based access control, the testing usually follows this sequence.
Inventory. The list of in-scope applications, with each one's tier and owner.
Configuration. For a sample of federated apps, evidence that SSO is enforced and local login is disabled or restricted.
New users. For a sample of joiners, an approval before access was granted, and the identity provider assignment that followed.
Leavers. For a sample of leavers, the termination date compared with the disable time in the identity provider, and for federated-only and non-federated apps, the separate removal record.
Population checks. App user lists compared with identity provider assignments. Any account present in the app but not assigned in the identity provider needs an explanation.
The fourth and fifth steps are where SSO either pays for itself or exposes the gap. If the app user lists match, the control is easy to prove. If they do not, the mismatch is the finding.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the identity and application systems you connect and routes each failure to its owner, so gaps surface during the period rather than at audit. Its user access reviews record reviewer decisions where they are made, against populations pulled from those systems.