Controls1 May 2026 8 min read

AWS IAM Controls for SOC 2: The Complete Checklist

A complete AWS IAM controls checklist for SOC 2. Covers root account lockdown, least-privilege policies, MFA enforcement, access key rotation, and auditor evidence.

Key Takeaways

Root account should have no access keys, MFA enabled, and be used only for break-glass scenarios.
IAM users should be replaced by IAM Identity Center for human access.
All IAM policies should follow least privilege — start with AWS managed read-only policies and add specific write permissions.
Access keys older than 90 days are a common finding — rotate or replace with IAM roles.
AWS IAM Access Analyzer identifies overly permissive policies before auditors do.

In this guide

Root Account Lockdown
IAM Users vs Identity Center
Least Privilege Policy Design
Access Key Management
MFA Enforcement
IAM Access Analyzer
IAM Evidence for SOC 2 Auditors

Root Account Lockdown

The AWS root account has unrestricted access to all AWS services and cannot be restricted by IAM policies. Securing it is a critical CC6.1 and CC6.2 requirement. The controls for root: (1) Enable MFA — use a hardware security key (YubiKey) rather than a virtual MFA device for the root account. (2) Delete root access keys if any exist. (3) Do not use the root account for routine operations. (4) Store the root account credentials in a physical safe or encrypted vault accessible only to named executives.

AWS Config managed rule "iam-root-access-key-check" will alert if root access keys exist. Run this rule and evidence a clean result for your auditors.

Under AWS Organizations, the management account root is especially sensitive — a compromise could affect all member accounts. Enable an SCP that prevents members from operating without the organization context, and restrict root usage at the organization level.

IAM Users vs IAM Identity Center

Traditional IAM users (with username/password and access keys) are being replaced by AWS IAM Identity Center (formerly AWS SSO) for human access. Identity Center integrates with your corporate IdP (Okta, Azure AD, Google Workspace), enforces MFA at the IdP level, and issues short-lived credentials for AWS access.

For SOC 2 compliance, the goal is: no IAM users for human access — all human access via Identity Center with MFA at the IdP. IAM users only for service accounts where a role cannot be used. If you currently have IAM users for humans, create a migration plan and execute it before the audit.

Service accounts should use IAM roles with instance profiles or ECS task roles — not IAM users with access keys. IAM roles issue temporary credentials that auto-rotate, eliminating the access key rotation burden.

Least Privilege Policy Design

Least privilege means each IAM identity (user, role, group) has only the permissions needed to perform its function. Start with the principle: deny by default, allow only what is explicitly needed.

For engineering roles: use AWS managed job function policies as a starting point (ReadOnlyAccess, PowerUserAccess) and restrict further. Add specific allow statements for the services the role needs to write to. Avoid "Action: *" wildcards. Use resource ARNs to scope permissions to specific S3 buckets, DynamoDB tables, or RDS instances rather than all resources.

Use IAM Access Analyzer to identify policies that grant public access or cross-account access that wasn't intended. Run an access advisor report (IAM console > role > Access Advisor tab) to identify service permissions that have never been used — remove them.

Access Key Management

Long-lived IAM access keys are a high-risk control gap. Keys that are exposed in code repositories, compromised via phishing, or simply old represent a significant breach risk. SOC 2 auditors will check the IAM credential report for access keys older than 90 days and flag them as a finding.

Best practices for access key hygiene: (1) Prefer IAM roles over access keys wherever possible. (2) Set a key rotation policy — rotate access keys every 90 days maximum. (3) Configure AWS Config rule "access-keys-rotated" with maxAccessKeyAge of 90 to alert on stale keys. (4) Enable AWS Secrets Manager or Parameter Store for storing keys that must be long-lived. (5) Audit all GitHub repositories for accidentally committed keys using AWS Partner tools or GitHub's secret scanning feature.

MFA Enforcement for IAM

For remaining IAM users (those not yet migrated to Identity Center), enforce MFA with a deny policy. Attach the following policy to all IAM users or groups: deny all AWS actions unless the request is authenticated with MFA (aws:MultiFactorAuthPresent: true), with exceptions for the MFA enrollment actions so users can set up their MFA device before the policy takes effect.

The AWS documentation provides a ready-made policy for this — search "IAM enable MFA for users" in the AWS docs. Attach it to a group containing all IAM users.

AWS Config managed rule "iam-user-mfa-enabled" checks all IAM users have MFA devices attached. "mfa-enabled-for-iam-console-access" checks console access specifically. Evidence both rules in a compliant state.

IAM Access Analyzer

AWS IAM Access Analyzer identifies resource policies that grant access to external principals — S3 buckets accessible from outside your account, IAM roles that can be assumed by other AWS accounts, and more. Enabling it and resolving all findings demonstrates proactive CC6.1 compliance.

Enable Access Analyzer in all regions and accounts from IAM > Access Analyzer > Create Analyzer. Review active findings monthly. For each finding, either confirm that the external access is intended (archive with justification) or remediate by removing the external access.

Access Analyzer also validates IAM policies against the principle of least privilege — use the policy validation feature when writing new policies to catch overly permissive patterns before deployment.

IAM Evidence for SOC 2 Auditors

(1) IAM credential report (aws iam get-credential-report) — shows all IAM users, password age, MFA enrollment, access key ages, and last used dates. (2) IAM Security Status dashboard screenshot — shows green checkmarks for root MFA, no root access keys, MFA on users. (3) AWS Config findings for iam-root-access-key-check, iam-user-mfa-enabled, access-keys-rotated. (4) IAM Access Analyzer findings list showing no active unresolved public/cross-account access findings. (5) Identity Center configuration screenshot showing external IdP integration. (6) Sample IAM role policies for key engineering roles demonstrating least privilege.

Frequently Asked Questions

How do we handle AWS access for contractors who don't have corporate IdP accounts?

Options: (1) Create a guest account in your IdP with MFA enforced and provision Identity Center access. (2) Create a time-limited IAM role that the contractor can assume using their own AWS account credentials (cross-account role assumption). (3) For short engagements, create a scoped IAM role and generate temporary credentials via aws sts assume-role. Document the contractor access policy and revoke access when the engagement ends.

AWS says we should delete unused IAM users — how do we identify them?

Use the IAM credential report to identify users with "last_used" dates older than 90 days and no recent console sign-in. Also use the Access Advisor tab on each user or role to see which services were accessed in the last 90 days. Deactivate (disable console access and delete access keys) before deleting, to avoid disrupting any automated process you may have forgotten.

What is the difference between an IAM policy finding and a SOC 2 finding?

An IAM policy finding (from Access Analyzer or Security Hub) is a technical observation about a configuration issue. It becomes a SOC 2 finding when an auditor identifies it as a control gap — for example, a publicly accessible S3 bucket is a CC6.1 finding because it violates least-privilege access. Remediate IAM findings before your audit to prevent them from becoming SOC 2 findings.

Do Service Control Policies (SCPs) count as access controls for SOC 2?

Yes. SCPs are preventive controls that enforce guardrails across all accounts in an AWS Organization. An SCP that prevents disabling CloudTrail, creating public S3 buckets, or enabling regions you don't use are all strong CC5.2 and CC6.1 evidence. Screenshot the SCPs and their attachment to the organization root or specific OUs.

How often should we run the IAM credential report for SOC 2?

Generate and review the IAM credential report at least monthly. For a Type II audit, you want to show continuous oversight — a monthly review cadence with a documented process (who reviews it, what they look for, what triggers action) demonstrates an operating control, not just a one-time check.