Old User Accounts on Your Website

Two different problems

Sites with any kind of registration accumulate two sorts of account, and they need different responses.

Administrative accounts, created for people who worked on the site, which are a security problem and are usually few.

Customer or subscriber accounts, created by registration, which are a data problem and are usually many.

The first is urgent and takes twenty minutes. The second is a slower decision about what you should still be holding.

Start with the elevated accounts

Since those are the ones that can do damage.

List every account with administrative or editing rights and account for each one by name.

Expect to find a developer from a previous build, a supplier who did a piece of work once, a former employee, and occasionally something nobody recognises at all.

Remove anybody who does not currently need it, and reduce anybody who needs less than they have.

People are routinely given full rights for a single task and left there, which is how a site ends up with six administrators and two people.

An account you cannot account for should be removed and its recent activity checked, since that combination is worth a closer look.

Registration accounts you never wanted

• Automated signups from bots.
• Accounts created to post spam.
• Duplicates from a customer trying twice.
• Test accounts from the build.
• Registrations from a feature you removed.

The first is worth checking specifically. Where open registration was enabled by default and never used, a site can hold hundreds of accounts created automatically, and any of them may have more rights than intended if the default role was set wrongly.

Check the default role

A five-second check with a large consequence.

Platforms allowing registration have a setting for what role a new account receives, and the correct value is the lowest one available.

Where it has been left or changed to something with editing rights, every account created since has that level.

That is how a site with open registration ends up with hundreds of accounts able to publish.

Check the setting, then check whether any registered account holds more than it should, since fixing the setting does not change existing accounts.

Where you do not use registration at all, turn it off entirely, which removes the whole category.

A worked example

A business site had nine hundred and forty accounts, which surprised the owner, who had created two.

Registration had been enabled by default when the site was built in 2016 and never used for anything.

The default role was correct, so none of them could do anything, and the site was holding nine hundred email addresses it had no use for.

Four administrative accounts existed: the owner, his current developer, a previous developer last seen in 2018, and one with a name nobody recognised.

They removed the two stale administrators, disabled registration, and deleted the automated accounts after exporting a list.

The unrecognised account had last logged in eleven months earlier, which they reported to their host.

Dormant customer accounts are a data question

Rather than a security one, and it needs a different kind of decision.

An account inactive for five years still holds whatever it held: a name, an address, an order history, sometimes more.

Holding personal information you no longer have a reason to hold is a compliance matter as much as a security one, and the risk is what happens if the site is compromised.

Decide a retention period, write it down, and apply it: something like removing accounts with no activity for a defined number of years.

Tell people before removing, where you can, since somebody may want their order history and a warning costs one message.

Keep whatever the accounting requirements oblige you to keep, which is usually the transaction record rather than the account.

Do it on a schedule

Since this accumulates continuously and nobody notices.

Twice a year for administrative accounts, which takes twenty minutes and is the part that matters.

Annually for the rest, alongside whatever other data review you do.

And immediately whenever somebody leaves or a supplier engagement ends, which is the event that creates most stale accounts.

Note the date you checked, so the next review is a comparison rather than a full audit.

Check the routes that survive removal

Because deleting an account does not always remove the access.

Application passwords, tokens, and connected integrations frequently persist after the account that created them is gone.

The same applies to keys added for a deployment or a backup tool, which sit at the server level rather than in the site.

Ask whoever maintains the site to check those specifically, since they are not visible in the user list.

That is the same problem as email forwarding rules surviving a password change, and it is missed for the same reason.

Stop registration being useful to anybody else

Where you do need registration, a few settings reduce what accumulates.

Require confirmation by email before an account becomes usable, which stops most automated signups at no cost to real customers.

Add whatever spam protection your platform offers to the registration form specifically, since it is frequently applied to the contact form and not to this one.

Turn off any public listing of members, which some platforms produce automatically and which publishes usernames for anybody to try.

And check whether your login page reveals whether a username exists, since a different message for a wrong username and a wrong password tells an attacker which half to keep.

The counter-case

Deleting accounts has risks.

Removing a customer account may remove their order history, which they may need and which you may be obliged to keep.

Removing an account can also reassign or delete content it created, which is how a purge takes a site's blog posts with it.

Check what happens to associated content before deleting anything, and reassign rather than delete where the option exists.

Remove the stale administrators today, disable registration if unused, and treat the customer accounts as a separate, slower decision.

The review

1. List accounts with elevated rights.
2. Account for each by name.
3. Remove or reduce anybody who does not need it.
4. Check the default registration role.
5. Disable registration if you do not use it.
6. Set a retention period for dormant accounts.
7. Check tokens that survive account removal.

Step two is the whole of the urgent part, and an account nobody can name is worth investigating rather than simply deleting.

The wider question of who holds access is covered in access nobody has revoked.

Frequently asked questions

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.