How to Manage 2FA for a Shared AWS Account

Nobody should be signing in to AWS with a shared login. Day-to-day access belongs to per-person identities through IAM Identity Center, and automation belongs to roles rather than to anything a human types.

That leaves the root user, which is genuinely one credential per account. The useful thing to know is that you do not have to share its second factor either: AWS lets you register several MFA devices on the root user, so two or three administrators can each enrol their own. Copying a TOTP secret around is a fallback for the cases where that is not available, not the default.

Three different credentials

“Our AWS account” usually means one of three things, and they have different answers.

The root user. One per account, identified by an email address, able to do everything including closing the account and changing billing. Not for daily work.

Per-person identities. IAM Identity Center users, or IAM users on older setups. This is where the actual work happens, and where each person has their own second factor.

Access keys. Long-lived credentials for programmatic access. Not a login, not protected by MFA in the way people assume, and the thing most likely to be sitting in an old repository.

Most “shared AWS 2FA” questions are really about the first, asked because the second and third were never set up.

Daily work: per-person identities

IAM Identity Center gives each person their own sign-in, their own MFA, and short-lived credentials into the accounts and roles they are entitled to. Access is granted by assignment rather than by handing anything over, and removing someone is one action in one place regardless of how many AWS accounts you run.

If you are still on IAM users, the minimum is one user per person, each with their own MFA device, and no shared user for the team. A shared IAM user has all the problems of a shared root user with none of the reasons.

For an agency working in a client’s account, the equivalent of “please invite me” is a cross-account role: the client keeps ownership and can revoke it in one place, and nobody emails credentials.

Automation: roles, not logins

Anything running unattended should assume a role rather than sign in. On AWS itself that means instance profiles, task roles or OIDC federation from your CI provider. Those are short-lived credentials, with no secret to store and nothing for a human to type.

If a script is prompting someone for a six-digit code, it is using a human’s identity, and it will break the day that human leaves.

Long-lived access keys are the other half of this. They are revocable and rotatable individually, which is a genuine advantage over a TOTP secret, but they are also the credential that leaks in commits. Keep them scarce and rotate them on a schedule you actually follow.

The root user: the real shared account

Root exists, several people need to be able to reach it, and it must not be a single person’s phone. Four things settle it.

Register more than one MFA device

This is the AWS-specific answer and it removes the sharing question entirely. Enrol the authenticator or hardware key of each administrator who should be able to act as root. Each device holds its own secret, and no secret is ever copied. Offboarding is deregistering one device, not resetting the account’s 2FA and re-enrolling everyone.

Where a hardware key is an option, this is where it earns its price: the second factor cannot be screenshotted, forwarded or synced.

Point the root email at a mailbox two people can read

Root recovery goes through that address. A founder’s personal inbox makes the account unrecoverable the day they are gone, so use a distribution list or a shared mailbox, and make sure whoever can read it is someone you would trust to recover the account, because functionally that is what the address grants.

Delete root access keys

There should be none. If any exist, they are a shared credential with no MFA in front of them, which is worse than anything else in this article.

Watch for root sign-ins

CloudTrail records them, and an alarm on root usage is standard practice. On a healthy account root sign-ins are rare and explainable, which makes them cheap to alert on and valuable to see.

When a shared TOTP secret is still the answer

Multiple MFA devices cover most cases. A few resist:

• A client’s account you do not administer, where you are handed credentials and cannot restructure anything.
• Older or third-party consoles around AWS (a billing portal, a reseller panel, a monitoring vendor) that allow exactly one TOTP enrolment.
• A break-glass credential your process requires several people to be able to use at short notice, where per-person devices are not practical.

For those, the requirements are the same as any shared account: one custody of the secret, code access granted per person, a log of who read a code, and recovery codes stored outside the account they recover. The reasoning is in how to share 2FA codes with your team securely, and the comparison of mechanisms in best ways to manage 2FA for shared accounts. The same reasoning applied to a payment provider is in how to manage 2FA for a shared Stripe account.

A break-glass procedure worth writing down

For root, and for anything else that only gets used in an emergency:

1. Who may use it, by name, and what triggers that.
2. Where the credential and its second factor live, and how many people can reach each.
3. Where the recovery codes are, outside the account they recover.
4. What gets alerted when it is used, which is the CloudTrail alarm above.
5. What happens afterwards: who is told, what gets reviewed, whether anything is rotated.
6. When it was last tested. An untested break-glass procedure is a plan you have chosen to discover under pressure.

Offboarding an AWS account

1. Remove their Identity Center assignments or delete their IAM user.
2. Deactivate and delete their access keys, including any their tooling used.
3. Deregister their root MFA device, if they had one.
4. If they ever held a shared TOTP secret, reset that 2FA and rotate the associated password. The secret does not leave their phone by itself.
5. Check whether they can still read the root email address.
6. Review CloudTrail around their departure for anything unexpected.

Step 5 is the one that gets missed. Access to the root mailbox is access to the root account, whatever else you have revoked.

Where Share Auth fits

Narrowly, and deliberately. For the accounts in the section above, meaning a client’s console, a third-party panel that allows one enrolment or a break-glass credential: the secret is entered once and encrypted at rest, the people who need codes see the code and its countdown rather than the secret, permissions are per member, and every view is logged.

For an AWS root user you administer, registering a second MFA device is better than anything a vault can do, ours included. Do that first.