Offboarding
Closing access when someone leaves the team: what Ilia Zavialov puts first
A small team rarely has a single moment where someone officially leaves. Notice periods run out and handovers get compressed into a final week, so the actual departure often happens faster than the paperwork. The real question is which logins, shared accounts, and payment tools still answer to that person once they stop coming to standups. Skipping that question, or answering it slowly, is how a clean exit turns into an open door.
English version for the United States.
01
The order that matters: what to close first
The risk starts the moment a resignation letter lands or a founder decides a role is no longer needed, well before the last working day arrives. Attention shifts to hiring a replacement, and the departing person has little reason to keep things tidy. The day that decision becomes real is when closing access when someone leaves the team truly begins, because the gap before the last day is where access stays live longest.
Once that clock is running, a fixed order matters, because a small team under pressure closes whatever is easiest to find first. The starting point is the identity layer: the work email address and whatever single sign-on service sits behind it. Almost every other account can be reset through that inbox, so leaving it open for an afternoon keeps every other lock pickable.
After identity comes anything that moves money or speaks for the company: the finance dashboard, the payment processor, the domain registrar. A former team member can cause real damage from inside using only a login that still works. Shared drives, chat channels, and subscription tools come after those two tiers, and closing the ten most sensitive accounts while forgetting three quiet ones still leaves a working path in.
02
Why a shared password cannot fix a shared account
Small teams share logins constantly. A five-person company might have one password for the business Instagram account, one for the domain registrar, one for an analytics dashboard that only offers a single paid seat. Nobody decided this on purpose; it is what happens when a tool's pricing or design assumes a single owner and a team grows around it anyway.
The trouble shows up the day someone with that password leaves. Changing the password is the first thing most small teams try, and it only solves half the problem, since the remaining three or four people still need the new one, which travels through a group chat or a sticky note and recreates the exposure the change was meant to close. Any device that stayed signed in through a saved session keeps working after the reset too.
Closing access when someone leaves the team on a shared account only works if the account stops being shared before that day arrives. Individual logins, or at minimum named roles inside a single tool, mean a departure removes one name from a list, with nobody else needing to learn a new secret. That change costs a few pounds a month and saves the far more expensive scramble of guessing who still remembers the old password six months later.
03
Sessions and tokens survive password changes
Passwords and sessions work as two separate locks. Once someone signs into an email account, a project tool, or a shared drive, the service usually issues a token that keeps that browser or device signed in until it is told otherwise, sometimes for months. Changing the account password later does not touch that token, so a laptop that was never asked to sign out again stays a working way in.
The same logic applies well beyond a single login screen. A personal calendar linked to a scheduling tool, a phone number tied to two-factor recovery, or an API key generated for a script nobody remembers writing, all keep functioning after a password reset. None of them check the password again once set up, which is what makes them convenient for a busy team and risky the day one member leaves.
Forgotten access points like these let an old login keep paying off long after anyone thinks to check it. Tokens and connected apps need the same scrutiny as the password itself, because closing access when someone leaves the team means checking each one individually rather than assuming a single reset covers them. Resetting a former employee's password without also closing their forwarding rule, linked device, or API key still leaves an open door.
04
Payment tools and standing permissions
Payment access in a small team rarely lives in one place. One person might hold the company card, another has admin rights on the accounting software, and a third manages a project wallet if the business touches cryptocurrency at all. Canceling the physical card when someone leaves feels like it closes the financial side of the departure, and often it closes only the smallest part of it.
A card number and a standing permission are different things. Approval phishing works by getting a smart contract to hold a standing permission through a signature such as approve, setApprovalForAll, Permit, or Permit2, a permission that keeps working until revoked, no password or seed phrase required. The FBI's Internet Crime Complaint Center puts cryptocurrency behind roughly half of all reported US fraud losses, one reason a wallet approval left in someone's name deserves its own line on the checklist.
The scale shows up in the numbers on personal wallets. Chainalysis recorded 158,000 thefts from personal crypto wallets in 2025, affecting 80,000 unique victims. Losses from classic wallet drainers fell from 494 million dollars in 2024 to 83.85 million in 2025, an 83 percent drop, with the average loss on an affected wallet down from about 1,488 dollars to 790. A payment checklist still needs its own line for every platform's authorized approvers, since only that closes the specific permission.
05
The inbox is the master key
Email earns a category of its own because almost every other tool treats it as the ultimate recovery method. A forgotten password on the accounting platform or the domain registrar almost always gets solved by a reset link sent to the address on file. Whoever can read that inbox can eventually get into almost anything connected to it, regardless of what password those tools currently have.
Small teams often overlook the quieter settings around an inbox, the parts nobody checks once the main password looks closed. A forwarding rule set up months earlier can keep sending copies of every message to a personal address long after the main login stops working. A phone number left as the two-factor recovery option keeps that channel open after the password has changed twice, and delegate access to a shared mailbox often outlives the person's own account entirely.
The inbox is the first item on that list for closing access when someone leaves the team, checked in full: sign-in disabled, sessions forced out, forwarding and delegate rules reviewed, and any recovery phone number removed. Doing this after cleaning up other accounts defeats the point. A live inbox can request its way back into any account already closed, simply by asking each service for a new reset link.
06
Ownership and speed: who runs the list, and when
Offboarding often has no clear owner in a small team, and that gap is more dangerous than any single missed account. The founder assumes a co-founder is handling it, and the co-founder assumes whoever set up the tool will remember to remove the departing person from it. Everyone assumes somebody else holds the actual list, and in a team of four or five people, that assumption is often correct for nobody.
The fix does not require hiring anyone. One person, named in advance and not necessarily the most technical member of the team, owns the checklist and works through it in a fixed order on the day itself. That same person keeps a running inventory of who has access to what while everyone is still employed, because building it for the first time on someone's last day burns the hours that should go towards actually closing accounts.
Speed matters for a reason that has nothing to do with any single dramatic incident. Most of the risk comes from ordinary drift: a session nobody thought to end, a forwarding rule nobody looked for, a wallet permission that never came up in conversation. Closing access when someone leaves the team on the same day, covering identity, logins, and payment tools in one pass, is what keeps that drift from ever starting.
| Access point | Risk if left open | Action on departure day |
|---|---|---|
| Email and single sign-on | Powers password resets for almost every other tool | Disable sign-in and force out active sessions first |
| Shared admin or finance logins | One password known by several people survives a single reset | Replace with individual accounts before anyone leaves |
| Payment platforms and wallets | Standing approvals and authorized-user roles outlive a canceled card | Remove the person from every approver or user list |
| Cloud storage and file sync | Local copies keep syncing through an already-open session | Revoke the linked device and rotate the account password |
| Connected apps and API keys | Tokens and keys stay valid after a password change | Rotate keys and disconnect linked third-party apps |
| Building or office access | A keycard or door code runs on a separate system from any password | Deactivate the card and change any shared door code |
Questions and answers
What is the first step in closing access when someone leaves the team?
Start with the identity layer: the work email account and any single sign-on service behind it. Almost every other tool can be recovered through that inbox, so it has to be locked down, with sessions forced out, before anything else on the list.
Why doesn't changing a shared password fully close the risk?
A password known by several people has to be shared again with everyone who still needs it, which recreates the same exposure through a chat message or a note. Any device that stayed signed in through a saved session also keeps working after the reset, since a password change does not force existing sessions to log out.
How should a small team handle a shared bank card or payment login after someone leaves?
Canceling the card is only the first step. Every payment platform, accounting tool, or wallet involved should be checked for a list of authorized users or approvers, and the departing person's role there needs removing directly, separately from the card itself.
Does a password reset remove access from connected apps and API keys?
Usually not on its own. Integrations, API keys, and mobile app logins are often set up to work without asking for the password again, so they keep functioning until someone rotates the key or disconnects the app by hand.
Who should be responsible for offboarding in a small team with no IT department?
One named person, decided in advance for every departure, owns the checklist and keeps an up-to-date list of who has access to what. That preparation is what lets the checklist run in minutes on the actual day.
How quickly should access be closed after someone leaves the team?
The same day, covering identity, shared logins, and payment tools in one pass. Most of the exposure in a slow offboarding builds up from ordinary things staying open by accident, such as a session, a forwarding rule, or a standing payment permission.