Which SOC 2 criteria cover identity and access management?

Mostly the CC6 series (logical and physical access controls) in the AICPA 2017 Trust Services Criteria: CC6.1 logical access security, CC6.2 registering, authorizing and removing users, CC6.3 role-based authorization with least privilege and segregation of duties, CC6.6 protection against threats from outside system boundaries, CC6.7 restrictions on moving information, and CC6.8 malicious software. Monitoring under CC7 usually supplies the detection evidence.

Does SOC 2 require MFA?

The criteria do not prescribe specific technologies. You define the controls that meet each criterion, and the auditor tests them. In practice MFA on production, administrative, and remote access is the control auditors expect to see for CC6.1 and CC6.6, and an undocumented MFA exception is a frequent finding.

How often do access reviews need to happen for SOC 2?

The criteria do not set a frequency. You set it in your control description and the auditor tests that you met it. Quarterly for production and privileged systems and at least annually for everything else is a common pattern, but whatever you write down is what you will be tested against.

What is the difference between a SOC 2 Type 1 and Type 2 report?

A Type 1 report covers the design of controls at a point in time. A Type 2 report adds testing of the operating effectiveness of those controls across a review period, which is where samples of joiners, leavers, and access reviews come in.

Are the SOC 2 criteria changing?

The AICPA published exposure drafts of proposed 2027 Trust Services Criteria on October 28, 2026, with comments due January 15, 2027. If approved, they would apply to engagements beginning on or after December 31, 2027, with early adoption permitted. Until then, examinations use the 2017 criteria with revised points of focus (2022).

SOC 2 for identity: the controls that actually matter

SOC 2 tests the controls you define against the AICPA Trust Services Criteria, and for identity almost all of the testing lands in the CC6 series on logical access. The criteria are not prescriptive: they say what must be achieved (only authorized users get access, access is removed when no longer authorized, privileges follow least privilege), and your control description says how. The auditor then samples real joiners, leavers, access reviews, and admin actions to see whether you did what you wrote. This guide maps the identity criteria to concrete controls and the evidence each one needs. See SOC 2 for the short definition.

What the criteria are and what is changing

SOC 2 examinations report on controls relevant to security, availability, processing integrity, confidentiality, or privacy, using the 2017 Trust Services Criteria (with revised points of focus, 2022) issued by the AICPA's Assurance Services Executive Committee. The full criteria text is a free download that requires an AICPA account. The identity controls sit in the common criteria (CC), mainly CC6.

A Type 1 report covers control design; a Type 2 report adds operating effectiveness across a review period, which means sampled evidence.

What changed in 2026: on October 28, 2026 the AICPA proposed updated 2027 criteria, with comments due January 15, 2027 and a proposed effective date for engagements beginning on or after December 31, 2027 (early adoption permitted). The draft consolidates duplicative concepts, removes and adds criteria, and adds points of focus on AI governance, prompt manipulation, and data poisoning. The announcement does not describe specific CC6 changes, so plan against the 2017 criteria for now.

The identity criteria, mapped to controls

Criterion (topic)	Control you define	Evidence the auditor samples
CC6.1 Logical access security over protected assets	SSO through one IdP, MFA on production and admin access, asset inventory	IdP policy export, MFA enforcement report, app inventory
CC6.2 Register and authorize users before issuing credentials; remove access when no longer authorized	HR-driven joiner and leaver flows, SCIM deprovisioning, defined revoke window	Joiner tickets with approval, leaver sample with time-to-revoke
CC6.3 Authorize, modify, remove access based on roles, least privilege, segregation of duties	Role catalog, mover workflow, SoD rules, periodic access review	Review campaigns with revocations, SoD conflict report
CC6.6 Protect against threats from outside system boundaries	MFA on remote access, conditional access, IP or device restrictions for admin consoles	Conditional access policies, VPN and ZTNA config
CC6.7 Restrict transmission and movement of information to authorized users	Scoped API tokens, OAuth app governance, data export restrictions	Token inventory, third-party app approvals
CC6.8 Prevent or detect unauthorized or malicious software	Endpoint controls on admin workstations	EDR coverage on privileged devices
CC7 monitoring (supporting)	Alerting on admin role changes, impossible travel, MFA resets	Alert rules, sample investigations

CC6.4 and CC6.5 cover physical access and disposal of assets; they matter to identity only through badge systems and device wipe on termination.

Decisions you have to write down

The criteria leave these to you. Whatever you choose becomes the bar the auditor tests.

Decision	Common choice	Trade-off
Revoke window for terminations	Same business day for involuntary, 24 hours for voluntary	Tighter windows need HR-to-IdP automation, not tickets
Access review frequency	Quarterly for production and privileged, annual for the rest	More frequent reviews are only credible if tooling generates them
MFA scope	All workforce SSO, mandatory phishing-resistant for admins	Exceptions must be listed, justified, and reviewed
Privileged access model	Just-in-time elevation through PAM	Standing admin is easier to run and harder to defend
Service accounts and API keys	Owner per credential, rotation schedule, inventory	Usually the weakest control in the population

Step-by-step: building audit-ready identity controls

Consolidate authentication. Put every in-scope app behind one IdP such as Okta or Microsoft Entra ID. Apps outside SSO need their own evidence, so the list should be short.
Wire HR as the source of truth. Joiner and leaver events from the HRIS drive account creation and disablement through SCIM. Write down the revoke window.
Enforce MFA and log exceptions. Export the policy and an exceptions register with owner and expiry. Prefer phishing-resistant MFA for admins.
Define roles and run reviews in a tool. Use an IGA platform such as SailPoint or ConductorOne, or your IdP's review feature. Evidence must show reviewer, decision, and the resulting revocation. See access certification.
Remove standing admin. Route production and cloud admin through just-in-time access with approval and expiry. See zero standing privileges.
Inventory non-human credentials. Every API key, service account, and OAuth app gets an owner and a rotation date. See service account.
Retain logs for the full review period. Sign-ins, admin changes, and MFA resets must be exportable for any date in the window.
Document one page per control. Name the criterion, the control, the owner, the frequency, and the evidence source.

Common failure modes, and the incidents behind them

Leavers who keep access. A former employee downloaded customer reports after leaving in the Cash App incident, and a departing engineer's still-valid token copied about 170 private repositories at CrowdSec. Both are CC6.2 failures. Technique: orphaned account abuse.
Movers who accumulate rights. Reviews that only confirm and never revoke miss mover entitlement accumulation, a CC6.3 gap.
MFA gaps on customer-managed accounts. In the Snowflake customer campaign, affected accounts lacked MFA and had not rotated credentials stolen by infostealers.
Help desk resets as the bypass. The MGM Resorts intrusion began with a help desk call. Your MFA reset procedure is part of CC6.2. Technique: help desk social engineering.
Subservice and vendor access. In the Okta and Sitel incident, access came through a support subprocessor's workstation. Carve-out subservice organizations still need complementary controls on your side.
Spreadsheet reviews. Auditors cannot tie a spreadsheet to what changed in the system.
Static secrets. Long-lived keys in repositories fail CC6.1 and CC6.7. Technique: secrets in repositories and CI.

The pragmatic path for a first audit

If you are pre-SOC 2, pick an IdP and review tool that can produce the evidence above, connect HR-driven joiner and leaver flows from day one, and run a review on schedule even at 20 employees. The Type 2 sample will show whether the process holds. For the wider evidence workflow, see the identity audit preparation guide and, for overlapping frameworks, identity controls for ISO 27001.