Why this matters
The root user is the first identity in an AWS account. It can change billing, close the account, delete resources, and change the support plan. IAM policies do not limit it. That means a stolen root password plus a missing MFA device is not a normal permission problem. It is full control of the account. Most teams use root once during setup and then forget it exists.
The common exposures are boring. A root email that forwards to a personal inbox. A group mailbox with no MFA. A root access key left in an old script. No alert when root signs in. Attackers look for these paths because they are quiet. A single root console login at 3 a.m. from a new country should wake someone up.
In AWS Organizations, every account has its own root user. The management account root is the most sensitive because it controls the organization. Member account roots still matter: they can close accounts, change contacts, and remove guardrails. Treat root as a break-glass identity. Give engineers IAM Identity Center or IAM roles for daily work.
Before you start
Write down every AWS account and its root email. If you use AWS Organizations, start from the accounts list in the management account. If you do not, pull the list from finance, support, or the cloud team. For each account, note who can read the root mailbox, who holds the MFA device, and whether root access keys exist. Do not change anything yet.
Choose a root email model you can support. Use a group mailbox on a company domain, not a personal address. Give it at least two named owners who can receive mail and pass a phone check. Turn on MFA for that mailbox and test recovery. Keep the mailbox out of daily use so a phishing email to it is easier to spot.
Get two hardware security keys per root account, or one key and a managed authenticator app as backup. Label each key with the account and store the backup offline. If you use an app, keep the recovery codes in a password vault, not in a ticket or chat. The goal is that one lost phone does not lock the company out.
Find root access keys before you delete them. Open the IAM console, choose the root user, then Security credentials. You can also read the IAM credential report and look at the root_account row. If a key is active, search logs and code for its use. Move that workload to an IAM role first. Pick a low-risk window for the change.
How to do it
Work one account at a time, starting with the management account. Keep a tested break-glass path open before you remove anything. The steps below assume you can sign in as root for the first pass. If you cannot, recover access first and record who approved it.
After root is locked, move daily work to IAM Identity Center or IAM roles. Use permission sets with least privilege and require MFA at sign-in. Do not hand out root credentials to engineers. For member accounts, use AWS Organizations SCPs to block risky actions and test each policy in a sandbox account.
- Secure the root email. Move the root email to a group mailbox on a company domain with at least two owners. Enable MFA on the mailbox and remove personal addresses from the recovery path. Update the email in the AWS account settings and confirm you receive the verification message.
- Enable root MFA. Sign in as root and open Security credentials. Choose Assign MFA device, register a hardware security key, then register a second key as backup. Label both keys and store the backup offline.
- Delete root access keys. In Security credentials, review Access keys for the root user. Delete every active key after you move its workload to an IAM role. Remove old signing certificates at the same time.
- Set a strong root password. Generate a long random password in a password manager. Store it in a vault with a short list of people who can open it. Never send it in chat or email. Rotate it if it was ever shared.
- Create break-glass admin access. Set up IAM Identity Center, create an admin permission set, and assign it to a small group. Require MFA at sign-in and use this role for daily work. Keep root for tasks that only root can do.
- Write the root use rule. Document the few tasks that need root, such as changing the root email, closing an account, or restoring access. Require a ticket and a second person for each use. Share the rule with finance and support so they do not ask for root by habit.
- Alert on root sign-in. Turn on an organization CloudTrail trail in all regions. Create an EventBridge rule for console logins where userIdentity.type is Root, and send it to a monitored channel. Test the alert with a real root sign-in.
- Set alternate contacts. In Account settings, add billing, operations, and security contacts. Use group aliases, not one person. AWS uses these contacts for outage and security notices.
- Repeat across accounts. Track each account in a simple sheet or ticket. Apply SCPs to member accounts to deny risky actions, and test in a sandbox first. Confirm every account has root MFA, no root keys, and an alert.
How to check it worked
Check root MFA and root keys from the AWS CLI. Run aws iam get-account-summary and confirm AccountMFAEnabled is 1. Generate the credential report and confirm the root_account row shows mfa_active as true and no active access keys. Repeat for each account.
Check the alert path. Use CloudTrail event history to find a ConsoleLogin event where the root user signed in. Confirm your EventBridge rule or CloudWatch alarm fired and reached the on-call channel. If you have no recent root login, do a controlled test sign-in and close the session.
Check daily access. Ask an engineer to sign in through IAM Identity Center and do a normal task. Confirm they can work without root and that the break-glass role works. Send a test message to the root mailbox group and to each alternate contact.
Use AWS Config managed rules to catch drift. Turn on root-account-mfa-enabled and iam-root-access-key-check. Send findings to a queue someone owns. Review IAM Access Analyzer for unused roles and over-broad policies that could replace root in daily use.
Mistakes to avoid
Do not put root MFA on one phone with no backup. Do not store the only hardware key in the same drawer as the only person who knows the password. Do not use a personal email for root. Do not share the root password in a ticket, chat, or wiki.
Do not delete root access keys before you find the workload. Do not assume member account roots are safe because the management account is locked. Do not leave a former employee on the root mailbox. Do not confuse an IAM administrator with root: an IAM admin is powerful, but root can still close the account and change the root email.
Do not rely on billing alarms alone. Do not skip CloudTrail in regions you think you do not use. Do not write an SCP that denies every action for root without a tested break-glass process. Test in a non-production account and keep a rollback path.
If you want an outside read before you change anything, the Cloud security review at $6,500 fixed price is one option among others. It reviews identity, exposure, encryption, and logging, then gives you a ranked fix list. You can also do this work yourself with the checks above.
Frequently asked questions
Can I delete the AWS root user?
No. Every AWS account has a root user tied to the account email, and you cannot delete it. You can remove root access keys, enable MFA, and stop using it for daily work. Keep the email and MFA devices under control.
Should I use root for everyday admin tasks?
No. Use IAM Identity Center or IAM roles with MFA and least privilege. Root is for account-level tasks that require it, such as changing the root email, closing the account, or restoring access. Daily use raises the chance of a mistake or a stolen session.
What MFA should I use for the AWS root user?
Use a hardware security key or an authenticator app. Register at least two devices and keep one offline. Store recovery details in a vault. Avoid SMS where you can because it is easier to intercept.