Lock away the root user: real-world lessons and examples

We've all heard the advice: don't use your AWS root user for everyday tasks. But knowing the theory and actually living it in a production environment are two different things. This article walks through why you need to lock away the root user: real-world lessons and examples that show what happens when teams skip this step — and how to do it right from day one.

Why the root user is dangerous

The AWS root user is the account owner. It has unrestricted access to every service, every resource, and every billing setting. Unlike an IAM user with a specific role, the root account cannot be restricted by policies. More critically, if someone compromises your root credentials, they can:

• Delete every resource in your account
• Modify billing settings and incur massive charges
• Close the entire AWS account, locking you out permanently
• Create backdoor IAM users that persist even after password resets
• Access encrypted data without key restrictions

We've seen teams lose production databases, get locked out of accounts during incident response, and spend weeks in AWS support disputes because a contractor's laptop was compromised and the root credentials were stored in a shared password manager. The root user isn't just a security risk — it's a business continuity risk.

Enable MFA on root immediately

Multi-factor authentication (MFA) is the first line of defense. It adds a second factor — typically a time-based one-time password (TOTP) from an authenticator app — that an attacker would need even if they steal your password.

The setup takes five minutes:

1. Sign in to the AWS Management Console as the root user
2. Go to Account > Security Credentials
3. Under Multi-factor authentication, choose Assign MFA device
4. Select Authenticator app (Google Authenticator, Authy, or Microsoft Authenticator work well)
5. Scan the QR code with your app and enter two consecutive TOTP codes to confirm

Store the backup codes somewhere secure — not in Slack, not in Git, not in an unencrypted notes file. Use your password manager or a separate encrypted vault. If you ever lose access to your authenticator app, those codes are your recovery path.

Real scenario: A startup we know had root MFA enabled. When an engineer's email was compromised and the attacker tried to reset the root password, AWS rejected it because MFA was required. The attacker couldn't proceed. Without MFA, that account would have been wide open.

Never create root access keys

Access keys are pairs of credentials (an access key ID and secret access key) used for programmatic access to AWS APIs. You might think: "I'll just create one root access key for my infrastructure automation." This is one of the most dangerous mistakes in AWS.

Why? Access keys are static. They're not rotated automatically. Once they exist, they're a permanent backdoor if compromised. And because they're for the root user, they grant unlimited permissions.

Check whether your account has root access keys:

aws iam get-credential-report

This generates a CSV report. Look for any row with <root_account> and access_key_1_active or access_key_2_active set to true. If you find any, delete them immediately:

# First, find the access key ID from the credential report
# Then delete it via the console (AWS CLI cannot delete root access keys programmatically for security reasons)
# Navigate to Account > Security Credentials > Access keys > Delete

Instead, create an IAM user with a specific role for any automation, CI/CD pipelines, or third-party integrations. That user gets only the permissions it needs — a practice called the principle of least privilege.

Example: Your deployment pipeline needs to push images to ECR. Don't give it root credentials. Create an IAM user with an attached policy that grants only ecr:GetDownloadUrlForLayer, ecr:PutImage, and similar ECR actions. If those credentials leak, the blast radius is limited.

Use root only for account-level tasks

There are legitimate reasons to use the root account. These are rare, and they're all account-level administrative operations:

• Change the email address associated with the account
• Change the AWS support plan (switching from Developer to Business or Enterprise)
• Close the AWS account
• Enable MFA Delete on S3 buckets (requires root MFA)
• Modify CloudFront distributions with certain configurations
• Restore IAM permissions if you've accidentally locked yourself out with an overly restrictive policy

Everything else should go through IAM users and roles. Your day-to-day operations, your CI/CD pipelines, your Lambda functions, your team members — all of these should use IAM identities with scoped permissions.

A real example: A team member needs to manage S3 buckets but shouldn't be able to delete RDS databases or modify billing. Create an IAM user for them with a custom policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket/*",
        "arn:aws:s3:::my-bucket"
      ]
    }
  ]
}

This user can work with that specific S3 bucket and nothing else. The blast radius of credential compromise is minimal.

Set alternate contacts for billing and security

AWS allows you to specify alternate contacts for your account. These are email addresses that receive notifications about billing, security events, and account issues — independently from the root email address.

Why does this matter? If your primary email is tied up in an incident or becomes unavailable, you need a way to be notified and to act. AWS can also contact alternate contacts during security events.

Set up alternate contacts in the AWS Console:

1. Sign in as root (yes, only root can modify this)
2. Go to Account > Account Settings
3. Under Alternate Contacts, add an email for Billing Contact and Security Contact
4. Verify the email addresses by clicking the confirmation links AWS sends

Best practice: Use a distribution list or shared mailbox for these contacts, not a single individual's email. When an engineer leaves, that account notification doesn't disappear with them.

Real scenario: A company's billing contact was a team lead who left unexpectedly. Months later, AWS needed to notify them about suspicious activity in the account. The email bounced, and nobody on the remaining team saw the warning. By the time they noticed unauthorized instances running, the damage was already done. A shared security contact email would have caught this.

Common mistakes

Mistake 1: Storing root credentials in a shared password manager. Password managers are convenient but they're still a single point of failure. If the password manager is compromised, so is your root account. Keep root credentials offline or in a dedicated, encrypted vault with minimal access.

Mistake 2: Sharing the root email address as a team contact. The root email is the recovery path for your entire account. If team members are using it for everyday communications or support tickets, you risk exposing the account identity or having the inbox flooded so you miss critical AWS notifications.

Mistake 3: Deleting root access keys but thinking you're done. Deleting root access keys is necessary but not sufficient. You still need MFA on the root user, a strong password, and a commitment not to use it for routine operations. Security is layered.

Mistake 4: Enabling MFA on root but losing the seed/backup codes. If your phone is lost or your authenticator app is uninstalled, you'll need those backup codes to regain access. Losing them means a lengthy AWS Support case and potential account lockout. Store them securely and separately from the authenticator itself.

Key takeaways

• Enable MFA on root immediately, using an authenticator app and storing backup codes in a secure vault
• Audit your account for root access keys and delete any that exist; programmatic access should use IAM users or roles
• Reserve root account access for account-level tasks only (email changes, support plan updates, account closure, MFA Delete on S3)
• Set alternate contacts for billing and security notifications so you're alerted even if the primary email is compromised
• Use IAM users and roles with least-privilege policies for all developers, CI/CD systems, and applications
• Treat root credentials as a break-glass emergency access method, not a day-to-day credential