Compliance & Privacy · 2026-03-29

SOC 2 Type II for Identity APIs: The Audit Controls Few Will Tell You About

By J. W. Bouckaert

SOC 2 Type II is not a checkbox

Most SOC 2 guidance stops at the Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy. That framing is accurate but insufficient for identity-layer APIs. An identity platform does not merely process data—it issues cryptographic assertions about who a person is, whether their device is compromised, and whether an AI agent is authorized to act on their behalf.

The difference between SOC 2 Type I and Type II is the difference between saying you have controls and proving they work over a sustained observation period—typically 6 to 12 months. Type I is a snapshot. Type II is a film. For identity APIs that process carrier signals, issue verifiable credentials, and manage passkey ceremonies, the film is what matters.

This article covers the specific audit controls that identity-layer APIs must implement to satisfy SOC 2 Type II requirements. These are the controls that generic compliance guides omit because they require domain-specific architectural decisions that most SaaS platforms never face.

The five control domains for identity APIs

SOC 2 maps to the AICPA Trust Service Criteria (TSC), but the criteria are deliberately abstract. An auditor evaluating an identity API needs to see concrete implementations across five domains:

Each of these domains requires architectural decisions that cannot be retrofitted without significant rework. The following sections detail how each control operates in a production identity API.

Control 1: Immutable audit logging

Auditor expectations

SOC 2 CC7.2 requires that the organization monitors system components and the operation of those components for anomalies. CC7.3 requires that detected events are evaluated to determine whether they constitute incidents. For an identity API, this means every signal ingest, credential issuance, key rotation, agent delegation, and administrative mutation must produce an audit record.

The key word is immutable. The audit log must be append-only. No actor—including platform administrators—should be able to modify or delete audit entries after they are written.

In practice

A production audit log schema for an identity API should capture the following fields:

The created_at field must be server-generated. Accepting client-supplied timestamps in an audit log is a compliance failure—it allows an attacker who compromises an API key to backdate or predate their activity.

Immutability enforcement

Database-level immutability is enforced through two mechanisms:

1. No UPDATE or DELETE grants: The application service account has INSERT-only access to the audit table. No UPDATE or DELETE permission is granted. This is enforced at the PostgreSQL role level rather than in application code.

1. Row-Level Security: RLS policies on the audit table permit SELECT for the tenant's own records and INSERT for authenticated service accounts. No UPDATE or DELETE policy exists.

An auditor reviewing this control will request evidence that the database role configuration prevents mutation. Application-layer "soft immutability" (e.g., a middleware that blocks DELETE requests) is insufficient because it can be bypassed by anyone with direct database access.

Control 2: Key rotation policies

Auditor expectations

CC6.1 requires that the organization implements logical access security measures. CC6.7 requires that the organization restricts the transmission, movement, and removal of information. For identity APIs, this translates to a concrete requirement: every cryptographic key and API credential must have a defined rotation schedule, and the rotation process must not cause service disruption.

Rotation architecture

Key rotation in an identity API involves three categories of keys:

The overlap window is critical. When a key rotates, the old key must remain valid for a defined period to allow in-flight operations to complete. A zero-overlap rotation—where the old key is immediately invalidated—causes authentication failures for any request that was signed with the old key but arrives after the rotation timestamp.

Evidence the auditor reviews

The auditor will request:

1. Rotation event logs: Timestamped records showing when each key was rotated, who initiated the rotation, and whether it was automatic or manual. These records live in the audit log (Control 1).

1. Policy configuration: Documentation or code showing the configured rotation intervals and overlap windows.

1. Failure handling: Evidence that a failed rotation (e.g., database write error during key swap) does not leave the system in an inconsistent state. This typically requires transactional key swaps with rollback capability.

Control 3: Tenant isolation

Auditor expectations

For multi-tenant identity APIs, CC6.1 and CC6.3 require that one tenant's data cannot be accessed by another tenant—even in the event of an application-layer vulnerability. This is the control where most identity platforms fail their first SOC 2 Type II audit.

Limits of application-layer isolation

A common pattern is to filter tenant data in the application layer:

// Application-layer isolation (INSUFFICIENT for SOC 2)
const events = await db.query(
  "SELECT * FROM events WHERE tenant_id = $1",
  [currentTenantId]
);

This works until a developer forgets the WHERE clause, a new endpoint skips the middleware, or an ORM generates an unfiltered query. A single missing filter exposes all tenants' data.

Database-layer enforcement

SOC 2-compliant tenant isolation requires enforcement at the database layer through Row-Level Security (RLS). With RLS enabled, every query against a tenant-scoped table is automatically filtered by the database engine—regardless of what the application sends:

-- Database-layer isolation (SOC 2 compliant)
ALTER TABLE shield_events ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON shield_events
  FOR ALL
  TO authenticated
  USING (tenant_id = auth.uid());

With this policy active, a query without a WHERE tenant_id = ... clause still returns only the authenticated tenant's rows. The isolation is enforced by the database engine itself.

Isolation verification

An auditor will test tenant isolation by:

1. Authenticating as Tenant A
2. Issuing a SELECT * FROM shield_events (no filter)
3. Verifying that only Tenant A's records are returned
4. Attempting a UPDATE shield_events SET status = 'tampered' against a Tenant B record by ID
5. Verifying that the update affects zero rows

This test cannot pass with application-layer filtering alone. It requires database-enforced RLS.

Control 4: Credential lifecycle management

Auditor expectations

CC6.2 requires that prior to issuing system credentials, the organization registers and authorizes new internal and external users. CC6.3 requires that the organization authorizes, modifies, or removes access to data. For identity APIs, "credentials" includes API keys, verifiable credentials, passkey attestations, and agent delegation certificates.

Every credential must have four lifecycle properties:

Time-bounded credentials

The most common SOC 2 finding in identity API audits is the presence of credentials without expiration. API keys that never expire, verifiable credentials with no expirationDate, or agent delegation certificates with an indefinite expires_at all violate CC6.2.

A compliant credential lifecycle enforces maximum validity periods:

Revocation latency

Revocation latency is the time between a revocation request and the moment the credential is no longer accepted by any system component. SOC 2 does not specify a maximum revocation latency, but auditors increasingly expect sub-minute propagation.

For identity APIs, revocation must propagate to:

• The API gateway (reject requests signed with the revoked key)
• The VC status endpoint (return revoked for StatusList2021 queries)
• The agent trust engine (invalidate delegation certificates)
• The cached proof store (mark proofs as invalid)

Any component that continues to accept a revoked credential represents a window of vulnerability that an auditor will flag.

Control 5: Access scope enforcement

Auditor expectations

CC6.1 requires logical access security over protected information assets. For identity APIs, this means API keys, user sessions, and agent delegates must operate under least-privilege principles with runtime enforcement.

Scoped API keys

An identity API key should not be a flat bearer token with full access. Each key should be scoped to specific operations:

When an API request arrives, the scope attached to the authenticated key is checked against the endpoint's required scope. A key scoped to ingest cannot read event history. A key scoped to events cannot issue credentials.

Agent scope narrowing

Agent delegation certificates introduce a second layer of scope control. An agent delegate operates within the scopes granted by its delegator, but those scopes can be narrowed at runtime based on behavioral trust signals:

Original scopes: [ingest, events, credentials]
Trust score: 0.92 → No narrowing

Trust score drops to 0.61 (behavioral drift detected)
Narrowed scopes: [events] (read-only)
Narrowing reason: "trust_decay_below_threshold"

The narrowing event is recorded in the audit log (Control 1), the agent is notified via the A2A protocol, and the narrowed scopes are enforced at the API gateway. The agent's original scopes are preserved and can be restored upon successful re-attestation.

This is the kind of control that a SOC 2 Type II auditor will specifically test—not because the TSC mentions "agent scope narrowing," but because it demonstrates that the organization's access controls respond dynamically to risk signals rather than remaining static between manual reviews.

The observation period

SOC 2 Type II requires that these controls operate correctly over a sustained period—typically 6 to 12 months. The auditor does not merely review documentation. They review the actual audit logs, actual key rotation events, actual tenant isolation enforcement, and actual credential lifecycle management that occurred during the observation window.

This means:

1. Audit logs must be retained for the full observation period. Log rotation that deletes records before the audit window closes will result in a qualified opinion.

1. Key rotations must actually occur on the scheduled cadence. A policy that says "rotate every 90 days" paired with logs showing no rotation in 180 days is a finding.

1. Tenant isolation must be continuously enforced. A single incident where cross-tenant data exposure occurred—even if immediately remediated—will appear in the auditor's report.

1. Credential expirations must be honored. If a credential's expires_at timestamp passes and the credential is still accepted, the lifecycle control has failed.

Consequences for your identity stack

If you are building or evaluating an identity API, these five control domains should be architectural requirements—not compliance afterthoughts. Retrofitting immutable audit logging into a system that was designed with mutable logs requires a migration. Retrofitting database-level tenant isolation into a system that relies on application-layer filtering requires re-architecting the data access layer.

The organizations that treat SOC 2 Type II as a design constraint from day one spend less time preparing for audits and more time building product. The ones that treat it as a checkbox spend months in remediation, explaining to auditors why their controls were "mostly working" during the observation period.

Mostly working is not a passing grade.

Further reading

• AICPA Trust Service Criteria (2017)—The canonical framework for SOC 2 audits.
• SOC 2 Readiness for Identity Startups in 2026—Our foundational guide to SOC 2 compliance in the identity space.
• The Zero-Knowledge Audit Trail: Proving Provenance Without PII—How the NF-07 Entropy Audit Pool satisfies audit requirements without storing sensitive data.
• The CISO's Guide to Zero-PII Identity Verification—Practical compliance mapping for GDPR Art. 25 and CCPA §1798.100.
• NIST SP 800-53 Rev. 5—Security and Privacy Controls—Federal control catalog that maps to SOC 2 TSC.
• PostgreSQL Row-Level Security Documentation—Technical reference for database-enforced tenant isolation.

Start free · Test the API