Skip to main content
Five Steps for Cloud Compliance Readiness·A practical playbook for security teamsDownload
CIS Amazon Web Services Foundations v7.0.0 · 2.4

The AWS root user should not have an access key

  • Level 1

This check looks at whether the account's root user has any programmatic access key. The safe setting is that none exists, so the root user can only be used through an interactive sign-in protected by MFA.

Why it matters

The root user can do everything in an AWS account, and its permissions cannot be restricted with IAM policies. An access key is a long-lived secret that works without MFA, so one leaked key in a code repository, a laptop backup or a chat message hands over the whole account. AWS recommends that you do not create root access keys and that you delete any that exist, and to use IAM roles or Identity Center for daily work.

Sources: AWS root user best practices, AWS account root user.

How to check it yourself

Sign in to the console and open IAM. The dashboard shows a security recommendation if the root user has an access key. You can also open the account menu → Security credentials and look at the Access keys list.

From the AWS CLI, this read-only call returns the number of root access keys. The expected value is 0:

aws iam get-account-summary \
  --query 'SummaryMap.AccountAccessKeysPresent'

A result of 1 or 2 means at least one root key exists.

How to fix it

Sign in as the root user, open the account menu → Security credentials → Access keys. Check the Last used information for each key and find out what uses it. Move that workload to an IAM role or a dedicated IAM user with only the permissions it needs. Then choose Actions → Deactivate, wait long enough to be sure nothing breaks, and only then choose Delete.

Deactivating first is a reversible step. If you prefer a script, run it with the root credentials themselves and replace the placeholder with the key ID shown in the console:

aws iam update-access-key \
  --access-key-id AKIAEXAMPLEKEYID \
  --status Inactive

ConfigCobra itself never changes your account. It generates the steps and leaves the change to you.

What changes when you fix it

Anything that still signs in as root with that key stops working the moment the key is deactivated. Typical culprits are old backup scripts, billing exports and third-party tools that were set up years ago. That is why the deactivate step comes before the delete step, and why the last-used date matters. People who sign in to the console as root are not affected, because passwords and MFA devices are separate from access keys. Once the key is gone, the account has one fewer secret that can leak.

Included in

BenchmarkCIS IDProfile
CIS Amazon Web Services Foundations v7.0.02.4Level 1

Check this on your AWS

ConfigCobra runs this check with every other control of the CIS Amazon Web Services Benchmarks, read-only.

Get in touch

Let's talk.

Whether you're evaluating ConfigCobra, running an audit, or managing a client fleet — we respond within one business day.

Free trial