The AWS root user has complete access to every resource in the account, so AWS recommends you do not use it unless a task specifically requires root credentials. Create an administrative identity for daily work, enable MFA on root, never create root access keys, and alert whenever root signs in.
What makes root different
When you create an AWS account, you start with one identity that can do everything, including billing changes and closing the account. It cannot be limited by an IAM policy the way a normal user can. That is why a stolen root password or session is the worst case for an account.
Because of that, the working rule is simple. Use root only for the short list of tasks that AWS says need it, and use something else for everything else.
What to use instead
For a single standalone account, AWS suggests IAM roles that give people temporary credentials. A role has no password or access key of its own. Someone assumes it and gets a session that expires.
For several accounts under AWS Organizations, AWS recommends IAM Identity Center workforce users, managed there or from your own identity provider. Either way, the goal is that nobody holds long-term credentials for daily admin work.
Locking root down
Treat the root login like a break-glass account:
- Use a strong, unique password from a password manager.
- Register MFA. AWS lets you register up to eight MFA devices on root, and recommends more than one so a lost device does not lock you out. All account types now require MFA on root, with a grace period after first sign-in.
- Do not create access keys for root. If you need the CLI for a root task, AWS points to the
aws logincommand, which gives temporary credentials. - Use a group mailbox for the root email, managed by the business, not a person who might leave.
- Split recovery channels. No single person should control both the root mailbox and the registered phone number.
AWS also describes splitting the password and the MFA between two groups, so that signing in as root takes one person from each.
Member accounts in an organization
If you run many accounts, each has its own root user. AWS describes two choices. You can centralize root access and remove root credentials from member accounts, so they cannot sign in or recover a root password at all. Or you can keep the credentials and secure each with MFA. A service control policy can also deny most root actions in member accounts, apart from the few root-only tasks.
Watching for root use
Root should almost never appear in your logs. AWS suggests alerting on root sign-in and usage through CloudWatch or EventBridge, and notes that GuardDuty can flag root credential use. An alert is only useful if someone knows what to do with it, so write down how to confirm the sign-in was expected and who to escalate to.
AWS Config and Security Hub can also check that root has MFA and has no access keys. If you remove root credentials from member accounts, expect those MFA checks to report not applicable rather than failing.
Where Safeguard fits
Safeguard's compliance and evidence automation can collect proof of controls like MFA enforcement for audits, but it does not replace configuring root correctly in AWS. Do that first.
Quick check
Can I just delete the root user?
No. The root user is part of the account. What you can do, in an organization, is remove its credentials from member accounts so nobody can sign in as root there.
Do I need root for anything at all?
Yes, a small set of tasks still need it. AWS maintains a list of tasks that require root credentials. Check that list before assuming a task needs root.
Sources
Last reviewed: 19 October 2026.
