Root Account Has Active Access Keys: Why They Should Never Exist

The AWS root account is the original identity created when you open an account. It has unrestricted access to every service, every resource, and every billing control, and that access cannot be limited by IAM policies. Access keys are long-lived credentials made of an access key ID and a secret access key that allow programmatic API calls. Combine the two, and you have a static, never-expiring credential that can do absolutely anything in your account.

This Lensix check, account_rootaccesskeys, flags any AWS account where the root user has one or more active access keys. The correct number of root access keys is zero. There is no legitimate use case that requires them.

---

What this check detects

The check inspects the root account's credential report and reports a finding if either of the two possible root access keys is in an active state. AWS allows a maximum of two access keys per identity, including root, and this check fails if any of them exist and are enabled.

You can confirm the state yourself by pulling the IAM credential report, which includes a row for the root account:

aws iam generate-credential-report

aws iam get-credential-report \
  --query 'Content' --output text | base64 -d | \
  grep '<root_account>'

In the decoded CSV, look at the access_key_1_active and access_key_2_active columns for the root row. If either reads true, this check fails.

---

Why it matters

Root access keys are a favorite target because of what they unlock. An attacker who obtains them does not need to escalate privileges, pivot between roles, or find a misconfigured policy. They already have everything.

The realistic ways these keys leak are mundane and common:

• A developer hardcodes them into a script for a "quick test" and pushes it to a public GitHub repo. Bots scan new commits within seconds.
• They end up in a CI/CD environment variable, a Terraform state file, or a Slack message.
• They sit in an old ~/.aws/credentials file on a laptop that later gets compromised.

Once leaked, the damage is fast and severe. The classic pattern is an attacker spinning up dozens of expensive GPU instances across every region to mine cryptocurrency, leaving you with a five or six figure bill. Worse outcomes include data exfiltration from S3, deletion of backups, creation of hidden IAM users for persistence, and tampering with billing and account settings to delay detection.

There is also a compliance angle. CIS AWS Foundations Benchmark, PCI DSS, SOC 2, and most other frameworks explicitly require that no root access keys exist. This finding will fail audits.

---

How to fix it

The fix is to delete the keys. There is no scenario where you should rotate them instead, since the goal is to have zero.

Option 1: AWS Console

1. Sign in as the root user (you must be root to manage root keys).
2. Click your account name in the top right, then Security credentials.
3. Expand the Access keys section.
4. For each active key, click Actions, then Deactivate, confirm it is no longer needed, then Delete.

Option 2: AWS CLI

If you have the root key locally and want to remove it programmatically, you can deactivate and delete it. First list the keys for the root identity:

# Run while authenticated as root
aws iam list-access-keys

# Deactivate first to catch anything still using it
aws iam update-access-key \
  --access-key-id AKIAEXAMPLE12345 \
  --status Inactive

# Then delete it
aws iam delete-access-key \
  --access-key-id AKIAEXAMPLE12345

Repeat for the second key if it exists. After deletion, regenerate and re-check the credential report to confirm both access_key_*_active fields show false.

---

How to prevent it from happening again

Deleting the keys solves today's problem. Preventing the next one means stopping anyone from creating root keys in the first place and catching it instantly if they do.

Block root key usage with a Service Control Policy

If you use AWS Organizations, an SCP can deny most root actions across every member account. Root cannot be fully disabled, but you can block it from performing meaningful work, including creating access keys:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

Alert the moment a root key appears

Set up an EventBridge rule on the root credential events, or use AWS Config with the managed rule iam-root-access-key-check, which continuously evaluates whether root has active keys:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "iam-root-access-key-check",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "IAM_ROOT_ACCESS_KEY_CHECK"
  }
}'

Gate it in CI/CD with policy-as-code

If your accounts are provisioned through Terraform or another IaC pipeline, add a check that fails the build if root keys are detected. Lensix runs account_rootaccesskeys as part of its continuous scanning, so you can wire a failed finding into your deployment gate and block promotions until it clears.

---

Best practices

Removing root keys is one piece of properly securing the root account. The broader goal is to use root almost never, and when you do, to make it as protected as possible.

• Enable MFA on root. Use a hardware security key if you can, since it resists phishing better than a TOTP app.
• Use a strong, unique password stored in a password manager, separate from any individual employee's personal account.
• Do all daily work through IAM Identity Center or IAM roles. Root should only be touched for the small set of tasks that strictly require it, such as changing the account email or closing the account.
• Set up billing and security alerting so that unusual root activity triggers an immediate page.
• Document a break-glass procedure for the rare legitimate root login, including who is authorized and how access is logged.
• Audit regularly. The IAM credential report shows root key status, last password use, and MFA state in one place. Review it on a schedule.

The safest root account is one that has no access keys, has MFA enabled, and goes months between logins. If you find yourself reaching for the root user often, that is a signal your IAM setup needs work.

Fixing this check takes a few minutes. Keeping it fixed takes a guardrail. Put the SCP and continuous monitoring in place once, and root access keys stop being something you have to think about.