SOC 2 Okta Checklist: MFA, Session Policies, User Lifecycle

Okta as Your SOC 2 Control Hub

When Okta is your primary identity provider, it becomes the single most important control for your SOC 2 audit. All human access to production systems — AWS console, GitHub, Salesforce, Jira, your own application — flows through Okta. This means a correctly configured Okta tenant can satisfy the majority of CC6 (logical access) criteria evidence requirements from one source.

Okta holds a SOC 2 Type II report of its own, downloadable from the Okta Trust Portal. Reference this in your audit package under the shared responsibility section. Your responsibility is the configuration of Okta: the policies you apply, the groups you create, the applications you integrate, and how you manage the user lifecycle. This checklist covers all of these areas with specific Okta Admin Console paths and settings.

MFA Policies (CC6.1)

Navigate to Security → Authenticators. Ensure you have at least one phishing-resistant authenticator configured: Okta Verify with device binding, FIDO2/WebAuthn, or a hardware security key (YubiKey). Avoid relying solely on SMS OTP — it is susceptible to SIM swap attacks and some auditors flag it as a weak authenticator for privileged access.

Navigate to Security → Authentication policies. Edit the "Any two factors" policy or create a new policy for privileged users. Set the condition "User must authenticate with" to "Phishing-resistant authenticator" for your admin group. For standard users, "Any factor" with Okta Verify is acceptable. Ensure the policy is ordered with the most restrictive rule first — Okta evaluates rules top-down and applies the first match.

Enable Okta ThreatInsight under Security → General → Okta ThreatInsight settings. Set it to "Log and enforce action based on threat level". ThreatInsight uses Okta network data across all tenants to identify known malicious IPs and block authentication attempts from them automatically. Enable "Exempt network zones" for your corporate IP ranges so that office users are not inadvertently blocked. This provides automated CC7.2 threat monitoring evidence.

Sign-On and Session Policies (CC6.6)

Navigate to Security → Authentication policies → [Policy name] → Add rule. Create rules for the following scenarios: (1) "Deny access from anonymizing proxies" — set "Network zone" to "Not in zones" and select "Anonymizer" (built-in zone). This blocks Tor exit nodes and known VPN providers used for credential attacks. (2) "Require MFA from unknown devices" — for users authenticating from a device not registered with Okta device trust, require step-up MFA.

Session lifetime settings control how long a user session remains valid without re-authentication. Under Security → Authentication policies → [policy] → Rule → Session settings: set maximum session lifetime to 8 hours for web applications and 1 hour for admin applications. Enable "Prompt for re-authentication" when session exceeds the idle timeout. Okta maps these to CC6.6 (boundary protection) and the access criteria under CC6.1.

For application sign-on policies, configure per-application rules. Sensitive applications (AWS, GitHub, Okta Admin) should require a fresh MFA challenge regardless of session state. Set this in the application sign-on policy: Okta Admin Console → Applications → [App] → Sign On → Edit. Check "Always require re-authentication" or set "Re-authentication frequency" to "Every sign-on".

Password Policies (CC6.1)

Navigate to Security → Authenticators → Password → Edit. Set complexity requirements: minimum length 12 characters, require lowercase, uppercase, number, and symbol. Set history to 24 passwords to prevent reuse. Set "Minimum password age" to 1 day to prevent users from cycling through history quickly. Set "Maximum password age" to 90 days (or 180 days if you have strong MFA enforced — NIST SP 800-63B recommends removing forced rotation when MFA is present, but many SOC 2 auditors still expect a rotation policy).

Enable "Common password check" which prevents users from setting passwords from the Have I Been Pwned (HIBP) database. This is a one-click setting in Okta that provides significant security value. Under Account lockout, set "Lock out account after" 10 failed attempts and "Unlock account after" 15 minutes (automated) or require administrator action for privileged accounts. Document these settings in your password policy document and reference Okta as the enforcement mechanism.

User Lifecycle Management (CC6.2, CC6.3)

CC6.2 requires that access is provisioned based on authorized requests. In Okta, implement Okta Workflows or integrate with your HRIS (BambooHR, Workday, Rippling) via the Okta HR provisioning connector. When an employee record is created in the HRIS, Okta automatically creates the user account, assigns them to the appropriate groups based on department and role, and provisions access to all mapped applications. Capture the HR system event and Okta provisioning event as CC6.2 evidence.

CC6.3 requires timely de-provisioning. Configure Okta to respond to HRIS termination events by immediately deactivating the user account and suspending all active sessions. Use the Okta Workflows "User offboarding" template as a starting point. The workflow should: (1) terminate all active Okta sessions, (2) deactivate the Okta account, (3) transfer owned items in Google Workspace or Microsoft 365, (4) notify the IT team for hardware collection. Target de-provisioning completion within 24 hours of the effective termination date.

Conduct quarterly access reviews using Okta's Group membership export or integrate with an access review platform. The review should verify that every active user's group memberships are still appropriate for their current role. Document the review results and any access changes made. This recurring review cycle is the primary evidence for CC6.3 ongoing access maintenance.

Group-Based Access Control

Never assign application access directly to individual users in Okta. Always use groups. Create groups aligned to job functions: Engineering-All, Engineering-Senior, DevOps, Security, Finance, HR, and so on. Assign applications to groups, not users. This ensures that when someone changes roles, removing them from one group and adding them to another is sufficient to adjust all application access atomically.

Use Okta Group Push to synchronize Okta groups to downstream applications. This means changes to group membership in Okta automatically propagate to GitHub teams, AWS SSO permission sets, Jira project roles, and Slack user groups. Without Group Push, access management becomes a multi-system manual process that inevitably drifts and creates audit findings.

System Log and Audit Evidence

The Okta System Log (`/api/v1/logs`) records every authentication event, policy evaluation, user lifecycle event, and administrative action in your tenant. This is the primary evidence source for CC6.x, CC7.2, and CC7.3 in an Okta-centric environment. Access it via Admin Console → Reports → System Log.

Export System Log events to your SIEM using the Okta System Log API. Set up a scheduled job that pulls events with `?since=` and `?until=` parameters and writes them to S3 or your logging platform. Okta supports native log streaming via the Log Streaming feature (Admin Console → Reports → Log Streaming) to AWS EventBridge or Splunk Cloud — enable this for real-time streaming.

Key event types to include in your audit evidence: `user.authentication.sso` (SSO authentications), `user.account.lock` (lockouts), `policy.lifecycle.deactivate` (policy changes), `user.lifecycle.deactivate` (de-provisioning), and `group.user_membership.add/remove` (access changes). Filter these events for your audit period and export to PDF or CSV for the auditor package.

Complete Okta SOC 2 Checklist

MFA: (1) Phishing-resistant authenticator configured (Okta Verify with device binding or FIDO2). (2) Authentication policy requires MFA for all users. (3) Privileged users required to use phishing-resistant MFA. (4) ThreatInsight enabled with enforce action.

Sign-On: (5) Anonymizing proxy network zone blocked. (6) Session lifetime ≤8 hours for standard, ≤1 hour for admin apps. (7) Re-authentication required for sensitive applications. (8) Device trust policy configured.

Passwords: (9) Minimum 12 characters, complexity enforced. (10) 24-generation password history. (11) 90-day rotation policy (or documented exception for MFA-strong environments). (12) Common password check (HIBP) enabled. (13) Account lockout after 10 attempts.

Lifecycle: (14) HRIS integration for automated provisioning. (15) Termination workflow de-provisions within 24 hours. (16) Group-based access (no individual app assignments). (17) Group Push enabled for downstream apps. (18) Quarterly access reviews documented.

Logging: (19) System Log exported to SIEM or S3 monthly. (20) Log streaming enabled (EventBridge or Splunk). (21) Alerts configured for admin role changes and multiple failed authentications.