Short answer: Sign in as root, open the account menu → Security credentials, and under Multi-factor authentication click Assign MFA device. Register a hardware security key as the first device and a second one as backup — AWS now supports multiple MFA devices per user. Then stop using the root account entirely: create an IAM user or Identity Center user for daily work and lock the root credentials away.
Why the root account is a special case
The AWS root user has unlimited power over the account. It can delete every resource, change billing, close the account, and override any IAM policy you have written. No permission boundary applies to it.
Which means a compromised root account is not an incident you contain — it is one you survive or you do not. The well-known failure pattern is an attacker spinning up expensive compute for crypto mining, running up an enormous bill in hours, while also having the access needed to delete the logs and backups that would help you recover.
AWS has been tightening this steadily: MFA is now mandatory for root users on standalone accounts and management accounts. If you have not done it yet, you will be prompted, and eventually blocked.
Step 1: Add MFA to the root user
- Sign in to the AWS console as root (the email address the account was created with).
- Click your account name (top right) → Security credentials.
- Under Multi-factor authentication (MFA), click Assign MFA device.
- Give the device a name and choose a type.
Your options:
- Passkey or security key (FIDO2) — the strongest, and the right choice. Phishing-resistant because the credential is bound to the AWS domain. See hardware security keys.
- Authenticator app (TOTP) — solid, and fine if hardware is not available. Any standard app works: what is an authenticator app.
- Hardware TOTP token — a physical display token, used in environments where phones are not permitted.
Register two devices. AWS supports up to eight MFA devices per root user, and root account recovery without MFA is a genuinely painful process involving the registered email and phone. Two keys, stored separately, removes that risk entirely — see which security key to buy.
If you use TOTP, do not screenshot the QR code; store the setup key offline instead, and enrol a second device while it is on screen. See what’s inside a 2FA QR code.
Step 2: Then stop using root
This is the actual security advice, and MFA is only the prerequisite.
The root account should be used for a handful of tasks only — changing the account email, closing the account, changing support plans, restoring a broken IAM configuration. Everything else should happen through an IAM Identity Center user or an IAM user with appropriate permissions.
- Create an administrative user in IAM Identity Center (or an IAM user with AdministratorAccess if you are not using Identity Center).
- Add MFA to that user too — a security key, ideally.
- Delete any root access keys. Root should have no programmatic credentials at all. Check under Security credentials and remove them if present.
- Store the root password in a password manager or a physical safe, along with a backup MFA device.
- Set the root email to a monitored distribution address rather than one person’s inbox, so the account is not lost when someone leaves.
Step 3: Extend MFA across the account
Root MFA protects one door. The rest of the estate needs the same treatment:
- Enforce MFA for all IAM users with an IAM policy that denies actions unless MFA is present.
- Prefer IAM Identity Center with SSO over long-lived IAM users, so authentication happens at your identity provider — see what is single sign-on and enforcing 2FA in Workspace.
- Rotate and scope access keys. Long-lived keys in CI systems and laptops are the most common real-world AWS compromise — they bypass MFA completely, because the API does not prompt.
- Use IAM roles rather than static credentials wherever possible.
- Turn on CloudTrail across all regions and protect the log bucket, so an intrusion leaves evidence.
- Set billing alarms. Not glamorous, but a cost spike is often the first sign of compromise, and it is the difference between a $500 surprise and a $50,000 one.
- Enable GuardDuty for automated detection of unusual API activity.
The credential leak problem
Most AWS compromises are not login attacks. They are access keys committed to a public repository, embedded in a mobile app, or left in a Docker image.
Automated scanners find keys in public repos within minutes. MFA on your console login does nothing about this, because the API call never sees a login screen.
So: no root access keys ever, scoped and rotated keys for everything else, secrets in a secrets manager rather than in environment files, and pre-commit scanning to catch mistakes before they are pushed. The same principle applies at Cloudflare and Stripe, where API tokens are equally independent of your 2FA.
Frequently asked questions
Is MFA mandatory on AWS root accounts now?
AWS has been rolling out mandatory MFA for root users, starting with standalone accounts and management accounts. Assume it applies to you and enrol before you are forced to.
What if I lose my MFA device?
Use your second registered device — which is why you register two. Without one, root recovery requires access to the registered email and phone and can take time. See recovering after device loss.
Can I use the same authenticator app as my other accounts?
Yes, though for an account of this consequence a dedicated hardware key is a better choice. If you use an app, make sure it is backed up — how to back up your authenticator app. The equivalent question for hardware is covered in can one security key cover all your accounts.
Why is my TOTP code rejected?
Usually clock drift. AWS is strict about time windows. Turn on automatic network time — why 2FA codes get rejected.
Do I need MFA if I only use the CLI?
Yes for the console, and you should also require MFA for sensitive CLI actions via IAM policy conditions. Access keys alone are a standing bypass otherwise.
What about AWS Organizations member accounts?
Each member account has its own root user. Secure them all, or better, prevent root use entirely with service control policies and manage access centrally through Identity Center.
The bottom line
Two security keys on the root user, no root access keys, and then never sign in as root again. MFA is the prerequisite; the real protection is that the all-powerful credential sits unused in a safe while your daily work happens through a scoped, monitored identity — and that your access keys are short-lived enough not to matter when one leaks.
Securing the rest of your infrastructure? See Cloudflare and your domain registrar.
One Response