chrisdunne.com

The AWS Security Checklist

Protect the root user credentials

Access to the root user account equates to the keys to the kingdom, the root user has unrestricted access to every service and resources within the AWS account.

Chapter
2
Progress
2 of 4
Time
3 min read
Updated
28 Mar 2025

Access to the root user account equates to the keys to the kingdom, the root user has unrestricted access to every service and resources within the AWS account. It’s important to protect access to the root user account, and the following options can ensure you can mitigate the risk while allowing for break glass access in the worst case scenarios.

Ensure that no access keys are created for the root user, if you already have access keys attached make sure to remove them. Only use the root account for changing configuration that only the root user can, such as enabling AWS support plans. There is no need for the root account to have API access. You should delegate access to IAM Roles, which can be leveraged by specific principals with the relevant trust policies attached.

Make sure to enable Multi-Factor Authentication (MFA) for the root user account. For an individual running their own AWS accounts a virtual device might be sufficient, but if your root user is for business AWS accounts I recommend using a hardware-based MFA device. You should store the hardware MFA device in a secure location, preferably a safe deposit box which only well-trusted individuals within the business can access - such as the Chief Technology Officer (CTO) and Chief Information Security Officer (CISO).

Use multi-user approved sign-in for the root user account. This is an administrative control where you separate who has access to the MFA device and who has the login credentials for the root user. In the MFA example above we have the CTO and CISO with access to the MFA device, but we wouldn’t want them to have the login credentials. A platform team might be the custodians of the login credentials in a password manager, and would need the CTO or CISO to access the account. This provides an extra level of protection, which may be suitable for companies with a low risk tolerance.

Store the root user credentials in a password manager. By using a password manager you can be restrictive over who has access to the credentials, but not tie them to an individual. It also allows for the password to be as complex as possible without anyone needing to remember it.

If you’re using AWS Organizations with multiple accounts you can now leverage a single root user account, instead of the old way of having a root user for every AWS account.

If you’re using multiple root users across your organization you can implement Service Control Policies (SCPs), which can restrict the root users from performing certain actions in all but the Management account.

Monitor root user activity. By enabling AWS CloudTrail in your account you can capture all API requests which interact with your AWS account, these events can be sent to Amazon CloudWatch for analysis. Within CloudWatch you can create an Event Rule which passes events to SNS through a Lambda or setup a CloudWatch Alarm based on a custom metric taken from the CloudTrail logs.

Utilise Amazon GuardDuty to create findings relating to root user usage. GuardDuty is used for threat detection, with continuous monitoring capabilities. If you’re using GuardDuty it will analyse various log sources within your account, including CloudTrail logs, and there is a finding type within GuardDuty in relation to root user activity “Policy:IAMUser/RootCredentialUsage”, and it will trigger any time the root user is used to invoke an API within your account.

Useful resources