What to do when someone who had access leaves
What to do when someone who had access leaves
I timed the last one. Twenty two minutes across nine accounts and two servers, and eleven of those minutes went on reading recovery contacts, which is the part I would have skipped two years ago.
The reason it took twenty two minutes rather than a weekend is that I was reading a list somebody had written down while the access was being granted. Not remembering. Reading.
That is the whole article, really, but the ordering underneath it is worth spelling out, because the sequence people use by instinct is close to backwards.
The step everyone does first protects the least
Somebody finishes up, and the reflex is to change the passwords. It is one button, it produces a visible result, and it lets you close the tab feeling like the matter is handled.
On most platforms a password change does not terminate a session that already exists. The browser is holding a token. The token stays valid. The login screen never reappears, so the machine on the other side keeps working exactly as it did yesterday, and nothing tells you.
A rotation defends against a future login attempt. It does nothing about an open session, nothing about a recovery phone number, nothing about a shared mailbox somebody can still open, and nothing about the vault seat they still occupy.
So the reflex covers roughly one fifth of the problem and produces most of the confidence.
Nobody has to do anything for this to hurt
Worth being clear about the threat, because the wrong mental model produces the wrong checklist.
The picture in most people’s heads is a bitter ex contractor logging in at midnight to wreck something. That happens occasionally. It is rarely the version you actually get.
The ordinary version is inert. A signed in session sitting on a personal laptop that gets resold, lent to a flatmate, or restored onto a new machine a year later. A password saved in a browser and synced to a phone you have never seen. A number still listed on an account and still receiving codes. An ssh key still in an authorized_keys file on a box nobody has logged into since the work finished.
None of that requires anyone to decide anything. It sits there working.
Which is why “I trust them” is an answer to a question nobody asked. You are closing doors. Whether anybody intends to walk through them is a separate matter and not one you can verify.
The order, and why it is that order
Five steps. The sequence carries more weight than any single step in it.
Sessions and linked devices first. Every platform names this differently: active sessions, where you are signed in, devices, connected apps. Find it and end everything you do not personally recognise. Do this before the rotation, because a live session can sometimes be used to set the password again, and then you are the one locked out, by somebody who was not even trying.
Credentials second. Now the rotation lands, because there is no surviving session to walk around it. Do the api keys, access tokens and ssh keys in the same pass. Those outlive passwords by years and nobody thinks of them as credentials.
Vault seat third. Remove the person from the shared collection, then read what was in that collection. If access was granted through a password manager rather than by sending the password itself, this is one click. That is the entire argument for granting it that way. Mine are split into per job collections in Bitwarden, so a contractor sees eight items and nothing else.
Recovery contacts fourth. Its own section below, because this is the one that goes wrong.
Audit last. Login history, device list, the sent folder of any mailbox they held, the change log on anything with money attached. It comes last on purpose. The first four steps stop the bleeding. This one only tells you how much there was.
Recovery contacts are the door that never closes
A recovery contact is a phone number or an email address a platform will accept as evidence you own the account. It lives outside the password. Rotating the password does not disturb it. Ending sessions does not disturb it.
A contractor adds their own number in month two because a verification screen is blocking work on a Tuesday and theirs is the phone on the desk. Sensible at the time. Nobody writes it down, because it was a thirty second detour on the way to something else.
That number stays a route into the account for as long as it stays on the record. Not a route to a session. A route to the account, including the ability to take it back from you.
And it will not surface anywhere you would think to look. Team pages skip it. Vaults skip it. It lives in the account’s own security settings, four screens deep, which nobody opens unless something has already gone wrong.
So open them. Every account the person touched, one at a time, reading what is on the screen instead of what you remember putting there.
The shared mailbox belongs in the same category and gets forgotten for the same reason. A support address or an operations inbox is nobody’s personal account, so it is nobody’s job on the last day. Everything that lands in it includes password reset links for other things.
The account nobody remembers
Somebody had access to three accounts. You will remember two.
The two you remember are the ones they worked on constantly, because those were the job. The third is the one you handed over on a Tuesday in their first month because something needed doing and they were the person free. It never became part of the work, so it never became part of the story you tell yourself afterwards about what they touched.
Nothing you do on the last day covers that third account, because you do not know it belongs on the list.
Calling that a discipline problem misses what is happening. You cannot solve it at the exit at all. At the exit you are working from memory, and memory here does not fade so much as edit. You recall the arrangement you meant to have, in detail, with confidence.
Write it on the way in
The only thing that makes a departure survivable is a record kept while people were arriving.
One line per grant: date, person’s name, the account or system, and how the access was given. That is the format. It takes about fifteen seconds at the moment of granting, when every field is already on the screen in front of you.
On the exit you filter for that name and the list is complete by construction. No recall involved.
Two details make it work. The name has to be a person, not a role, because “the VA” covers three different people over eighteen months and none of them offboard together. And the line needs a second half added when they leave: what was rotated, what was removed, and the date. If you cannot answer that for somebody who left six months ago, they still have access and you are guessing at the size of it.
I keep the same discipline on the infrastructure side for a duller reason. Every proxy port I provision carries the customer’s identity in its name, so months later I can answer who held it before it was recycled without reconstructing anything. Access records are the same trick pointed at people instead of ports.
Five months
A contractor of mine finished a piece of work and I did what felt like a thorough job. Passwords rotated, vault seat pulled, shared documents closed, all of it inside an hour.
About five months later I was in the security settings of one of those accounts for an unrelated reason and found a phone number listed as a recovery contact. It was not mine.
It had gone on during the work, for a reasonable cause, on a day when a verification prompt was in the way and the fastest path through it was the phone belonging to the person sitting at the desk.
Nothing came of it, and I am not writing this up as a near miss. As far as I can tell nothing happened at all.
The five months are what bother me. For five months there was a working route into that account held by somebody with no remaining connection to my business, and I found it by accident rather than by process. I had done four of the five steps, and the one I skipped was the only one that never expires on its own.
Recovery contacts now get read on every account on the list, and the check gets a date written beside it so that future me can tell the difference between having done it and having meant to.
Say how it ends on the first day
The real reason this gets done badly has nothing to do with technique.
It feels like an accusation. Somebody leaves on good terms, you liked working with them, and within the hour you are stripping everything they held. It reads as an announcement that you expected to be robbed.
So it gets delayed a week. Or half of it gets done. Or it gets done quietly in the hope that nobody notices, which is the worst of the three, because from the outside half a procedure and a whole one look the same and only one of them works.
The fix is a sentence, delivered at the start rather than the end. When you grant access, say how it ends: same procedure for everybody, runs on the last day, takes about twenty minutes, standard. I say a version of that now whenever I hand anything over, and it has not once landed badly.
Once it has been announced in advance, doing it fast is you keeping your word. Most people leaving are relieved, because holding keys to a business you no longer work for is a liability they did not ask for either.
What this buys is narrow and worth being honest about. It closes one category of exposure, the one that opens every time a person stops working with you. The account keeps every other weakness it had yesterday. But this is the category where thoroughness costs twenty minutes and sloppiness costs a door that stays open until somebody trips over it, which in my case took five months and a coincidence.
The stack we run and the guides behind it are at Multi Account Ops.
Get new guides and videos first — join the Telegram channel.