Is SSO Required for SOC 2 or HIPAA? What Auditors Actually Look For

Where the claim comes from

Identity, device management, and security vendors often describe SSO as a SOC 2 or HIPAA requirement. It is an easy thing to sell, because SSO really does make several controls easier to run. But it is a product recommendation, not a framework requirement. If a vendor tells you SSO is mandatory, ask which criterion or rule they are pointing to. There is not one that names it.

What SOC 2 actually asks for

The Trust Services Criteria address access mainly in CC6.1 through CC6.3. CC6.1 expects logical access security over protected information assets, and its points of focus say the entity identifies and authenticates users before they access those assets, using more advanced techniques such as multifactor authentication when that fits the entity's risk strategy. CC6.2 and CC6.3 cover registering and authorizing users before access is granted, and removing or changing access when it is no longer appropriate. None of the criteria names a specific tool.

SOC 2 has no checklist of mandatory controls or products. Your controls have to meet the criteria and match what you describe in your system description. In practice, auditors expect to see MFA on email, cloud and production access, source code repositories, and administrator accounts, whether or not SSO is in place.

What HIPAA actually asks for

The HIPAA Security Rule requires unique user identification and procedures to verify that a person seeking access to electronic protected health information is who they claim to be. It does not specify the technology. Proposed changes to the Security Rule that would tighten MFA expectations had not been finalized at the time of writing, so check the current status before relying on that point. Keep in mind that a SOC 2 report is not a HIPAA certification, and no such certification exists.

What changes if you skip SSO

Without SSO, each application has its own accounts, its own MFA setting, and its own offboarding step. We test each in-scope system separately, which means a user list, MFA configuration, termination evidence, and access review for every one. That is more evidence to collect and more places for a single miss. A former employee who is still active in one application is an exception for that control, even if everything else was clean.

With SSO, much of that evidence comes from one place, which is the real operational benefit. It does not remove all the work. Applications outside SSO, local administrator accounts, and anything that cannot be connected still need their own evidence.

How to think about the decision

Whether to implement SSO is a business decision about cost, setup time, team size, and how many applications you run. A small team with a handful of applications can operate clean manual controls. As the application count grows, manual access management gets harder to keep consistent.

For a Type II report, whatever you choose has to operate for the whole observation period, and your policies need to describe what you actually do. We describe what we would test. We do not choose tools or design controls for the companies we audit, because that would compromise our independence.

What to have ready if you do not use SSO

Expect to show that every person has a unique account in each in-scope system, that MFA is enforced on each of those systems, and that you keep a current list of applications with an owner for each. Expect to show that access is approved before it is granted, that it is removed within your stated timeframe when someone leaves with evidence of the removal, and that you review access to each system on a regular schedule and keep the results.

If you're weighing SSO before a SOC 2 or HIPAA engagement, Zero Day CPA can walk you through what evidence each approach will require.