Cloud LabsLabsBeginner

Lab: securing an AWS account with IAM users and MFA

By Mohamed Fayas 9 min readUpdated 8 October 2026

In short: The root user of an AWS account can do anything, including close the account. In this lab you protect it with MFA and stop using it, create an admin group and a personal IAM user with MFA, set a password policy and use a credential report to check your work.

Aim and what you need

The aim is to follow the first rule of AWS security: protect the root user and do daily work through a separate identity with only the permissions it needs. IAM (Identity and Access Management) is the free AWS service that controls who can do what.

Your own AWS account with a budget already set (see using cloud free tiers safely).
An authenticator app or a FIDO2 security key or passkey.
The AWS CLI version 2, configured temporarily as described below. About 45 minutes. IAM itself has no charge.

Figure 1. The root user is protected and unused; daily work happens through an IAM user in a group, protected by MFA.

Steps

Sign in as root. Open Security credentials and assign an MFA device. A passkey or security key resists phishing better than an app code. Confirm there are no root access keys; if there are, delete them.
Open IAM and create a group Admins with the AWS managed policy AdministratorAccess.
Create an IAM user for yourself with console access and a strong password, and add it to the group. Note the account sign-in URL.
Sign out of root, sign in as the IAM user and assign an MFA device to it.
Set an account password policy.
From now on, use root only for the few tasks that need it, such as changing account settings.

Steps 2 to 5 can also be scripted with the CLI, which is useful when you set up a second lab account or more users later. Run the commands as an existing admin identity, preferably with short-lived credentials (for example from aws configure sso) rather than long-lived access keys.

aws iam create-group --group-name Admins
aws iam attach-group-policy --group-name Admins --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
aws iam create-user --user-name lab-admin
aws iam add-user-to-group --user-name lab-admin --group-name Admins
aws iam create-login-profile --user-name lab-admin --password '<temporary-strong-password>' --password-reset-required
aws iam create-virtual-mfa-device --virtual-mfa-device-name lab-admin-mfa --outfile lab-admin-qr.png --bootstrap-method QRCodePNG
aws iam enable-mfa-device --user-name lab-admin --serial-number arn:aws:iam::<account-id>:mfa/lab-admin-mfa --authentication-code1 <code1> --authentication-code2 <code2>
aws iam update-account-password-policy --minimum-password-length 14 --require-symbols --require-numbers --require-uppercase-characters --require-lowercase-characters --password-reuse-prevention 5

Delete the QR code image as soon as the MFA device is enabled; anyone with it could clone your MFA.

Figure 2. IAM users are simple for a single lab account; organisations should use IAM Identity Center with temporary credentials.

How to verify

The IAM dashboard should show no security warnings for root MFA. The account summary should report root MFA as enabled (value 1) and zero root access keys. Generate a credential report: it is a CSV file listing every user with columns for password use, MFA status and key age. Every user with a password should show MFA as true. Finally, sign in as lab-admin in a private browser window and confirm you are asked for MFA.

aws iam get-account-summary --query "SummaryMap.[AccountMFAEnabled,AccountAccessKeysPresent]"
aws iam list-mfa-devices --user-name lab-admin
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csv

Troubleshooting and clean-up

MFA codes rejected: the phone clock is wrong. Turn on automatic time, then enter two consecutive codes.
Cannot see billing as an IAM user: root must enable IAM access to billing information in account settings.
Lost MFA device: another admin can remove it, and for root AWS offers an identity-verification recovery process. Registering two MFA devices (supported for root and IAM users) avoids the problem.
Access denied: check the group policy is attached and you are signed in as the right user.

Keep this setup: it is the foundation for every other AWS lab. If you created access keys for the CLI, deactivate and delete them when you finish, and review the credential report monthly. At work, you would go further with IAM Identity Center, permission boundaries and least-privilege roles.

Practice

Why should you not use the root user for daily work?

It has unrestricted power that cannot be limited by IAM policies, so a stolen root session is the worst possible compromise.

What does the IAM credential report show?

Each user with password, MFA and access key status, including when they were last used and rotated.

Why grant permissions to a group rather than directly to a user?

It is easier to manage and audit: people join or leave groups, and permissions stay consistent.

Key takeaways

Put MFA on root, delete root access keys and stop using root.
Give permissions to groups, then add users to groups.
Every IAM user with a password should have MFA.
Use the credential report and account summary to prove it.
Prefer IAM Identity Center and short-lived credentials at work.

Tracks your learning on this device only. See your progress on the learning paths.

About the author

Mohamed Fayas

Founder of FM TecHub. CCNA certified, with a BTEC HND in Network Engineering, and BEng (Hons) in Computer Networking and Cloud Security. He writes practical, plain-English guides on networking, security and cloud.

More about the author