The Long Goodbye: Retiring Old CMS Logins Without the Drama

Most web teams have one. A login for a contractor who left after the 2024 redesign. A shared "contentadmin" account nobody admits to using. A former colleague's profile still sitting in the user list, inactive but perfectly capable of publishing. None of it feels urgent until it does.

Dormant CMS accounts are a bit like the spare key you gave a neighbour years ago. It was sensible at the time. Then the neighbour moved, the lock changed, and nobody quite remembers who still has a copy. The difference is that a CMS account can post to your homepage at 2am, and your organisation's name is on the result.

This isn't about catching people out. It's about treating access as something with a lifecycle: it starts, it changes, and it should end. Here's a plain-English audit routine for UK web teams who'd rather sort this out on a quiet Tuesday than during an incident.

Start with a list, not a feeling

Before you change anything, export the user list from your CMS. Most platforms will give you names, email addresses, roles, last login dates and account creation dates. If yours won't, that's a finding in itself.

Put it in a spreadsheet and add a few columns: who owns this account, what team they're in, what the role actually allows, and when it was last used. You don't need a fancy tool. You need a view of reality.

A word of caution: last login dates can mislead. An account might be used rarely but legitimately — a finance officer who updates the fees page twice a year, for example. The question isn't "has this person logged in recently?" It's "do we know why this account exists and who would notice if it went?"

Separate the three types of risk

Dormant accounts usually fall into three buckets, and they need different responses.

Leavers who were never removed. The person has gone, the account hasn't. This is the most common and the easiest to fix, provided you have a leavers checklist that includes the CMS alongside email and HR systems.

Contractors and agencies with long tails. A freelancer built a template in 2023 and kept editor access "just in case". Fine in principle, less fine when nobody has spoken to them since. Either renew the relationship formally or close the account.

Shared or generic logins. The classic "admin" or "webteam" account passed around like a biscuit tin. These break the basic principle that access should be attributable to a person. They also make incident investigations miserable, because you can't tell who did what.

Make the leavers checklist boringly reliable

A leavers checklist only works if someone owns it and it runs every time. HR usually triggers it, IT usually actions it, and the web team often finds out afterwards. Fix that by adding the CMS to the standard offboarding form — not as an afterthought, but as a line item with a named owner.

For smaller organisations without a formal HR system, the checklist can be a shared document with three columns: person, systems, confirmed off. It doesn't need to be sophisticated. It needs to be used.

If you use a central identity provider — Microsoft Entra ID, Google Workspace, Okta or similar — removing the person there should remove CMS access too. If it doesn't, that's a gap worth writing down. Single sign-on is only as good as the accounts it actually covers.

SSO and MFA: practical, not theatrical

Single sign-on and multi-factor authentication are not magic, but they remove a lot of the day-to-day mess. When someone leaves, you disable one identity and their CMS access goes with it. When someone changes role, you update their group membership rather than hunting through individual CMS profiles.

MFA is the other half. The NCSC has been clear for years that MFA is one of the simplest ways to reduce account compromise, and Cyber Essentials expects it for remote access. For a CMS, that means at minimum the ability to require a second factor for administrator and editor roles.

A few practical notes for UK teams:

• Check whether your CMS supports SSO on your current plan. Some vendors charge extra for it, which is worth knowing before you promise it to anyone.
• Decide what happens to service accounts and integrations. They can't do MFA in the usual way, so they need their own controls and a named owner.
• Test the joiner and leaver journey with a real person, not a diagram. A five-minute walkthrough will reveal more than a policy document.
• Keep a fallback local admin account, but store its credentials properly and review it quarterly. A break-glass account is useful; a forgotten break-glass account is just another ghost.

Document decisions without turning it into a tribunal

The temptation when auditing access is to write a report that reads like a misconduct hearing. Resist it. The goal is a clear record of what you found and what you decided, not a list of who left the back door open.

For each account, note one of four outcomes: retained, role changed, disabled, or deleted. Add a short reason and a date. If an account is retained for a legitimate reason — a retained contractor, a shared inbox owner, a seasonal editor — say so. Future you will thank present you.

Where shared accounts exist, the decision is usually to replace them with named accounts and, if needed, a role that does the specific job. That can be a bit of work in the short term. It saves a lot of confusion later.

Put it on a calendar

An access audit isn't a one-off spring clean. Accounts drift. People change roles. Agencies come and go. A light quarterly review — even thirty minutes with the user list — keeps the problem small.

Pair it with something you already do: the quarterly CMS routine, the security review, the start of the financial year. The point is to make it normal. Dormant accounts thrive in the gap between "someone should check that" and "I thought you had".

The takeaway

A dormant login isn't a scandal. It's a loose end. Most organisations have a few, and the fix is usually a spreadsheet, a conversation and a checklist that actually gets used. Start with the list, assign an owner, close what you can and write down what you've kept and why. The ghost editor doesn't need a dramatic exit — just a quiet, documented goodbye.