Who Holds the Keys? Website Access, Trust, and Getting It Right with Your Developer

There’s a conversation I wish I had with every client at the start of a project, and it’s not about design, budgets or timelines. It’s about access: who holds the keys to your website, your domain, your hosting and your email, and what happens when something goes wrong.

I’m writing this because I’m in the middle of a situation that shows exactly why it matters.

When the developer can’t get in

One of my clients has, quite understandably, kept tight control of their accounts. They own the hosting, the domain, the email and their Microsoft 365 setup, and I have very limited access.

That sounds sensible until the site goes down.

Their website has now been offline for two days. I know what needs fixing, but I can’t reach it. The hosting account has two-factor authentication tied to a phone I don’t have. I can’t get into their Microsoft accounts, and the authenticator app for SharePoint sits on someone else’s device. Nobody on their team is particularly comfortable with IT, so the person with the phone isn’t sure what they’re looking at or what to approve.

So the developer who could fix the problem in half an hour is locked out, and the people with access don’t know how to fix it. Every hour offline costs them enquiries, bookings and credibility.

But clients have a point

I want to be fair here, because the opposite situation is just as bad, and it happens far more often than it should.

Plenty of business owners have handed everything to a developer or agency, only for that person to disappear. They stop answering emails, the agency folds, or there’s a dispute and access becomes a bargaining chip. Suddenly the business can’t renew its domain, can’t move its hosting and can’t recover its own email. I’ve been brought in to untangle situations like this, and it can take weeks, sometimes with the domain lost entirely.

So clients are right to be cautious. The problem isn’t caution. It’s that “keep everything locked down” and “hand everything over” are the only two options most people think they have.

There’s a better middle ground.

The principle: you own it, your developer can use it

The aim is simple. The client owns every account outright, and the developer has their own separate login with the access they need. Nobody shares passwords, nobody relies on one person’s phone, and access can be added or removed without drama.

Here’s how that works in practice.

1. Keep the domain in your name

Your domain is the most important thing you own online. Register it in your business name, with your own login and a business email address you control. A developer rarely needs registrar access. If they do, for DNS changes, most registrars let you add a user or manage DNS separately.

2. Use collaborator or team access on hosting

Most decent hosting providers now let account owners invite other users, often called team members, collaborators or delegated users. Your developer gets their own login, with their own two-factor authentication on their own device, and you stay the owner. If you part ways, you simply remove them.

If your current host doesn’t offer this, that alone is a good reason to consider moving.

3. Give your developer their own accounts everywhere else

The same idea applies across the board:

• WordPress: a separate administrator account in the developer’s name, never a shared “admin” login.
• Microsoft 365: a separate user account for the developer with the admin role they need, rather than access to someone’s personal mailbox or authenticator.
• Analytics, Google Search Console, booking systems and so on: invite the developer as a user.

Separate accounts also give you an audit trail. You can see who changed what.

4. Don’t tie critical 2FA to one person’s phone

This is the weak point in most small businesses. If the only way into the hosting account is a code sent to one person’s mobile, then that person being on holiday, off sick, or having changed phones can take your business offline.

Better options:

• A shared business password manager (such as 1Password or Bitwarden) that can hold 2FA codes and be shared securely with named people
• Backup or recovery codes, printed and stored somewhere safe
• More than one authorised person on each critical account
• For Microsoft 365, an emergency or “break-glass” admin account, stored securely for exactly this kind of situation

5. Keep an access register

This is a simple document listing every service you use: who owns it, who has access, where the login lives and when it renews. It doesn’t need to be fancy, and a single page is fine. It’s the first thing anyone will need in an emergency, and the first thing you’ll want if you ever change developer.

6. Put it in writing

A good contract should state clearly that the client owns all accounts, domains and content, and that the developer will hand over access and remove their own on request. That protects both sides. Clients know they can’t be held hostage, and developers have clear permission to act when something breaks.

7. Agree an emergency plan in advance

Decide now, while everything is working, what happens if the site goes down. Who does the developer contact? Who can approve a login? Can the developer act without waiting for approval? A five-minute conversation now saves days of downtime later.

What this looks like when it works

With this setup, if your site goes down at 9am, your developer logs in with their own credentials, finds the problem, fixes it and tells you what happened. Nobody has to hunt for a phone or work out which code to read out.

And if you ever part ways, you remove their access in a few clicks. Your domain, hosting, email and website stay exactly where they are, in your name.

Trust, but structure it

I completely understand why clients hold on to their accounts. But holding on doesn’t have to mean locking out. If you trust your developer enough to build your website, set things up so they can also look after it. If you ever stop trusting them, you’ll be glad everything is in your name with their access easy to remove.

If you’re not sure who has access to what across your business, that’s the place to start. Make the list, check the logins and ask your developer to help you set up proper shared access. It’s one of the least exciting jobs in running a website, and one of the most valuable.