Leaving a freelancer with your AWS root login

Leaving a freelancer with your AWS root login is a liability even when the build went well and the relationship ended on good terms. The root user can close the account, change billing and override any permission you set later, so it belongs with the business, not the person who wrote the code. Here's how to check where you stand and take back control when a contractor finishes.

What the AWS root user can do

An AWS account has one root user: the email address and password used to create it. IAM policies can't restrict it. It can change the payment method, alter support plans, change the account email and close the account outright. AWS's own guidance is to lock it away, protect it with multi-factor authentication and use it only for the handful of tasks that need it.

So the question isn't whether your contractor is trustworthy. It's whether one person outside the company should hold a key that outranks all the others. If their inbox is compromised, or they simply stop answering, the password reset goes to an address you can't read.

Signs the account isn't really yours

Ask three plain questions. Whose email address is on the root user? Whose card pays the bill? And who has the MFA device? If any answer is the freelancer's name or a personal Gmail, the account is theirs in practice, whatever the contract says about the code.

Other warning signs: a single IAM user called admin shared by the whole team, access keys created on the root user, and no record of which region holds the database. None of these mean the build is bad. They mean nobody in the business could run it tomorrow.

Root login vs named IAM vs an organisation account

• Root login: one identity with unlimited power. Fine for account recovery and billing tasks, wrong for daily work or deployments.
• Named IAM or Identity Center users: one login per person, each with MFA and only the permissions their job needs. When someone leaves, you remove their access and nothing else breaks.
• AWS Organizations account in the client's name: the business owns the management account and billing, and workloads live in member accounts beneath it. A contractor gets a role in a member account, not the keys to the building.

How to take back AWS control after a contractor build

Leaving a freelancer with your AWS root login is easiest to fix while they're still friendly and reachable. It's a short, cooperative job then, and a support ticket with AWS later.

First, move the root user's email to a shared address the company controls, something like [email protected] rather than a person's mailbox. Change the password, store it in the company password manager, and register MFA on a device a director holds. Delete any root access keys. Put the business card on the billing page.

Next, create named users for anyone who needs access, contractor included, with MFA required. Give the freelancer a role they can use for the handover period, then remove it on a date you've both agreed. Rotate any secrets they could have copied: database passwords, API keys and deployment credentials. Turn on CloudTrail if it isn't already, so you can see who did what.

Finally, ask for a written handoff. Which regions and services are in use, how deployment works, where backups go and how to restore them, and what costs to expect. If the infrastructure is in Terraform or CDK, the repository should be in the company's name too.

When the contractor has gone quiet

If you can't reach the person who holds the root login, start with what you can prove: invoices, contracts and the payment card. AWS has an account recovery route for the legitimate owner, but it's slower and you'll need that paperwork. Meanwhile, list what's running and what it costs, so nothing surprises you while you wait.

This sits next to two related problems: who owns the code and the case where one person knows how to deploy it. Account ownership comes first, because without it the other two can't be fixed.

How Eight Mile handles accounts and takeovers

On our own software development work, cloud accounts and repositories are in the customer's name from the start, and we work with access granted to us. Infrastructure is described in code and the setup is documented in the repository. Delivered work is covered for twelve months, and after that a retainer can define support coverage and response times in writing.

We also take on systems someone else built. That starts with a review of what's running, its fragile areas and its costs, then a written plan. Tightening least privilege and access logging is part of that work, and so is rescuing a SaaS someone else built.

If a freelancer still holds your AWS root login, or you're not sure who does, talk to an engineer and we'll help you work out where you stand and what to change first.