Offboarding Without Losing Access: Closing Accounts Safely
An employee or contractor leaves — do you actually control the ad accounts and social profiles they used? A practical offboarding checklist.
An employee quits, a freelancer wraps up a project, a contractor's agency gets replaced — and only then does it become clear that access to dozens of ad accounts, social profiles, and marketplace seller accounts is tied to that person's phone, their email for 2FA, and their personal Chrome profile. The contract is terminated on paper, but the accounts are still, in practice, in their hands.
This isn't a rare edge case. In media buying, SMM agencies, and e-commerce, teams grow and turn over faster than access processes get built. While someone is still on the team, nobody thinks much about who exactly is holding the passwords and codes. The problem surfaces only at the moment of separation — and by then it's often too late.
Why this is a systemic problem, not an exception
The classic access setup looks like this: a spreadsheet of logins and passwords in Google Docs, 2FA tied to a staffer's personal phone number, work accounts open in their personal browser on their personal laptop. This works fine as long as the relationship is amicable. But the moment there's friction — a delayed paycheck, a KPI dispute, resentment over being let go — a former employee retains physical control over company assets:
- they can change the password before you manage to react;
- 2FA is tied to their phone — you can't log in even with the right password;
- cookies and sessions live in their personal browser, and a formal "access revoked" changes nothing while the session is still active;
- if accounts were run through their personal proxies or from their own device, a password change doesn't stop them from simply continuing to use the live session.
There's a flip side too: if access is revoked abruptly, without a procedure, you can accidentally lock yourself out of working accounts. From the platform's point of view, a burst of password changes and IP changes looks like account compromise, and the account gets frozen for review.
Proper offboarding isn't "press one button" — it's a sequence of steps planned in advance, ideally designed back at the onboarding stage.
Preparation has to happen before the departure, not on the day of it
A safe exit is only possible if access was granted correctly in the first place. If, from day one, all work accounts lived in profiles with assigned roles and limited permissions — rather than in an employee's personal browser — closing off access is a matter of minutes. If a person set up accounts however was convenient for them, in their own browser, under their own phone number, untangling it afterward can take days or weeks of manual work.
So the first practical piece of advice isn't really a checklist item for departure day — it's a requirement for how work is structured in the first place: client and ad account profiles should live in a shared team workspace, not in employees' personal browsers. Roles, limits, and the handoff procedure between teammates are covered in more detail in team roles and profile handoff.
- lev opened Airdrop zkSync 07
- artem closed FB · US · BM-14
- maya is watching artem
- lev transferred TikTok Shop 03
Checklist: what to verify on the day someone leaves
Below is a sequence worth running through in full, even if some steps seem unnecessary in a given case. A skipped step usually resurfaces a month later as "wait, why is this account locked" or "who even has access to this account."
| Step | What to do | Why it matters |
|---|---|---|
| 1. Map the scope of access | Pull a full list of every profile, account, and service the person had access to | Without a complete list, some access points go unnoticed |
| 2. Revoke the role in the system | Remove the role and permissions in the shared profile pool | The person loses the ability to open profiles immediately, without delay |
| 3. Reassign profile ownership | Transfer profiles to another teammate or back to the shared pool | Profiles don't disappear along with the departure |
| 4. Change profile passwords | Reset passwords anywhere the departing person knew them | Old saved credentials stop granting access after the change |
| 5. Rotate 2FA | Re-link two-factor authentication to a work number/email | The most common way a former employee retains control |
| 6. Check sessions and cookies | Log out of active sessions, clear cookies if needed | An active session doesn't require a password at all |
| 7. Check extensions and API keys | Revoke automation tokens, review installed extensions | Automation may have been running on the person's own keys |
| 8. Check proxies | Disable proxies the person bought or configured personally | They may still see traffic or retain access to the proxy provider's panel |
| 9. Review the activity log | Check recent actions before the departure | Reveals attempts to export data, change an email, or link a new phone number |
| 10. Update documentation | Refresh the list of people responsible for each account | So the next offboarding doesn't start from zero |
This is a general sequence, but the weight of each item shifts depending on who's leaving — a full-time employee, a freelancer, or a contracted agency.
Employees, freelancers, and contractors carry different risks
A full-time employee usually works with company tools, has a corporate email, and likely signed an NDA. The risk here isn't malice so much as inertia: they might simply forget they're still logged into ten accounts from their personal phone, if 2FA was tied to it. Offboarding here is mostly hygiene — revoke, re-link, verify.
A freelancer is riskier, because there's often no single point of entry: they may have created separate accounts per project, used their own proxies, corresponded with a platform's support team under their own name. When the engagement ends, it's not enough to just take back a password — you need to confirm the account itself is registered under company or client details, not the freelancer's email. Otherwise they formally remain the account owner even after a password change and can recover access through platform support.
A contracted agency managing client accounts is a different story altogether: offboarding here happens between two separate businesses, not within one team. If the agency used a shared profile pool, every client profile needs to be handed over to the client or the new agency in full, with passwords changed, 2FA rotated, and proxies reviewed. If client profiles were running in agency staffers' personal browsers, the handover turns into a painful migration: accounts need to be re-warmed, cookies rebuilt, the whole environment set up from scratch. Issues of this kind, and how to recover access once an account has already taken a hit, are covered in diagnosing and recovering a flagged profile — many of the symptoms described there show up precisely after a sloppy access handover.
Transferring a profile without exposing the password
The core technical problem in offboarding is how to hand a working account to a new owner without revealing the password to someone who hasn't used it before, and without losing the warmed-up session, cookies, and history in the process.
If profiles are organized as isolated environments with a managed fingerprint, rather than rows in a spreadsheet, this is solved without drama: the profile is simply reassigned to another team member inside the shared pool, along with its cookies, history, and attached proxy. The new owner gets the working environment exactly as it was, without having to log in again and risk a suspicious new-device or new-IP login — to the platform, it looks like a continuation of the same session, not a change of user.
This is especially useful during the transition: while the new person is still getting up to speed, you can watch their work in the profile via live view, and step in and adjust settings remotely if needed, instead of asking them to hand the password back.
A separate issue is 2FA keys. If 2FA codes aren't stored in an employee's personal authenticator app but in a vault tied to the profile itself, rotating access doesn't require a frantic reinstall of Google Authenticator on a new phone and a support ticket with the platform. The code simply becomes available to whoever the profile is now assigned to.
How profile data encryption and the 2FA vault actually work, and why the server can't read a profile's contents even in principle, is covered in profile encryption and the 2FA vault. For offboarding, this means something simple: even if a former employee somehow got access to the server (which the architecture rules out anyway), they couldn't decrypt the profile data without the company account's password.
Common mistakes when closing access
Removing the user without touching the profiles. If a role is revoked but passwords and 2FA stay the same, and sessions remain active, a formal "access revoked" changes nothing at the level of the actual platforms. The person can keep using the open session in their own browser indefinitely.
Changing everything at once, abruptly. Mass password resets, logging out of every session, and changing IPs for dozens of accounts all at the same moment looks suspicious to platforms and can trigger security reviews — on exactly the accounts you're trying to protect. It's safer to rotate in batches spread over a day or two, especially for accounts with history and reputation.
Forgetting the linked email. If account recovery for an ad account or social profile runs through email, and that email was also managed by the departing employee (or registered in their name), changing the account password solves nothing — they'll recover access through the email in five minutes.
Not checking automation. If someone set up scripts through Puppeteer or Playwright for warm-up or routine tasks, they may have left local API tokens or saved sessions in the code. How local profile automation works and what to check when handing off scripts is covered in Puppeteer and Playwright automation for profiles.
Relying on a verbal agreement. "They promised to delete all the data" is not a procedure. You need a record: who checked what, and when, ideally tied to the activity log rather than a manager's memory.
The activity log as a tool, not a formality
Logs deserve special attention. Many teams enable activity logging as a formality, "just in case," and never actually look at it. At offboarding time, it's the first thing worth opening: who last accessed the profile, changed settings, exported cookies, installed a new extension. If, the day before an official departure, someone suddenly exported cookies from a dozen client accounts, that's a reason to do more than just change passwords — it may warrant a closer look, possibly with legal involved, if client data is at stake.
The log is also useful for assigning responsibility when an account gets flagged after someone has left: you can check whether anything suspicious happened in the final days of their work, rather than chalking it up to bad luck.
The problem scales with the team
For a freelancer with five profiles, offboarding is a half-hour task. For an agency with dozens of staffers and hundreds of client profiles, without a procedure or a role model in place, every personnel change turns into chaos. If a team has already grown to that scale, it's worth first putting the structure of the profile pool in order — covered in detail in organizing hundreds of profiles without chaos. Without a basic structure — groups, tags, assigned owners — closing off access for one person turns into an archaeological dig through the entire database.
GetAntik has a role model with per-member limits, an activity log, profile handoff between teammates without exposing the password, and on-device encryption keyed to the account password — meaning the architecture itself doesn't let a departing employee "take a profile with them," even if they copy files locally. The full set of team features is on the team collaboration page, and encryption and security details are on the profile security page.
FAQ
Do proxies need to change during offboarding if the employee didn't buy them personally? If proxies were assigned centrally through the team's shared proxy manager, there's no need to touch them — changing IPs without reason can itself look suspicious to a platform. Only change proxies whose provider panel the departing person had personal access to.
What if an account is registered under an employee's personal email instead of the company's? This needs fixing before the departure, not after: switch the linked email to a corporate one in advance, while the employee is still cooperative and willing to confirm the change through their own inbox. After they leave, this becomes either impossible or requires contacting platform support with proof of business ownership.
How long should a full offboarding procedure take? For one employee with a dozen or two profiles, usually an hour or two for the process itself, plus a day or two of staggered password and 2FA rotation to avoid triggering a compromise review.
Should a platform be notified about a change in account administrator? For ad accounts and business accounts on many platforms, this is explicitly built into the rules — it's better to formalize the admin change through the platform's own built-in access settings than to simply reset the password from your side.
How often should access lists be reviewed if the team hasn't changed in months? Checking the list of people responsible for key accounts against the actual team roster once a quarter is worthwhile — it often turns up access still held by someone who changed roles internally long ago, even though they never technically left.