Five AWS account mistakes small teams make

Small teams often set up an AWS account in an afternoon and never go back to the security settings. This post lists five mistakes to check for in your own account. They are not a ranking of "the most common". They are five things that are easy to check and that AWS's own guidance covers.

Each section gives the problem and the exact steps to fix it. Near the end there is a short check you can run today and a monthly routine. Console wording changes from time to time, so if a label differs on your screen, follow the AWS documentation linked in that step. Use this only on AWS accounts you own or have written permission to review.

Using the root login for daily work

When you create an AWS account, you start with a root user that has complete access to everything, including billing. AWS's root user best practices (opens in a new tab) strongly recommend that you do not use it unless a task requires it, and that you create an administrative user for everyday work instead.

What to check and fix

1. Ask the team who signs in as root. If the answer is "everyone" or "the developer", that needs to change.
2. Create an administrative identity for daily use. For a single account, AWS suggests IAM roles for temporary credentials. For several accounts under AWS Organizations, AWS recommends IAM Identity Center workforce users.
3. Check that the root user has no access keys. AWS says not to create them. In the IAM console, open the Security credentials page for the root user and confirm no keys are listed.
4. Change the root email to a business-managed group address that forwards to several people, as AWS advises. Then, if one person leaves or is ill, nobody is locked out.
5. Store the root password in a password manager that does not depend on that same AWS account.

No MFA on root and admin users

Multi-factor authentication (MFA) means a password alone is not enough. AWS says all account types require MFA for the root user, and that users must register MFA within 35 days of their first console sign-in attempt if it is not already on. AWS also recommends MFA for IAM users.

What to do

1. Sign in as root, open the security credentials page, and add an MFA device under the MFA section.
2. Register more than one device. AWS says you can register up to eight MFA devices for the root user, and strongly recommends more than one for resilience.
3. Open the IAM console, then Users, and check each user. The IAM Credential report has a column called mfa_active, which shows TRUE or FALSE for every user.

Hardware key or app: the plain trade-off

AWS recommends phishing-resistant MFA, such as passkeys and security keys, wherever possible. It also supports a virtual authenticator app and a hardware TOTP token.

For the root user and any administrator, use a security key if you can, and register a second method as a backup. For others, an app is far better than nothing.

"Temporary" admin rights that stay

Someone needed to fix a problem, so a user or role got the broad AdministratorAccess permission. Months later it is still there. AWS recommends least privilege: grant only the permissions required for a task. It admits that you may start broad while you work out what you need, and says to reduce them as your use case matures.

What to do

1. In the IAM console, open Users, then each user's Permissions tab, and note who has administrator-level policies.
2. For each, ask whether the person needs it every day. If not, remove it and give a narrower policy, or have them assume an admin role only when required.
3. Use IAM's last accessed information to see which services a user or role actually uses. AWS provides this to help you remove permissions that are never used.
4. For roles that already run workloads, AWS says IAM Access Analyzer can generate a fine-grained policy from the access activity logged in CloudTrail. Test the generated policy before you use it.
5. When access is meant to be short, write down who has it, why, and the date to remove it. Review that list monthly.

If you have more than one AWS account, AWS recommends IAM Identity Center for central access management.

Long-lived access keys, and keys in code

An access key is a long-lived password for programs. If one ends up in a code repository, a chat message or a laptop that is stolen, whoever finds it may use it from anywhere until you disable it. AWS says to prefer temporary credentials. Applications that run on AWS compute, such as EC2 or Lambda, can use an IAM role, so no key needs to be stored at all.

What to do

1. In the IAM console, open Users. If the Access key age column is missing, use the settings icon above the table, choose Manage columns, and select it. The column shows the number of days since the oldest active access key was created.
2. Open a user's Security credentials tab and read Last used for each key. A key that has not been used for a long time is a candidate for removal.
3. To replace a key without breaking an app, follow AWS's access key update steps (opens in a new tab). In short, create the second key, move the app to it, then deactivate the old key, test, and only then delete it. A user can hold two keys at once to allow this.
4. Search your code, build settings and shared documents for key IDs. If you find a key, treat it as exposed. Create a replacement, deactivate the old key, and then delete it.
5. Move apps to roles wherever you can. Use keys only where AWS says roles cannot work, and rotate them when staff leave.

Old users and roles nobody removed

People leave, agencies finish, and test users pile up. Each unused identity is an unmonitored way in. AWS recommends reviewing and removing unused users, roles, permissions, policies and credentials, and says IAM's last accessed information helps you find them.

What to do

1. In the IAM console, choose Credential report, then Download Report. AWS says you can generate one as often as every four hours.
2. Open the CSV in a spreadsheet. For each user, check password_last_used, access_key_1_last_used_date and access_key_2_last_used_date. Those with no recent use, or N/A, are candidates.
3. Match the list against your staff and supplier list. Remove anyone who no longer works with you. A safe order is to disable the credentials first, wait to see whether anything breaks, then delete.
4. Do the same for roles under Roles, checking their last activity.

A short check you can do today

Set aside some uninterrupted time and work down this list. Tick each line or write down who will fix it.

• The team knows root is not for daily use, and the root email goes to a group
• Root has MFA and no access keys
• Every human user has MFA (check mfa_active in the credential report)
• The list of administrators fits on one page and each has a reason
• No access key is unused or unexplained
• No key sits in code, chat or shared documents
• Everyone in the credential report still works with you

A monthly routine

Put one recurring entry in the calendar for the first working day of the month, owned by a named person:

1. Download the credential report and compare it with the people list.
2. Review the list of administrators and short-term access.
3. Check Access key age and Last used.
4. Remove, then write down what you changed and the date.

When a cloud security review is worth it

A self-check catches the basics. A review helps when you run several accounts, when you do not know who has access to what, when you handle customer data, or when you have never had anyone outside the team look at the setup.

Our cloud security review is done only on accounts you own, with your written permission. We rank findings by risk, give a clear fix for each one, and re-test after the fixes.