Create a separate account for each person at the lowest level that lets them work, remove it when the job ends, and never share the credential you use yourself.

What sharing costs

It works, immediately, which is why it happens.

What it removes is everything you would want afterwards.

There is no record of who did what, since every action appears as you, which matters when something breaks and nobody remembers who changed it.

The access cannot be ended without changing the password and disrupting everybody, so in practice it never is.

And the credential is now in somebody else's password manager, their notes, or an email, indefinitely.

The alternative takes two minutes

Every platform a small business uses supports this, and the reason it does not happen is that creating an account feels slower in the moment than sending a password.

Choose the level deliberately

Since the default when in doubt is full access, and it rarely needs to be.

Somebody writing content needs to edit content and nothing else.

Somebody fixing a display problem needs to edit the theme and does not need your customer records.

Somebody doing a one-off task may need administrative access for a day, which is different from having it permanently.

Ask what they actually need rather than guessing, since a competent supplier will tell you and will not be offended by the question.

Where the platform only offers full access or nothing, that is worth knowing, and it is a reason to be more careful about the end date.

The hosting and registrar are different

Worth separating, since these are the accounts where sharing is most tempting and most damaging.

A developer frequently needs hosting access, and hosting accounts often have no concept of separate users at the level a small plan offers.

Where the host supports sub-accounts or a support-user feature, use it.

Where it does not, consider whether the work genuinely requires it, since a great deal can be done through the site itself or through a file transfer account created for the purpose.

Never share the registrar login, under any circumstances, since that account controls whether you own the domain at all.

Where a supplier needs a change made there, make it yourself while they tell you what to do.

A worked example

A business had used four different suppliers over six years, giving each the same administrator login.

The password had never changed, and all four still had it.

When something broke, nobody could tell which of them had made the change, or when, because the log showed one account.

They created named accounts for the current supplier, changed the shared password, and removed the old one.

Two of the previous suppliers were no longer trading, and one had had the credential for four years after finishing the work.

Nothing had gone wrong, and the exposure had been continuous and unnecessary the whole time.

Agree the end at the start

Because removing access afterwards depends on somebody remembering.

When you create the account, note the date the work is expected to finish and put a reminder a week after it.

Say to the supplier, at the outset, that access will be removed when the job completes, which is normal practice and makes the removal unremarkable rather than a statement about them.

Where the arrangement is ongoing, review it annually rather than never, and reduce the level between pieces of work.

And remove access the day a relationship ends, particularly if it ends badly, since that is exactly when it matters and exactly when nobody is thinking about it.

Ask what they will hold

A question worth asking and rarely asked.

A supplier working on your site will end up with copies: a backup taken before changes, exported data, images, and sometimes a full copy running on their own machine.

Ask what they will keep, for how long, and whether it includes customer data.

That is a reasonable question and a competent supplier will have an answer, since they have to think about it for their own reasons.

Where customer data is involved, get the answer in writing, since your obligations do not end at the boundary of your own systems.

And ask them to delete working copies at the end, which most will do and none will do unprompted.

Keep the list

Since the point of named accounts is that somebody can look at the list.

Write down who has access to what, at what level, and why, on one page.

Review it twice a year, which takes minutes when the list exists and is a full audit when it does not.

Include the accounts outside the website: hosting, the registrar, email, analytics, advertising, and anything a supplier touched.

That page is also what somebody needs if you are unavailable, which is a second reason to have it.

Watch what the account does

A benefit of named accounts that goes beyond removal.

With separate logins the activity log becomes readable: who published, who changed a setting, and when.

That is useful in the ordinary case of something breaking and nobody remembering, which is far more common than any security incident.

It also means an unexpected action from a supplier's account is visible, whether that is somebody logging in months after the work finished or an account being used at an odd hour.

None of that exists with a shared login, where every action is attributed to the same person and the log answers nothing.

The counter-case

Sometimes sharing is the practical answer.

Some older systems and small tools genuinely have one login and no way to add another, and refusing to use them is not always an option.

Where that is the case, use a password manager that can share a credential without revealing it, change it when the work ends, and note that this account works differently.

There is also a version of this that becomes obstructive, where a supplier cannot get the access they need and the work stalls for a fortnight.

Create named accounts where you can, agree the end date at the start, and never share the registrar.

What to do

  1. Create a named account for each person.
  2. Ask what level they actually need.
  3. Never share the registrar login.
  4. Agree the end date at the start.
  5. Set a reminder to remove it.
  6. Ask what copies they will keep.
  7. Keep a one-page list of who has what.

Step four is what makes removal happen, since access left in place is almost never a decision and almost always the absence of one.

Handing over an account entirely is covered in handing the account to somebody else.


Frequently asked questions

What does sharing a password cost?

Any record of who did what, since every action appears as you, and any way to end the access cleanly, since removing it means disrupting everybody.

What should I do instead?

Create a separate account in their own name, at the lowest level that lets them work, with an end date agreed at the start and their own two-factor on it.

How do I choose the level?

Ask what they actually need. Somebody writing content does not need customer records. A competent supplier will tell you and will not be offended by the question.

What about hosting and the registrar?

Use sub-accounts where the host offers them. Never share the registrar login under any circumstances, since it controls whether you own the domain at all.

When should access be removed?

On the agreed end date, with a reminder set when the account is created, and immediately when a relationship ends, particularly if it ends badly.

What else should I ask a supplier?

What copies they will keep, for how long, and whether they include customer data. Get it in writing where customer data is involved, and ask them to delete working copies.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Same admin password given to four suppliers?

Create named accounts for whoever is current, then change it. Two of the four may no longer be trading.

Start a Conversation