The AWS root user should not be used for administrative or daily work
This check looks at whether the root user of the AWS account has been used to sign in or to call the API recently. The safe setting is that day-to-day and administrative work runs through other identities and the root user is kept for the few tasks that only it can do.
Why it matters
The root user has unrestricted access to everything in the account and cannot be limited by IAM policies. A stolen or misused root credential therefore has the widest possible impact, and root activity is hard to attribute to a person. AWS recommends using root only for the small set of tasks that require it: root user best practices and tasks that require root.
Root activity is also a useful signal. Because a well-run account hardly ever uses root, a single root sign-in is unusual enough to be worth a conversation, which is only true if people do not use it for routine work.
How to check it yourself
In the IAM console open Credential report and download it; the row for <root_account> shows when the password and any access keys were last used. CloudTrail Event history filtered by user name root shows what root did.
Read-only commands with the AWS CLI:
aws iam get-credential-report --query Content --output text | base64 -d
aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=root --max-results 20If the report does not exist yet, aws iam generate-credential-report creates it; this does not change any setting.
How to fix it
Give administrators their own identities, for example through IAM Identity Center or IAM roles with the permissions they need, and move automation to roles. Then stop signing in as root. Store the root password and its MFA device securely, and use them only for tasks that AWS lists as root-only.
- Create or confirm an administrator identity with MFA.
- Test that this identity can do your regular admin work.
- Remove any root access keys.
- Set up an alert on root sign-in events so unexpected use is noticed.
ConfigCobra only reads your environment and never changes it; the steps below are for you or your administrator to run.
What changes when you fix it
Administrators sign in with their own accounts instead of a shared root login, so every action is tied to a person in CloudTrail. People who used root out of habit need an alternative path, and a small number of account-level tasks still need root, so keep the recovery procedure documented. Nothing about running workloads changes.
Roll this out by first finding out who still uses root today. The credential report and CloudTrail will show whether it is one person, a forgotten script, or a shared habit. Fix the cause for each, tell the team which identity replaces root, and keep a written procedure for the rare root-only tasks, including who holds the MFA device. The remediation impact view in ConfigCobra can list the affected identities before you apply a fix.
Included in
| Benchmark | CIS ID | Profile |
|---|---|---|
| CIS Amazon Web Services Foundations v7.0.0 | 2.7 | Level 1 |
Check this on your AWS
ConfigCobra runs this check with every other control of the CIS Amazon Web Services Benchmarks, read-only.