Five AWS settings auditors check first

1. MFA on the root user and every IAM user

• Why auditors care: a password alone is easy to steal, and the root user can do anything in the account. Access control criteria in frameworks such as SOC 2 and ISO/IEC 27001 rely on strong authentication.
• How to check: in the console, open Security credentials for the root user and the MFA column on the IAM users page. From the CLI, run aws iam get-account-summary and look for AccountMFAEnabled, then generate the credential report and read the mfa_active column for each user.
• How to fix: register a hardware key, passkey or authenticator app for root, and for every IAM user that remains. Better still, give people access through IAM Identity Center with MFA and keep few or no IAM users.
• TrustProof: the scan has a check for root user MFA and a check that reads mfa_active for every IAM user. Root settings are yours to change in the console; no tool can do that for you.

2. No access keys on the root user

• Why auditors care: root access keys are long-lived credentials with unlimited power and no MFA prompt, so a leaked key hands over the whole account.
• How to check: aws iam get-account-summary shows AccountAccessKeysPresent, and the credential report lists the root user’s key status. The console shows it under Security credentials.
• How to fix: confirm nothing still uses the key, move any workload to an IAM role, then delete the key. Use the root user only for the few tasks that need it.
• TrustProof: the scan checks that the root user has no active access keys.

3. CloudTrail on and retained

• Why auditors care: CloudTrail is the record of who did what in the account. Without it, an auditor cannot test change management or investigate an incident, and the record has to cover the whole review period.
• How to check: aws cloudtrail describe-trails and aws cloudtrail get-trail-status show whether a trail exists and IsLogging is true. Check it is multi-region and that log file validation is on. The Event history view only shows recent activity, so a trail that delivers to S3 is what gives you longer retention.
• How to fix: create a multi-region trail with log file validation, deliver it to a locked-down S3 bucket and set a lifecycle rule that keeps logs for the period your policy states.
• TrustProof: the scan checks that a trail is recording, and that a multi-region trail is logging with log file validation. It does not check how long CloudTrail logs are kept in S3, so confirm your retention rule yourself. A separate check covers retention on CloudWatch Logs log groups.

4. S3 not public, and encrypted

• Why auditors care: publicly readable buckets are a common cause of data exposure, and encryption at rest is a baseline expectation for customer data.
• How to check: in S3, review Block Public Access at the account level and for each bucket, and the default encryption setting for each bucket. From the CLI, use aws s3api get-public-access-block and aws s3api get-bucket-encryption, and aws s3control get-public-access-block for the account.
• How to fix: turn on all four Block Public Access settings for the account, remove public bucket policies and ACLs unless a bucket is meant to be public, and set default encryption. Since January 2023 every new S3 object is encrypted by default with SSE-S3, so the real decision is whether your policy requires SSE-KMS keys.
• TrustProof: the scan checks the account and each bucket for Block Public Access settings and for bucket policies or ACLs that make a bucket public, and separately checks each bucket has default encryption set.

5. No security groups open to the internet on SSH or RDP

• Why auditors care: SSH (port 22) and Remote Desktop (port 3389) reachable from anywhere invite constant automated attacks, and they are an easy item for a reviewer to test.
• How to check: in the EC2 console, filter security groups for inbound rules on those ports with a source of 0.0.0.0/0, or use aws ec2 describe-security-groups with a filter on the port and CIDR.
• How to fix: remove the rule. Use AWS Systems Manager Session Manager or EC2 Instance Connect Endpoint instead, or limit the source to a known address range or VPN.
• TrustProof: the scan finds security groups that let any IPv4 address (0.0.0.0/0) reach port 22 or 3389, and a separate check flags any security group open to all IPv6 addresses (::/0) on any port.

What to do next

Run the free AWS security scan to see all five at once through a read-only role that cannot change anything, and read what the AWS scan checks for the full list. These settings are only a start. To see how they fit a full programme, read our guides to the SOC 2 readiness timeline and evidence and CPS 234 for technology suppliers, or the SOC 2 readiness page. TrustProof does not certify, and a clean scan result does not decide any audit outcome.

FAQ

Frequently asked questions