If one person holds the only admin login to your domain, cloud account or source control, you have two risks at once: that person is a single point of failure, and their account is a single point of compromise. Fix it with at least two named admins, group owned recovery addresses, and a written list of who can recover what.
Why this happens
Early on, the founder sets everything up. Accounts are in their name, on their phone number, behind their email. It works until they are on a plane, ill, or gone.
It also matters for attackers. A phished founder inbox can mean the domain, the cloud account and the payment tool in one afternoon.
Which accounts to list
Start with the five that can hurt most.
- Domain registrar and DNS.
- Email and identity provider admin.
- Cloud provider root or owner.
- Source control organization owner.
- Payment and billing, including card on file for the cloud account.
For each, write the owner, the backup owner, the recovery email, the recovery phone and where the MFA devices are.
Rules that help
AWS documentation on the root user gives a useful model that applies broadly. Use a group email address managed by the business instead of an individual's inbox. Do not let one person control both the email inbox and the phone number used for recovery. Consider multi person approval so nobody holds both password and MFA device.
GitHub's documentation on requiring 2FA notes that a sole organization owner cannot disable 2FA on their own account without turning off the organization requirement. Add a second owner so the requirement is not tied to one person.
Separate admin from daily use
Admins should have a separate admin account, not their daily mailbox. If their daily account is phished, the admin account stays out of reach.
Test recovery once a year
Run a short drill. Pretend the primary admin is unreachable and see whether the backup can recover each account. You will find an expired card, a dead phone number or an MFA device nobody can find. Fix those while nothing is on fire.
Do not overcorrect
Giving everyone admin to avoid single points of failure creates a different problem. Aim for two or three people with admin, each with strong MFA and a clear reason.
Common pitfalls.
Common mistakes: putting the backup admin's phone number on file and then forgetting to update it when they change devices, storing the only copy of MFA recovery codes in the same vault that the admin account unlocks, and letting a departing admin keep ownership of billing. Add admin ownership to your offboarding checklist, and review the table each quarter. When someone becomes a backup admin, have them actually perform a recovery step, not just receive a link.
Quick check
How many admins is right for ten people?
Two or three per critical system is a common starting point. More needs a reason.
Sources
- Root user best practices for your AWS account
- Requiring two-factor authentication in your organization (GitHub Docs)
Last reviewed: 19 October 2026.
