The client deleted a departing colleague's backend account, but their phone number can still reset the password—is that really cleaned up?

Not really. Deleting a departing colleague's backend account from the list only closes the login door; if the account was originally bound to their personal phone number or email, they may still get in through password reset. In 2026 project handovers, the more reliable order is: inventory the entry points first, clear accounts and roles, then reset credentials uniformly and keep a ledger. What really needs to be handled is four layers—accounts, roles, credentials, and records; the password is only one layer.

Why access may still be possible after deleting the account

Backend access is not a single entry point: the login account determines 'who you are,' the role determines 'what you can change,' the credential determines 'which door you come in through,' and the record determines 'whether it can be investigated after an incident.' If only one of the four layers is touched, the other three can still open doors.

• Account layer: one person one account, or several people sharing one admin; bound to a corporate phone number and email, or a personal phone number and email.
• Role layer: what super admin, editor, customer service, and finance can each see; who can change site configuration, export inquiries, or install plugins.
• Credential layer: beyond the backend password, there is FTP or database, server panel, domain registrar, corporate email, and third-party keys for SMS, maps, payments, analytics, etc.
• Record layer: login logs, operation logs, and an account ledger that clearly states 'who had which permission at what time.'

Many 'already handled' cases have actually only touched the account layer. Common leftovers: the backend account is deleted, but FTP is still under a developer's personal name; the database password has not been changed for years; third-party keys are written in code and never rotated.

Three common leftovers that changing the password alone won't fix

Changing the password blocks 'people who know the old password,' but not 'people who can prove they are the account owner.' Most backends have a forgot-password flow verified by SMS code or email link; if the binding information is not changed, the new password is just one more step.

• Only changing the backend password: the domain registrar account is untouched, so the person may still change DNS records.
• Deleting the backend account: corporate email is not disabled, so inquiry notifications still go to them.
• Sending the new password in a group chat: that is like changing a lock but giving everyone a key.

For workload, here is an experience range: for a corporate website of a dozen or so pages, clearing only backend accounts and resetting roles commonly takes 1–3 hours; checking domain, corporate email, server panel, and third-party keys together usually takes half a day to a day, with review across providers counted separately. This range varies with site size and number of collaborators; it is not a fixed quote.

On delivery: inventory the list before making changes

A common project constraint is that handover is squeezed into the week before launch: the client is pushing for launch, materials are incomplete, and no one fills in the account table. At that point, directly 'changing the password first' often leads to rework, because only after the change do you find that another entry point is actually in use, or that a third-party callback is configured with an old account, causing payments and SMS verification to fail.

Based on website delivery experience, check before changing: have the client designate one responsible person, fill in the 'current holder' for six entry-point categories—backend, FTP or database, server panel, domain, corporate email, and third-party keys—one by one; first migrate entry points under personal names to the company name, then reset passwords uniformly. The cost is usually a half-day to one-day launch delay (typical range), in exchange for avoiding a second round of troubleshooting later.

Piecemeal cleanup or full reset: a comparison you can check

Clients often ask whether they should just delete everything and rebuild. Neither approach is universally better; it depends on site size, number of collaborators, and the nature of this change.

• Piecemeal cleanup: disable only the departing person and adjust related roles, leaving the rest untouched. The experience range is commonly 1–3 hours; the action is small and the list catches missed items; suitable for single-person changes and sites that already use one person one account.
• Full reset: rebuild all site accounts, reconfigure roles, and rotate key credentials. The typical range is half a day to a day, and the client must confirm the new account holder for each account; suitable for multi-person collaboration, long-term outsourcing, or sites that have just gone through major team turnover.

The decision rule can be simple: if there are still accounts in the backend that 'no one can clearly say who is using,' a full reset is worth doing; if every account maps to a person, piecemeal cleanup is usually enough.

What counts as done, and where this applies

The pass line does not need to be complex; the key is that it can be checked: one person, one account, with each account mapping to a specific current employee; least privilege, where a role that can publish content does not get site configuration rights, and a role that can view inquiries does not get member data; deactivation window, commonly within 24–72 hours after departure or transfer, with the shorter end for payment and finance permissions; regular review, going through the account list against the ledger every quarter. Rotating third-party keys once after personnel changes is a common practice.

Applies: websites with a content management backend, inquiry or order data, multi-person collaboration, or a history of outsourcing handover usually see direct benefits from account cleanup. Does not apply: purely static display sites with no backend, single-person maintenance, and no past external changes usually do not need a dedicated permission rebuild; however, it is still advisable to confirm the domain registrar and corporate email are under the company's name.

The boundary can be remembered in one sentence: every entry point that can be logged into is part of the website, and the scope of account cleanup should be based on the entry-point list, not on the 'website backend.'

Common questions

If I delete a departing colleague's backend account, will the articles they previously published disappear too?

Generally no. Content belongs to the site, not the account; deleting the account only affects login. The article author byline may become empty or display abnormally, so export the content list and bylines before deletion.

If the departing person was only a content editor, should the account still be disabled immediately?

It is recommended. Although editor permissions cannot change site configuration, they can publish content, upload files, and see some messages; deactivation costs little, and the common practice is to handle it together with offboarding.

What if the client is unwilling to hand over the super admin account?

This request is common and reasonable. You can create a dedicated technical account, agree to use it during the delivery period, and have the client take it back or change its password after project close, with both sides keeping operation records.

How often should the account ledger be reviewed?

A common practice is once a quarter, or monthly for teams with frequent personnel changes; compare the ledger with the actual backend account list and delete the ones that do not match.

If you happen to have a site to hand over, start with one thing: have the client designate one responsible person, list the current holders of six entry-point categories—backend, FTP, server, domain, email, and third-party keys—on one page, and only change passwords after confirming. This set of actions pays off clearly on sites with multi-person collaboration or outsourcing handover; if the site has only one maintainer and all entry points are already under the company's name, a quarterly account review is enough—no need to set up a special project for it.