AWS Security Hub · IAM
IAM.4: The root user still has long-lived access keys
Written and reviewed by Emnode · Last reviewed
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, open My Security Credentials, and 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.
More IAM controls
- 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