Root Account

The Root Account (root user) is the identity created when you first set up an AWS account. It has complete, unrestricted access to all AWS services and resources - it cannot be limited by IAM policies or permission boundaries. In the management account, SCPs do not apply to the root user either. However, in member accounts, SCPs do restrict the root user.

Because of this unlimited power, the root account is the single most critical identity to protect. A compromised root account means total loss of the AWS environment.

Security Best Practices

• Enable MFA immediately (hardware FIDO2 key recommended)
• Do not create access keys for the root user
• Use root only for tasks that require it (account settings, billing, support plan changes)
• Create IAM users or use IAM Identity Center for daily operations
• Since November 2024, AWS centralized root access management lets you remove root credentials from member accounts entirely
• Set up CloudTrail alerts for any root account activity

How It Goes Wrong in Practice

The classic pattern is the forgotten root access key. Years ago someone generated root keys "temporarily" for a script, and they still exist: in an old laptop backup, a CI variable, or worst of all a Git repository. A leaked root key is the worst possible credential exposure because nothing constrains it. There is no IAM policy, no permission boundary, and in a standalone account no SCP that can limit what the holder does. An attacker with root can change the account email and password, remove every other administrator, stop logging, and hold the entire environment hostage. This is why the first two items on any AWS audit checklist are: root MFA enabled, root access keys absent.

The second pattern is the email takeover. Root sign-in is tied to an email address, and password recovery flows through that inbox. If the root email is a personal mailbox, a shared alias with weak protection, or an ex-employee's address, whoever controls the inbox can work toward controlling the account. Treat the root email as a privileged credential: use a dedicated, access-controlled distribution address per account, protected with MFA on the mail side too.

Finally, teams often protect root in production but forget the dozens of member accounts created over the years, each with its own root user, password, and recovery path. Centralized root access in AWS Organizations addresses exactly this: you can remove the root password, access keys, signing certificates, and MFA from member accounts, and new accounts created in Organizations have no root credentials by default.

A Practical Check

Two account-level indicators come straight from IAM:

aws iam get-account-summary --query "SummaryMap.AccountMFAEnabled"

aws iam get-account-summary --query "SummaryMap.AccountAccessKeysPresent"

You want AccountMFAEnabled to return 1 and AccountAccessKeysPresent to return 0. To review recent root activity, query the CloudTrail event history, which keeps 90 days of management events per region:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=root

Any hit outside a known billing or account-maintenance window deserves an immediate investigation.

Frequently Asked Questions

Which tasks genuinely require the root user? A short list, including: activating IAM access to the Billing and Cost Management console, closing a standalone AWS account, changing a standalone account's root email or password, restoring IAM permissions if the only administrator revoked their own access, registering as a seller in the Reserved Instance Marketplace, enabling MFA delete on an S3 bucket, and fixing an S3 bucket policy or SQS queue policy that denies all principals. Everything else should run through IAM Identity Center or IAM roles.

Is MFA on the root user mandatory? AWS enforces MFA for root users by default, but it still requires action on your side: you add the MFA device during initial account creation or when prompted at sign-in. Register more than one device where possible, and prefer FIDO2 hardware keys over virtual authenticator apps for this identity.

Can I get rid of root credentials entirely? For member accounts in AWS Organizations, yes. With centralized root access enabled you can delete the root password, access keys, and MFA from member accounts, and block password recovery. If you later need root-level action on a member account, the management account or delegated administrator performs a privileged task, or temporarily re-enables password recovery for that account. The management account itself keeps its root user, which is why it deserves the strictest protection in your organization.