Sign in as root, choose your account name in the upper-right corner and choose Security Credentials, then delete every access key listed under the root user. Move any automation that was using a root key to a dedicated IAM role or user with a scoped policy. Lock the root user down with hardware MFA (see IAM.6/IAM.9) and use it only for the handful of tasks that genuinely require root.

Compliance Critical severity

AWS Security Hub · IAM

IAM.4: The root user still has long-lived access keys

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub IAM.4 check?

IAM.4 checks the root user of the account and fails if any access keys exist for it. The AWS root account is never supposed to hold programmatic credentials.

Why does IAM.4 matter?

Root access keys cannot be scoped, cannot be denied by an SCP, and grant unrestricted control of the entire account including billing and account closure. A leaked root key is a full account takeover with no policy that can stop it. AWS's own guidance is to delete them and never recreate them.

How do I fix IAM.4?

Sign in as root, choose your account name in the upper-right corner and choose Security Credentials, then delete every access key listed under the root user.
Move any automation that was using a root key to a dedicated IAM role or user with a scoped policy.
Lock the root user down with hardware MFA (see IAM.6/IAM.9) and use it only for the handful of tasks that genuinely require root.

Remediation script · bash

# Close the highest-blast-radius mode first: confirm and remove the root access key.
# (Deletion is done as the root user via the console; an IAM identity cannot do it.)
aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent'
# Expect 0 after deletion.

# Close a public EKS endpoint (only after confirming a private path exists).
aws eks update-cluster-config --name svc-orders \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true

# Disable legacy ACLs on a bucket and let policy govern access.
aws s3api put-bucket-ownership-controls --bucket my-legacy-assets \
  --ownership-controls 'Rules=[{ObjectOwnership=BucketOwnerEnforced}]'

# Migrate a Transfer Family server off plain FTP to SFTP only.
aws transfer update-server --server-id s-0a1b2c3d4e5f --protocols SFTP

Full walkthrough (console steps, edge cases and verification) in the lesson Disable insecure access modes and protocols.

Is IAM.4 a false positive?

This control has effectively no legitimate-failure case: AWS's own guidance is that root access keys should never exist, and the check is a simple binary on the account, so a FAIL almost always means a real key is present and must be deleted. The one scenario that looks like a false positive isn't one: a very old account created before IAM existed may have had root keys provisioned automatically, but those still need removing, not excepting. Don't suppress this finding; delete the key and confirm the control flips to PASSED. If you operate in AWS GovCloud (US), use the GovCloud-specific deletion path, but the expected end state is identical: zero root access keys.

Full lesson Disable insecure access modes and protocols Step-by-step remediation with CLI, code and persona-specific context.

AWS documentation for IAM controls ↗ Check your own account for IAM.4 →

Part of the learning path Lock down access

IAM.1 A policy grants full "*" administrative privileges
IAM.2 Policies attached directly to users do not scale or audit cleanly
IAM.3 Long-lived access keys have not been rotated
IAM.5 Console users without MFA are one phish from compromise
IAM.6 The root user is not protected by hardware MFA
IAM.7 The IAM password policy is too weak
IAM.8 Unused IAM keys and passwords are waiting to be leaked
IAM.9 The root user can sign in without MFA
IAM.10 IAM user password policies should be strong (PCI DSS)
IAM.19 MFA should be enabled for all IAM users
IAM.21 Wildcard permissions grant far more access than intended
IAM.22 IAM credentials unused for 45 days should be removed