Change every password listed in the handover email, give each person their own login with only the access they need, and keep access details in a password manager rather than an inbox.

The email with every login

When a website launches, the developer usually sends one email with everything: the address of the admin page, a username and password, the hosting control panel login, and often the domain account too.

It is an ordinary email, unencrypted and searchable like any other. It gets forwarded to the office manager, and probably to whoever does the bookkeeping.

Several years later that email is still sitting in three or four inboxes. In most cases the passwords in it have never been changed.

Anyone who can read any of those inboxes can still log in to the website.

What the email usually contains

The fourth is the one that matters most. Whoever controls the domain account can point the website and the email somewhere else entirely, and recovering a domain is slow.

Why old passwords keep working

Nothing forces anyone to change them. The site works, the logins work, and changing a password feels like a way to break something.

Meanwhile the email ages. Inboxes get synced to new phones, exported when staff leave, and opened on home computers.

Inboxes are a common target as well. Once an email account has been broken into, a search for the word password is an obvious first step, and a handover email answers it in one go.

Change everything on the list

The fix starts with that email. Open it, list every login it contains, and change each password.

Use a long password for each, different from every other, and never one already used somewhere else.

Some changes need care. The database password is stored in the site's configuration file, so changing it without updating that file takes the site down. Leave that one to whoever looks after the hosting.

When everything has been changed, delete the email, and ask everyone who received a copy to delete theirs.

One login per person

A shared login hides who did what. When a page goes missing or a strange plugin appears, there is no way to tell which of five people did it.

WordPress and most other systems allow as many accounts as you need, each with a role. An editor can write and change pages; an administrator can also install plugins, change settings and add users.

Give each person their own account at the lowest level that lets them do their job. Most staff who update pages need editor access, not administrator.

When someone leaves, their account is removed, and nobody else has to learn a new password.

A worked example

A family-run funeral home with two chapels posts obituaries and service details on its website several times a week.

The site was built five years ago. The developer's handover email went to the general office address, with one administrator login, the hosting control panel and the domain account.

Four funeral directors and two office staff all posted obituaries using that one login, so the password had been written on a card beside the office computer.

One of the directors had since moved to another firm, and still had the email on her phone. Nobody had done anything wrong; the single login was simply the only one anyone had been given.

The fix took a morning. Each person got an editor account in their own name, the owner kept the only administrator login, and every password from the handover was changed.

The card went in the shredder. The access details went into a password manager the owner controls.

The developer's own access

Most developers keep an account after launch so they can help later. That is reasonable, if they still look after the site.

If they do, they should have their own named account, and the old shared one should go. If they do not, remove their access and let them know, politely.

The same applies to the hosting account. One set up in the developer's name is worth moving into the business's name while relations are good.

Where the logins should live

Not in email, not on a card by the monitor, and not in a spreadsheet on the shared drive.

A password manager stores logins in an encrypted vault opened with one strong master password. Most can share particular logins with particular people, and withdraw that access later.

For the few logins only the owner should hold, such as the domain account, a written copy in the office safe is a reasonable backup.

The test is simple. If a stranger read one of your inboxes tomorrow, would they find a working website login in it?

Protect the reset address

Changing every password still leaves one route in: the reset link.

Every website and hosting account sends password resets to an email address. Whoever controls that inbox can reset the password and lock everyone else out.

Check which address each account uses. It should be one the business owns, not the developer's and not a former employee's.

That inbox also deserves two-step verification, where a code from a phone is needed alongside the password.

The counter-case

Some sites have little behind them. A simple site with no forms, no shop and no customer details holds less of value, though a break-in can still be used to send spam or host fake pages.

And some businesses had a careful handover: individual accounts from the start, with logins passed on by phone or through a password manager. For them this is a ten-minute check.

For most, the handover email is still out there. Find it, change everything in it, and give each person their own way in.

Starting with the inbox

  1. Search your inbox for the handover email.
  2. List every login it contains.
  3. Change each password to a new one.
  4. Create a named account for each person.
  5. Check the reset address on every account.
  6. Move the logins into a password manager.
  7. Delete the email and every forwarded copy.

Step four is the one that stops the problem returning. Shared passwords get written down and passed around again, while named accounts mean the next departure is one account removed.

The quiet weeks for this kind of housekeeping are mapped in a website year planned around your busy season.

Frequently asked questions

Why do handover passwords still work?

Nothing forces a change. The site works, changing a password feels risky, and the email sits in several inboxes for years without anyone opening it again.

Which login matters most?

The domain registrar account. Whoever controls it can point the website and the email somewhere else, and recovering a domain is slow and difficult.

Should staff share one website login?

No. A shared login hides who changed what, and gets written down. Give each person a named account at the lowest level that lets them do their job.

Should the developer keep access?

Only if they still maintain the site, and then through their own named account. If they no longer look after it, remove their access and let them know.

Where should website logins be stored?

In a password manager, which encrypts them and can share particular logins with particular people. Not in email, not in a spreadsheet, and not on a card by the computer.

Is changing passwords enough on its own?

Not quite. Password resets go to an email address, so check each account uses an inbox the business controls, and protect that inbox with two-step verification.

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.

Still using the logins from launch day?

Send us the list of accounts, not the passwords. We will help you change them and set up proper individual access.

Start a Conversation