AWS Account Security Checklist

Chapter 1 of 8 · 6 checks · 4 min

The root user

Checks that the one identity with unlimited power over the account is locked away, protected by MFA and watched.

Show
  1. The root user has MFA, ideally more than one deviceMust

    Why it matters and how to check

    The root user can do anything in the account, including closing it and changing billing. AWS now requires MFA for the root user of every account type, with registration enforced within 35 days of the first console sign-in attempt if it is not already set up. AWS recommends registering more than one device (up to eight are allowed) so losing one does not lock you out, and prefers phishing-resistant FIDO security keys or passkeys.

    To verify: run aws iam get-account-summary and check that AccountMFAEnabled is 1. In the console, open Security credentials as root and confirm at least two MFA devices are listed, stored in different places.

    Example

    Shell
    aws iam get-account-summary \
  --query 'SummaryMap.{RootMFA:AccountMFAEnabled,RootKeys:AccountAccessKeysPresent}'
# expect: RootMFA 1, RootKeys 0
  2. The root user has no access keysMust

    Why it matters and how to check

    A root access key is a permanent credential with full access to everything, including billing. AWS strongly recommends never creating one. For the rare root task that needs the CLI, AWS now suggests aws login with root credentials, which issues temporary, automatically rotated credentials instead.

    To verify: AccountAccessKeysPresent from aws iam get-account-summary must be 0. The credential report (see the human access chapter) also shows access_key_1_active and access_key_2_active for the <root_account> row. If a root key exists, find what uses it from CloudTrail, move that use to a role, and delete the key.

  3. Root is used only for tasks that require it, and its email is a group addressShould

    Why it matters and how to check

    Daily work as root means every mistake is unlimited and every action is logged as the same identity. AWS recommends an administrative user for everyday tasks and the root user only for the short list of tasks that need it. AWS also recommends that the root email be a business-managed group address used for nothing else, so account notices still reach someone when one person is away or leaves.

    To verify: search CloudTrail for root activity in the last 90 days, for example with the console's Event history filtered by user name root. Each event should match a known root task. Check that the root email is a distribution list your company controls, not a personal mailbox.

  4. Root recovery channels are controlled by different peopleShould

    Why it matters and how to check

    Root password recovery goes through the account's email and phone number. AWS recommends that no single person controls both, with one group holding the primary email and another the primary phone number, and multi-person approval for root sign-in where possible (for example one group holds the password, another the MFA device).

    To verify: write down who has access to the root mailbox, the root password store, the MFA devices and the account phone number. No one person should appear in every column. Confirm the phone number on the account is current under Account settings, and that the password is not stored only in a tool that itself runs in this AWS account.

  5. In AWS Organizations, member account root credentials are removed or restrictedShould

    Why it matters and how to check

    Every account in an organization has its own root user. AWS recommends centralizing root access: remove member accounts' root passwords, access keys and MFA, so nobody can sign in as root there, and perform the rare root tasks from the management account with privileged root sessions. Where root credentials stay, AWS suggests an SCP that denies root actions in member accounts.

    To verify: in the IAM console of the management account, check that centralized root access is enabled for member accounts. For each member account, confirm root credentials are absent, or that an SCP denying root user actions is attached to its organizational unit. AWS Config root MFA rules report removed credentials as not applicable, which is expected.

  6. Any root sign-in or root API call sends an alert to a personMust

    Why it matters and how to check

    Root use should be rare enough that every occurrence is worth a look. AWS recommends alerts on root sign-in and usage, using an EventBridge rule with an SNS notification, or GuardDuty's root credential usage finding if you already run GuardDuty. AWS also says responders should have a procedure to confirm whether the use was expected and how to escalate.

    To verify: list EventBridge rules with aws events list-rules and find one matching root userIdentity.type. Sign in as root once during a planned change and confirm the alert reaches the right people within minutes.

    Example

    JSON
    {
  "detail-type": ["AWS Console Sign In via CloudTrail", "AWS API Call via CloudTrail"],
  "detail": { "userIdentity": { "type": ["Root"] } }
}