The AWS root user should not have an access key
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 InactiveConfigCobra 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
| Benchmark | CIS ID | Profile |
|---|---|---|
| CIS Amazon Web Services Foundations v7.0.0 | 2.4 | Level 1 |
Check this on your AWS
ConfigCobra runs this check with every other control of the CIS Amazon Web Services Benchmarks, read-only.