When we built Tenurex's evidence collection integrations, identity providers were the first source we connected — not because they were technically easy (they weren't), but because identity provider configuration generates more SOC 2 findings than any other single source in the Common Criteria stack.
The CC6 cluster — Logical and Physical Access Controls — is where most Type II audits spend the most time. And within CC6, the identity layer (how users authenticate, what they can access, how access is provisioned and revoked) is where gaps are most common, because identity configurations change frequently, aren't always owned by a single person, and are easy to misconfigure during SSO integrations or onboarding of new services.
This post covers the specific IdP controls that auditors test, what evidence is acceptable, and what "continuous monitoring" means for identity specifically — as opposed to once-a-quarter manual checks.
The Core IdP Controls Under SOC 2 CC6
MFA enforcement across user population (CC6.1, CC6.6). The auditor wants to verify that multi-factor authentication is technically enforced — not just available or recommended — for all users with access to production systems and administrative interfaces. The evidence is typically an IdP configuration export showing enforcement policy, plus confirmation that the enforcement applies to all applications in scope.
The gap that comes up repeatedly: MFA is enforced at the IdP level for SSO applications, but direct-access credentials to cloud consoles or database management tools bypass SSO entirely and have no MFA requirement. The auditor asks: "are there any access paths to production systems that don't go through your IdP?" If the answer is yes and those paths are unmonitored, that's a finding regardless of how well your SSO MFA is configured.
Password policy configuration (CC6.1). Minimum length, complexity requirements, and prohibition on commonly breached passwords. For IdPs that support breach-detection features (checking new passwords against known breached credential databases), enabling that feature is increasingly expected rather than optional.
The evidence format: an IdP policy configuration export or screenshot showing the specific password policy settings. Not a policy document saying "we require strong passwords" — actual configuration state showing what the IdP enforces.
Session management and idle timeout (CC6.1). Session duration limits and idle timeout policies prevent authenticated sessions from remaining valid indefinitely. The standard for production system access is typically 8-hour session duration with 30-minute idle timeout for administrative access. For end-user application access, longer sessions are acceptable but should still have defined limits.
Privileged access management (CC6.3, CC6.8). Privileged accounts — those with administrative access to production infrastructure, database root access, or security configuration rights — require separate monitoring from standard user accounts. The auditor looks for: a defined list of privileged accounts, evidence that privileged access is used only when needed (not as a default daily account), and monitoring of privileged account activity.
Provisioning and Deprovisioning: Where the Gaps Accumulate
CC6.2 requires that the organization registers and authorizes new users prior to issuing credentials. CC6.3 requires that access is removed when it's no longer authorized. In practice, these two requirements together mean you need a fully documented joiner-mover-leaver process tied to your IdP.
The provisioning side is usually better maintained than deprovisioning. When someone joins, there's a natural forcing function: they need access to do their job, so someone is motivated to set it up. When someone leaves, the forcing function is weaker, especially for contractors, interns, or part-time contributors whose offboarding may not go through the same formal HR process as a full-time employee.
A scenario that illustrates the pattern: a B2B analytics SaaS at roughly $4M ARR, fifteen employees. They were twelve months into their first Type II audit period. Their IdP had 89 active user accounts. Their current employee and contractor roster had 71 people. The eighteen-account discrepancy was a mix of former contractors whose IdP accounts had never been deprovisioned, shared service accounts that had been created for integrations and never documented, and two accounts for people who'd transitioned to a different role and retained access to systems from their previous role. None of these were active attacks. All of them were CC6.3 findings.
The evidence that satisfies CC6.3 isn't just that deprovisioning happened — it's that it happened within a defined timeframe. The industry standard is 24 hours for involuntary terminations (fired, contract ended) and five business days for voluntary departures. If your offboarding process relies on an IT ticket that gets created manually when HR notifies the team, the audit question is: was that ticket created and completed within the required window for every departure in the audit period?
SSO Coverage: Which Applications Are and Aren't Federated
Modern identity programs centralize authentication through an IdP via SAML 2.0 or OIDC federation. But most companies have applications that don't support SSO — legacy internal tools, some category of SaaS, infrastructure management interfaces. The auditor will ask for a list of all applications with access to production systems or customer data, and for each one: is it federated through your IdP, or does it use local credentials?
For non-federated applications, the auditor wants to see: are those applications covered by a separate access review process? Are the credentials stored in a secrets manager rather than in plaintext configs or individual engineers' password managers? Are MFA requirements enforced at the application level even without IdP federation?
We're not saying every internal tool needs to be SAML-federated. That's often not practical, especially for smaller infrastructure tools. What's required is that non-federated applications are inventoried, that access is reviewed periodically, and that the access review covers both the user list and the credential storage method.
Azure AD / Entra-Specific Evidence Artifacts
For teams using Microsoft Entra ID (formerly Azure AD), the evidence artifacts that auditors commonly request include:
- Conditional Access Policy export showing MFA enforcement rules and scope
- User sign-in logs for sampled dates in the audit period (auditors typically sample three to five specific dates)
- Privileged Identity Management (PIM) configuration showing just-in-time activation requirements for privileged roles
- Access review results from the Entra ID Access Reviews feature, if used
- Registered application list with OAuth permissions scope for each application
The PIM evidence point is worth calling out specifically. Auditors reviewing CC6.8 (infrastructure protection) increasingly ask whether privileged role assignments in Entra are permanent or time-bound. Standing administrative assignments where a Global Administrator role is permanently assigned to a user's daily account is a finding in some audit firms' practice — they expect PIM or equivalent just-in-time elevation even if the TSC language doesn't explicitly require it.
What Continuous Monitoring Means for Identity
A quarterly access review answers the question "is the user list appropriate as of this quarter?" It doesn't answer the question "was the user list appropriate on every day of the audit period?"
The difference matters because configuration can change between reviews. A new IdP application gets registered without going through the standard provisioning process. A contractor's account gets reactivated for a new engagement without a formal provisioning ticket. An MFA bypass exception gets created for a service account and never expires.
Continuous monitoring of your IdP means the evidence of current configuration state is collected on a regular cadence — daily or multiple times per day — not just when a quarterly review is scheduled. When the auditor asks for evidence that MFA was enforced on October 14th, the answer comes from a logged configuration check from that date, not from a reconstruction based on a quarterly review that happened to fall two weeks later.
For identity specifically, the controls we monitor continuously in Tenurex include: MFA enforcement status across all users, session timeout policy configuration, privileged account count and assignment status, and SSO federation coverage for applications in scope. When any of those drift from expected state, the gap surfaces before the quarterly review cycle, not after.