Changing an account password without losing track of who has it

Changing one account's password is trivial. Changing passwords across an estate without losing track of who holds what is the actual problem, and it is an administrative one rather than a technical one.

Know what the password reaches before you change it

An account password is not only a login. Depending on how the site was set up, it may also be the credential behind file transfer access, mail client configuration, and any tooling somebody wired up months ago. Changing it can therefore take a working thing offline in a way that is not obvious for days.

So the first step is not the change, it is the question: who or what authenticates as this account? Two minutes of thought here prevents the classic outcome where the site is fine, the panel is fine, and a backup job has been silently failing since Tuesday.

Four moments that justify a change

1. Somebody left. A contractor, an agency, a former colleague. This is the one people postpone and should not.
2. The credential travelled badly. It went over chat, or into a ticket, or into a document that got shared onward.
3. You inherited the account. A site came in from another host or another owner. Assume the old password is known to people you cannot name.
4. Something looks wrong. Unexplained files, unexplained mail, unexplained load. Change it as part of the response, not as the whole response.

Routine rotation on a calendar, with no event behind it, mostly generates work and weaker passwords. The events above are what actually warrant it.

One account, one password

The rule that saves the most pain later is the boring one: no password is used by two accounts. If it is shared, a change in one place breaks the other, and a leak in one place exposes both. On an estate whose whole point is that the sites look unrelated, a shared credential is also a shared fate.

Generate the value rather than inventing it, and let it be long. You are not going to type it from memory, so its memorability buys you nothing.

Where the new value goes

Into a password manager, and nowhere else. Not into a spreadsheet, not into the ticket where somebody asked for it, not into a note in the account's own comment field. The record you need alongside it is short:

• Which account, and which site that account serves.
• When it was changed, and why.
• Who has been given it since.

That last line is the one people skip and the one that matters when somebody leaves. Access control across a network of sites is covered more fully in Running Your Estate.

What to check afterwards

Log in with the new value once, from the panel, to confirm it took. Then check the things that authenticate without a human present: file transfer clients, mail clients on phones, deployment scripts, monitoring, backup jobs. Anything you have to hunt for is anything you should be writing down.

Prefer a token where a password is not needed

If the reason you are handing a password to somebody is that a script needs to do one narrow job, a password is the wrong instrument. A scoped token can be issued, given away and revoked without disturbing the account or the humans using it. When that applies, and how narrow to make it, is in WHM and Accounts.