One login can undo everything else you build
You can spend weeks designing accounts, guardrails and least-privilege roles, and all of it is bypassed by one credential: the AWS root user. It is created with the account, sits outside IAM policy control, and can do anything. Service control policies, for instance, do not stop it in the management account.
That makes root hardening the first job in any new estate and a priority in inherited ones. It is quick, unglamorous and one of the highest-value tasks in our cloud setup service. Once done, everyone signs in through Identity Center and root becomes a sealed emergency tool.
What we find in real accounts
These are patterns from console-built environments:
- The root email is a founder’s personal address, long since forgotten.
- Root has a password only, or an authenticator app on one phone.
- Root access keys were created for a script years ago and are still active.
- Nobody knows who last signed in as root, because nobody looked.
- Billing and security contacts are blank, so AWS notices go unread.
Each of these is a realistic route to an account takeover or a lockout.
What good looks like
- Root MFA uses a phishing-resistant method, with a registered backup.
- Zero root access keys.
- A strong, unique password stored in a team vault with controlled access.
- The root email is a distribution list, with at least two people receiving it.
- Alternate contacts for billing, operations and security are filled in.
- Any root sign-in triggers an alert within minutes.
- The procedure to use root is written down and rarely invoked.
How it works in practice
Check the current position
The IAM credential report shows root status quickly:
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d | head -2
The first data row is the root user. We look at whether access_key_1_active and access_key_2_active are false, whether MFA is active and when the password was last used. The account summary also reports root key and MFA state:
aws iam get-account-summary \
--query "SummaryMap.[AccountMFAEnabled,AccountAccessKeysPresent]"
You want MFA to read 1 and keys to read 0.
MFA and recovery
Register two security keys, kept in different locations, and write down who has custody. A single key in one drawer is a single point of failure. Avoid putting the only MFA on one individual’s phone. The recovery path, including the email address and the phone number on the account, should be tested rather than assumed, because AWS account recovery without them is painful.
Alerting on root use
Root activity appears in CloudTrail. A simple EventBridge rule, in the default event bus of each region you use for sign-in events, sends root logins to an SNS topic that pages or emails the team:
{
"detail-type": ["AWS Console Sign In via CloudTrail", "AWS API Call via CloudTrail"],
"detail": {
"userIdentity": { "type": ["Root"] }
}
}
Console sign-in events for the root user are recorded in us-east-1, so the rule must exist there. In an organisation we create the rule through Terraform in every account, and feed the same events into the security baseline so they are not missed.
Billing alerts
Because root usually owns billing, we set budgets at the same time: a monthly total with alerts at several thresholds, plus a forecast alert. The detail is in billing alerts and cost budgets.
Organisation-wide root management
In an AWS Organization, member-account root users are a large and often neglected attack surface. AWS offers centralised root access management, which lets you remove root credentials from member accounts and use short-lived, task-scoped privileged sessions from the management account when something truly needs root. Where the feature fits your setup, we enable it and reduce the number of root passwords in existence to nearly zero. Where it does not, each member account’s root receives MFA and monitoring. Account structure is explained in multi-account design.
Decisions and trade-offs
Hardware keys versus authenticator apps. Keys resist phishing and are the better choice, but you must manage physical custody. For a very small team an app on a dedicated device is an acceptable second best.
Who holds the keys? Two named senior people, never one. Splitting the password and the MFA between different custodians gives separation but adds friction in an emergency. Choose based on how often you expect to need root, which should be rarely.
Shared mailbox versus individual. Always shared, with an alias you control on your own domain, so it survives staff changes.
When this is not enough. Hardening root does not fix weak IAM elsewhere. It is a floor, not a security programme.
Inherited accounts and awkward cases
Not every account starts clean. When a client asks us to take over an estate, we often meet one of three situations. First, the root email belongs to an agency or former contractor. In that case we work through the AWS account recovery and contact-change process early, because it can take days and needs the current owner’s cooperation. Second, the account was opened with a personal credit card and personal email by a founder. We move billing ownership to the company and attach the account to an organisation, so that it is no longer tied to one person. Third, several accounts exist with no organisation at all, each with its own root credentials. We invite them into one organisation and then reduce the number of live root credentials as far as the platform allows.
None of this is dramatic work, but it is the kind that stays undone for years because nobody owns it.
Common failure modes
- MFA device lost with no backup. Recovery requires proof of identity and time.
- Mailbox on a domain that lapsed. Whoever registers the domain can reset the password.
- Keys deleted that a forgotten job still used. We check CloudTrail history before removal.
- Alert goes to an unmonitored inbox. We test it by actually signing in and confirming a human sees it.
A short test plan we run afterwards
Hardening that was never tested is a hope. Once the changes are made we verify them with the people who will really use them. We sign in as root with the registered key and confirm the alert reaches the right channel. We read the credential report again to confirm no keys remain. We check that the shared mailbox receives a test message from AWS, that a second custodian can access the vaulted password, and that the recovery steps in the runbook match what the console actually shows today. If any step surprises us, we correct the documentation before it is needed in anger.
Delivery and handover
We carry out the hardening in a single session with the right custodians present, because MFA registration needs their devices. You receive a checklist showing the before and after state, the alert configuration as code, and a one-page emergency procedure. For environments with many accounts, the same checklist is applied to each.
How to tell it is working
- The credential report shows no root keys and root MFA enabled in every account.
- A test root sign-in generates an alert within minutes.
- The last root usage date is months or years old.
- Two people can explain where the recovery devices are.
To have your accounts checked, contact us.