How to safely share an AWS root account password across a small team

Nobody should hold the AWS root password alone. A shared password manager isn't quite enough either. Here's a concrete 2-of-3 or 3-of-5 setup that survives a laptop loss without turning any single engineer into a single point of failure.

9 min read · Updated 2026-05-25

Why the root account is different

The AWS root user can do things no IAM user can: change account contact email, close the account, modify the root device for an EC2 instance store, edit S3 bucket policies that have explicitly denied everyone (including root), and rotate the root access keys. AWS's own guidance is straightforward: lock the root account away, give it MFA, never use it for daily work, and treat its credentials like a nuclear key.

That's fine advice — and it leaves an awkward gap. Who physically holds the key? In most small teams the honest answer is "the CTO, in 1Password, with the MFA app on their personal phone." Which means: if the CTO leaves, loses the phone, or is unreachable during an incident, the company has lost its own AWS account.

Why a shared password manager isn't enough

Shared vaults in 1Password, Bitwarden, or Dashlane are great for normal credentials. For the AWS root account specifically, they have three problems:

• Anyone in the vault is fully authorized. "Shared with three people" means three people can each, alone, log in as root. You haven't reduced the blast radius — you've widened it.
• The vault provider is a single point of failure. If your 1Password account is compromised or locked out, your root password is in the same bag as everything else.
• It doesn't model two-person control. The whole point of locking the root account away is requiring deliberation before it's used. Shared vaults provide convenience, not friction.

Threshold sharing flips this: no single holder can act, but any quorum can. That's the property you actually want for a credential that should rarely be touched and should require a human conversation when it is.

The shape of the setup

A workable arrangement for an early-stage company:

1. Generate a 32-character random password for the AWS root user. Don't use anything mnemonic. Don't reuse a manager-generated one — generate fresh.
2. Enable hardware MFA on the root account (a YubiKey or two registered as MFA devices). Save the recovery code AWS issues at MFA setup.
3. Split the password with shattr into a 2-of-3 (3-person team) or 3-of-5 (larger team) threshold.
4. Split the MFA recovery code separately, with the same threshold but to different custodians where possible.
5. Store the root YubiKey(s) in a physical safe with limited access.
6. Document who holds what, where, and how to combine them — in a runbook that's also accessible without root.

Picking the right threshold (2-of-3 vs. 3-of-5)

Threshold choice is a tradeoff between availability (can we still log in if someone is unavailable?) and collusion resistance (how many people would have to conspire to misuse it?).

2-of-3

Three custodians, any two recover. Survives one custodian being unreachable, sick, or laptop-lost. Two people can collude to log in without the third's knowledge. Right for a 3-person founding team where everyone trusts each other but you still want two-person control.

3-of-5

Five custodians, any three recover. Survives two simultaneous absences. Requires a real meeting (three people) to act. Right for a team of ~10–30 where you want roles to span engineering, finance, and a board member or outside counsel.

Above 3-of-5

Usually overkill for a small team and creates a different failure mode: too many custodians means recovery becomes a logistics problem during the exact moment you need to move fast. Reserve higher thresholds for governance-tier secrets, not operational ones.

Who should hold the portions

The point of N-of-M is that the people don't fail correlated. Some heuristics for custodian selection:

• Span roles. Not all engineering. Mix engineering, finance/ops, and one non-employee (board member, legal counsel, accountant) where the threshold allows.
• Span geographies. Two people in the same office in the same city in the same country isn't "two people" for purposes of natural disasters or local political risk.
• Span attack surfaces. If one custodian is the most-targeted employee (CEO, founder), make sure the threshold doesn't include them as a required signer.
• Avoid reporting lines where you can. An IC and their manager being two of the three custodians means the manager can functionally compel a signature. Cross-functional custodians sidestep this.

How each custodian should store their portion

The portions are useless on their own (that's the math), but they should still be stored with care. Decent options:

• Each custodian's personal password manager, in a vault not shared with the others. Bonus points if the manager uses a hardware key for unlock.
• Printed and kept in a home safe. Paper is durable. A QR code of the portion is fine.
• Engraved on a metal backup plate for very long-lived custody (founder succession, succession to estate).

What to avoid:

• Email inboxes (long-lived, often-compromised).
• Plain notes apps that sync to cloud accounts you don't control.
• The same vault that holds everything else (eliminates independence).

The MFA question

AWS root MFA can be a hardware key (recommended), a virtual MFA app, or a U2F device. With hardware MFA, the keys themselves become a custody problem: do you keep two YubiKeys in a single safe? In two different safes? Who knows the combination?

A robust pattern:

• Two hardware MFA devices registered to the root account, stored in two different physical safes with two different custodians.
• The MFA recovery code AWS issues at setup is split with shattr at the same threshold as the password — different custodians where possible.
• The runbook explicitly covers both paths: "if a hardware MFA is available, use it; if neither is reachable, reconstruct the recovery code and re-enroll a new MFA."

A concrete 3-of-5 example

Imagine a 15-person startup. The 3-of-5 looks like this:

1. Co-founder / CEO — home safe, west coast.
2. Co-founder / CTO — home safe, east coast.
3. Head of Finance — personal 1Password vault with hardware-key unlock.
4. Outside counsel — printed, in their firm's safe.
5. Board chair — printed, in their personal safe.

Hardware MFA: one YubiKey in the office safe (custodied by Head of Finance), one YubiKey at the CEO's home. Recovery code split 3-of-5 across the same custodians, but rotated so that the "default" three-person quorum to recover is CEO + CTO + Head of Finance, with outside counsel and the board chair as redundancy for incapacity.

Rehearse it — quarterly

A break-glass procedure that has never been exercised is worse than not having one: it provides false confidence. Once per quarter:

1. Schedule a 30-minute call with the three primary custodians.
2. Combine portions on shattr (or by hand on paper) and confirm the password reconstructs correctly. Don't actually log in unless you're rotating credentials.
3. If a hardware key is part of the procedure, physically retrieve it and confirm it still authenticates.
4. If a portion is corrupted, missing, or its custodian has changed, rotate: generate a new password, new portions, hand out new portions, retire old.

Rotate when a custodian leaves

When any custodian leaves the company — even amicably — treat their portion as burned: generate a new root password, generate fresh portions, redistribute. The math doesn't care that they "still have a portion"; what matters is that their portion is no longer one of the N that decrypts the current secret.