The Website Access Offboarding Checklist: What to Revoke, and in What Order

A password reset is not the same as an offboarding

When someone with access to your website leaves — a developer moves on, an agency contract ends, a staff member changes roles — the instinctive response is to change a password and consider the matter closed. That instinct is wrong, and it is wrong in a specific, checkable way: a password protects a login screen, not a session that is already open, an API token that was already issued, or an SSH key that was already trusted. All three of those can go on working long after the password tied to the account they came from has changed.

This matters more for a website than for almost any other business system, because website access is scattered across a dozen separate places — a host, a registrar, a CMS, a code repository, several APIs, a DNS provider, an email system and a handful of SaaS tools — each with its own definition of "access" and its own separate revocation step. Closing one door rarely closes the rest of them.

Why changing a password doesn't finish the job

Take GitHub as a concrete, checkable example, because its own documentation is explicit about the gap. GitHub's security guidance tells account holders that after a password change, they should separately "review your SSH keys, deploy keys, and authorized OAuth apps and GitHub Apps and revoke unauthorized or unfamiliar access" — a password change does not do any of that automatically (GitHub: Preventing unauthorized access).

Deploy keys make the point sharply. A deploy key is an SSH key attached to a specific repository so a server can pull code without a human logging in each time. GitHub's own documentation states that a deploy key "isn't tied to the specific user, but rather to the repository" that holds it — so if the person who originally added the key is removed from the project, or their personal account is deleted altogether, the key keeps working exactly as before (GitHub: Managing deploy keys). Deploy keys also carry no expiry date by default, so one added for a project three years ago and forgotten about is, by default, still live today. The only way to close it is to open that specific repository's own settings and delete it there — removing the person from your organisation or team does nothing to it.

The same pattern shows up with OAuth grants. A departing developer's personal Google, GitHub or Slack login might have authorised a connected app — a CMS plugin, a build pipeline, a monitoring tool — independently of any password. Revoking that grant is a separate action inside that specific app's or account's "authorised applications" settings, and it's easy to forget an authorisation exists at all if nobody kept a list of what was connected.

The order to work through

There's no single universal sequence, but working roughly from "controls everything else" down to "controls one thing" avoids leaving a high-leverage account exposed while you tidy up smaller ones.

1. Hosting account. Change the login, and separately check for API keys or CLI tokens issued under it — most hosting control panels list these apart from the account password.
2. Domain registrar. This account can repoint your entire site and mail, so secure it early. Check for a separate "API access" or reseller-style toggle that many registrars offer alongside the normal login.
3. CMS admin users. Remove the individual's own account rather than only changing a shared admin password — a named account lets you trace specific actions later if something goes wrong, and removing it closes their session immediately rather than waiting for it to expire.
4. SSH keys and deploy keys. Remove personal SSH keys from servers and version-control accounts, then audit every repository's deploy keys individually, as above — there is no bulk switch for these.
5. API tokens and webhooks. Payment gateways, transactional email services, form-handling tools and analytics platforms each issue their own tokens, usually tucked under an "API" or "Developer" settings tab, separate from any login credential.
6. DNS provider. Where DNS is managed apart from the registrar, it needs its own access review — DNS records control mail delivery and domain-ownership verification, not only where the site resolves.
7. Email forwarding rules and mailbox delegation. A departing admin may have set up a forwarding rule, or given themselves delegated access to a shared inbox — such as the one that receives domain or hosting renewal notices. These persist independently of the mailbox owner's password and are easy to miss during a routine review.
8. Third-party SaaS seats. Booking tools, live chat, review platforms, marketing automation — each is its own login with its own separate user list, none of which is touched by changing a CMS or hosting password.
9. Shared password-manager vault. Remove the person's access to the vault itself, then separately rotate every credential they could see inside it. Removing someone from a vault stops future viewing; it does nothing about anything they already copied down before that point.

Why the vault comes last, not first

It's tempting to revoke vault access first, since it feels like the master switch for everything else. In practice it works better near the end of the process, once you've used the vault's own records to work out what actually needs rotating. Cut vault access before finishing that inventory, and you can lose the one place that documented what needed to change in the first place.

Agencies leaving are a wider case than staff leaving

An individual staff member usually has a bounded set of logins tied to their own name. An agency relationship tends to be wider and messier: they may have created accounts on your behalf that were never handed to you directly, added their own team's personal logins as CMS admins, and connected tools using credentials that live only in their own password manager, not yours. Ending an agency contract is a good moment to ask, explicitly, for a written list of every account, key and token they created on your behalf — not just for the ones you already know about.

A realistic starting point

If your business has never mapped out who has access to what across hosting, domain, CMS, code and third-party tools, an offboarding event is usually the first time the gaps surface — and by then it's reactive rather than planned. One option for building an honest starting inventory is JagaWeb's Essential System Review: a fixed RM1,500 check (RM999 until 16 September 2026) across eight control points on a single site, including access and account exposure, producing a decision-ready report rather than a subscription. It's a way to see what's actually out there before the next departure, not a guarantee that every gap will be caught.