How to share AWS credentials with a small team (the safe way)

Quick answer. To share AWS credentials with a small team safely: (1) never share the root account — lock it with a YubiKey, only use for billing changes, (2) create individual IAM users for each teammate (or use IAM Identity Center / SSO), (3) for service accounts, create scoped IAM users with rotating access keys, (4) store passwords, MFA backup codes, and access keys in a zero-knowledge shared vault, (5) on offboarding, deactivate the IAM user AND rotate any access keys they touched. The vault handles distribution; AWS IAM handles the actual access control. Free vault at LitePassword.

---

The three things you should never share

1. AWS root account password. Anyone with root can delete the org, change billing, and bypass every IAM policy. Reserve for billing-day rescues only.
2. Root account access keys. They shouldn’t exist. Delete them in IAM if they do.
3. An IAM user’s password as a shared credential. Each human gets their own IAM user. Sharing one IAM user across humans means you can never tell who did what in CloudTrail.

What you do share, and how

The root account itself (rare)

Use case: billing changes, account-recovery scenarios.

Pattern:

1. Lock the root account with a hardware key (YubiKey 5 series).
2. Store the password and recovery codes in a zero-knowledge shared vault.
3. Grant vault access to 2 founders only.
4. The YubiKey is physical — store it in a fireproof safe at the office.

IAM user credentials (per-human access)

Each teammate gets their own IAM user. They set their own password on first login. You share the initial console-login URL and their assigned username — that’s it. They take it from there.

If you need to give an existing teammate IAM console access later, generate an IAM password reset link in AWS, share that link via the vault (not Slack), and let them set their own password.

IAM access keys for programmatic access (per-service)

For CI/CD pipelines, scripts, or developer local environments that need programmatic access:

1. Create an IAM user for the service (e.g., github-actions-deploy).
2. Attach a tight policy — read S3 bucket X, write to Lambda Y, period.
3. Generate access keys.
4. Store the access key ID + secret in the LitePassword vault.
5. Grant vault access to the engineers who manage that service.

Rotation cadence: every 90 days at minimum. AWS makes this easy — generate a new key, update the consumers, deactivate the old, delete after a grace period.

MFA: how to share backup codes

Every IAM user (and the root account) should have MFA. Hardware keys are best; TOTP apps are fine as fallback.

Store backup recovery codes in a Secure Note in the LitePassword vault. Label clearly: “AWS root MFA recovery codes — use only if YubiKey is lost.” Grant access only to the people who can authorize a recovery.

Don’t store active TOTP seeds in LitePassword (no TOTP generation in v1). Use a dedicated authenticator app for the live codes.

Offboarding: the two-step pattern

When an engineer leaves:

Step 1 — In LitePassword: Users page → Revoke Access. Their vault access rotates. Cached ciphertext on their device becomes undecryptable. They can no longer pull new access keys from the vault.

Step 2 — In AWS IAM: Deactivate their personal IAM user (don’t delete immediately — preserves CloudTrail history). Rotate every access key they touched — service-account keys they used in CI, any shared programmatic access keys. They might still remember the value, so a fresh key invalidates that.

If they had console access to production: also force a sign-out of all active sessions (IAM → user → Revoke active sessions).

A common smell to avoid: the “ops” shared IAM user

You’ll see this pattern in young companies: a single IAM user called ops or devops, shared between 3-4 engineers, with broad permissions. Don’t.

CloudTrail logs the IAM user, not the human. If something gets deleted at 2am, you cannot tell who did it. When someone leaves, you have to reset the shared password and tell the others. The pattern collapses the moment you actually need accountability.

Use individual IAM users per human + scoped service accounts for programmatic access. The vault is for distribution; AWS IAM is for authorization.

Summary

1. Don’t share root or IAM passwords as the unit of sharing — share account access via IAM, share the initial setup links via the vault.
2. Per-human IAM users for console; per-service IAM users for programmatic.
3. Hardware MFA on root, TOTP on IAM. Backup codes in the vault as Secure Notes.
4. Offboarding = revoke vault access + rotate keys in AWS.

Create your free LitePassword vault →