Nov 26, 2025

Centralised Root Access Management in AWS Organizations: Reducing Risk and Operational Overhead

Morten Jensen

9 minutes read

Centralised Root Access Management in AWS Organizations

Background

Over the years, we have helped organisations scale their AWS footprint securely. As the number of AWS accounts grows within an AWS Organization, managing root account credentials becomes increasingly challenging from both security and operational perspectives.

Traditionally, when a new AWS account is created in an AWS Organization - whether through AWS Control Tower or otherwise - a root user account is implicitly created. By default, the root account’s credentials are “undefined” and must be recovered via an email confirmation process. This approach doesn’t scale well and introduces security concerns.

AWS has now released centralised root access management for AWS Organizations member accounts, which seeks to reduce root user access overheads whilst making management easier and more secure.

In this blog post we describe how centralised root access management works, how to enable it and the operational considerations when adopting this feature.

Understanding the Root Account Challenge

As organisations scale their AWS account footprint, management of root accounts becomes progressively harder whilst also needing to mitigate security concerns. Root accounts may occasionally be needed for specific privileged actions that cannot be performed by IAM users or roles.

Traditional root account management presents several risks:

Email interception: Emails could be intercepted and unauthorised parties may be able to recover passwords
Credential sprawl: Each account requires password recovery, MFA configuration and secure storage of credentials - adding significant account vending overhead and security risks
Inconsistent security posture: Managing hundreds or thousands of root credentials consistently is practically impossible
Compliance challenges: Discovering and auditing root credentials across member accounts becomes increasingly difficult

How Centralised Root Access Management Works

Centralised root access management addresses these challenges for member accounts by enabling you to:

Remove long-term root user credentials from member accounts
Recover root user credentials centrally if ever required
Prevent in-account root user credential recovery
Provision secure-by-default member accounts with no root access configured
Stay compliant by being able to discover root credentials across member accounts
Provide a mechanism to carry out specific root privileged actions that cannot be carried out by IAM principals, including deleting S3 bucket policies and SQS queue policies when principals have been accidentally denied

Architecture Overview

The centralised root access management architecture consists of:

AWS Organizations Management Account: Where root access management is configured and controlled
Delegated Administrator Account (Optional): A designated security account that can manage root access without requiring access to the management account
Member Accounts: AWS accounts in the organization with centrally-managed root access
Privileged Operations: Specific root-level actions that can be performed centrally, including S3 bucket policy removal, SQS queue policy removal and root credential management

Enabling Root Access Management

Enabling centralised root access management can be accomplished from the AWS Console under IAM Root access management.

Prerequisites

Root access management requires trusted access for AWS IAM in AWS Organizations. If you are using AWS Control Tower, this is already enabled.

Configuration Steps

When enabling central root access management you can optionally assign a delegated administrator account, which reduces the need to access the AWS Organizations management account for root-related operations. This function can be delegated to a separate “Security” account, following the principle of least privilege.

Importantly, it is possible to enable centralised root access management without affecting existing AWS Organizations accounts’ root credentials. What this means is that newly vended AWS member accounts will not have a root access login profile configured, whilst existing accounts remain unchanged until you explicitly manage them.

Privileged Actions

When root access management is enabled, privileged actions can be taken either from the AWS Organizations management account or from a delegated root access management account.

The following privileged actions are available:

Delete root user credentials: Remove access keys, passwords, signing certificates and Multi-Factor Authentication devices from the member account’s root user. The time since the console password was last used is shown. Once deleted, root credentials cannot be recovered by the standard password recovery flow.
Delete S3 bucket policy: Remove a bucket policy that may have accidentally denied all principals
Delete SQS queue policy: Remove a queue policy that may have accidentally denied all principals
Allow root user recovery: Enable password recovery for a member account (only available if the member account has no root user credentials configured)

It is important to note that a privileged action isn’t any and all root actions - it’s a specific set of actions listed above. Some operations still require direct access to the root user and for those actions it’s possible to reinstate root user credentials in a given account centrally.

Note that no privileged actions can be taken on the AWS Organizations management account itself.

Taking Privileged Actions

There are three methods to take privileged actions:

AWS Console

From IAM, choose Root access management, then pick the account from the Organizations hierarchy and click Take privileged action. This offers three actions:

Delete S3 bucket policy
Delete SQS queue policy
Delete root user credentials (or Allow password recovery)

AWS CLI

Use the aws sts assume-root command with the following parameters:

--target-principal <account-id>
--task-policy-arn with one of the following task policies:
- arn:aws:iam::aws:policy/root-task/IAMAuditRootUserCredentials
- arn:aws:iam::aws:policy/root-task/IAMCreateRootUserPassword
- arn:aws:iam::aws:policy/root-task/IAMDeleteRootUserCredentials
- arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy
- arn:aws:iam::aws:policy/root-task/SQSUnlockQueuePolicy
--duration-seconds <seconds> (maximum 900 seconds)

Then use the returned credentials to perform IAM operations as the member account’s root user.

AWS API

The AssumeRoot API is available for programmatic access. This enables automation including potentially auto-disabling root credentials after a set time so that it isn’t forgotten.

Allowing and Recovering Root Passwords

When root credentials are deleted, it is not possible to recover the root account and set a new password unless Allow password recovery has been enabled for the account in question from the AWS Organizations management account.

Password Recovery Process

When allowing root password recovery for an AWS account, the standard AWS root password recovery routine can be used:

Navigate to https://aws.amazon.com/console/
Click Sign in using root user email
Enter the root email address
Select Forgot password?
Complete the CAPTCHA
An email will be sent containing a URL to reset the password
Set a new password and confirm it

At this point, login can be achieved using the new credentials. Once username and password have been entered, login will send a verification challenge email with a link. Without link confirmation, it is not possible to login.

The root account will have 35 days to configure MFA. Optionally, it is possible to implement an IAM policy condition to prevent some root “write” activities until MFA has been configured (whilst allowing the MFA setup itself to avoid a catch-22 situation).

Best Practice: Temporary Root Access

The strong recommendation is that once the task requiring root access has been completed, the root credentials are deleted again - perhaps automatically after a time period of a number of hours using scheduled automation.

The advantage of centralised root credentials management across an Organization is that by default it will not be possible to login or to recover root passwords because all member account root credentials can be deleted across the Organization. This means requiring storage of only a single set of credentials for the entire AWS Organization (for the management account), with the option of having an additional fallback mechanism in place.

Deleting Root Credentials via CLI

From an AWS CLI perspective, the process to delete root credentials demonstrates that it is possible to automate the root credentials deletion process, for instance based on the root LoginProfile CreateDate or the root user PasswordLastUsed date fields.

First, from the AWS Organizations management account, assume the root user of a member account (requires sts:AssumeRoot permission):

CREDS=$(aws sts assume-root \
    --target-principal 987654321098 \
    --task-policy-arn arn:aws:iam::aws:policy/root-task/IAMDeleteRootUserCredentials \
    --duration-seconds 900)

export AWS_ACCESS_KEY_ID=$(echo $CREDS | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo $CREDS | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo $CREDS | jq -r '.Credentials.SessionToken')

# Ensure that credentials were properly exported
aws sts get-caller-identity

# Get member account root user details
aws iam get-user
{
  "User": {
    "UserName": "root",
    "UserId": "987654321098",
    "Arn": "arn:aws:iam::987654321098:root",
    "CreateDate": "2025-03-15T10:23:45+00:00",
    "PasswordLastUsed": "2025-11-20T14:32:18+00:00"
  }
}

# Get member account root user login profile
aws iam get-login-profile

{
  "LoginProfile": {
    "UserName": "root",
    "CreateDate": "2025-03-15T10:45:22+00:00",
    "PasswordResetRequired": false
  }
}

# List any access keys
aws iam list-access-keys

{
  "AccessKeyMetadata": []
}

# List signing certificates
aws iam list-signing-certificates

{
  "Certificates": []
}

# List MFA devices
aws iam list-mfa-devices

{
  "MFADevices": [{
    "UserName": "root",
    "SerialNumber": "arn:aws:iam::987654321098:mfa/root-account-mfa-device",
    "EnableDate": "2025-03-15T11:02:33+00:00"
  }]
}

# Deactivate the MFA device
aws iam deactivate-mfa-device \
    --serial-number arn:aws:iam::987654321098:mfa/root-account-mfa-device

# Delete login profile of current user (root)
aws iam delete-login-profile

# This will now fail
aws iam get-login-profile

Note that to allow password recovery, aws iam create-login-profile needs to be run as the member account root user after aws sts assume-root to the member account with the IAMCreateRootUserPassword task policy.

Protection Against In-Account Recovery

Once root credentials are deleted centrally, if password recovery is attempted from the member account, this will fail at the point that the verification challenge email link is clicked, with the following error:

“Password recovery failed. Password recovery is disabled for your AWS account. Please contact your administrator for further assistance.”

This provides strong protection against unauthorised root access attempts.

Operational Considerations

Not All Root Actions Are Covered

Not all actions that require root access are possible with centralised root access management’s privileged actions. For these cases, root credentials recovery may be required.

Following use, removal of the credentials could be automated using a scheduled script or Lambda function to periodically check for member account root credentials and delete root credentials after a grace period.

Time Lag with Credential Deletion

One caveat appears to be either a time lag - or a need to login as the root account - between allowing password recovery, then recovering the password and finally deleting the root credentials again. In testing, invalid MFA device errors occurred when attempting to delete root credentials immediately after recovery. After a 10-15 minutes of time and after having logged in as the root user in the account following password recovery, the delete root credentials operation worked successfully.

Conclusion

Centralising root access management reduces the attack surface and makes member accounts more secure by default. It addresses the operational and security challenges that arise when managing root accounts at scale in AWS Organizations.

Enabling root access management is straightforward and provides immediate benefits:

Reduced credential sprawl across the organisation
Simplified compliance and audit requirements
Protection against unauthorised root access
Operational efficiency through centralised management

By combining centralised root access management with automation to remove any temporary root credentials on a schedule, organisations can maintain a robust security posture whilst retaining the ability to perform privileged operations when genuinely required.