When Employees Share Accounts: How to Offboard Without Breaking Shared Tools

Your designer just gave notice. They had access to the company Figma account, the Canva Pro subscription, and the HubSpot login your team shares via 1Password. You change the Figma password — and three other designers get locked out of their active sessions. You remove the Canva account — and realize your departing designer was the billing owner. The HubSpot password gets rotated, but their browser still has an active session for the next 90 days. Shared-account offboarding breaks in ways that individual-account offboarding doesn't, and most startup offboarding guides don't cover it.

Why Shared Accounts Are a Startup-Specific Problem

Larger companies can afford a seat for every user on every tool. At 15–40 people, that math doesn't work. One Figma Professional seat per designer costs $15/month — but when you have three designers sharing a single $15 seat because "we're rarely editing at the same time," you've created a shared-credential situation that HR software doesn't model. The same happens with Canva Pro, HubSpot Starter, Adobe Creative Cloud, SEO tools, and billing accounts tied to a personal email. Shared accounts are practical. They become a problem exactly once: when someone leaves.

The Three Types of Shared Accounts (Each Breaks Differently)

Not all shared accounts are the same. The offboarding action required depends on the type.

Type 1: Shared credentials — one login, multiple people who know the password. This is the most common pattern: a Canva Pro account with a single email and password stored in 1Password, a stock photo subscription, a scheduling tool your ops lead and CEO both use. The departing employee knows the password. The fix sounds simple — rotate it — but it's not, because everyone else on the team who uses that credential needs to update their copy simultaneously or they get locked out.

Type 2: Individual seats on shared workspaces with ownership roles — here, everyone has their own login, but the departing employee holds an owner or admin role that gives them elevated control over the whole team's work. A Figma team where the designer who's leaving is the team owner. A Notion workspace where they're the workspace admin. A GitHub org where they're the only owner. Removing their account without first transferring those roles can break things for the whole team.

Type 3: Service accounts or bot accounts — billing accounts tied to a personal email, AWS root accounts, domain registrar logins, accounts used for API keys or integrations. These are the most dangerous type, because they're often not on the standard offboarding checklist at all. If a developer registered your company's Cloudflare account under their personal Gmail and now they're leaving, that's a crisis, not a checklist item.

Why Changing the Password Isn't Enough

The instinct when someone leaves is to change the shared password immediately. That instinct is right, but it's incomplete — and if done wrong, it causes more problems than it solves.

Session cookies persist after a password change. Many SaaS apps keep existing browser sessions alive even after a password is rotated. HubSpot, Notion, and Canva all issue session tokens that can stay valid for 30–90 days. Changing the password prevents future logins — it doesn't log out existing ones. You need to explicitly revoke active sessions (most apps have a "log out all devices" button in security settings).

Password manager copies don't auto-update. If four people have the old shared password saved in their personal 1Password vault, rotating the account password means you need all four people to update their saved credential that same day. If even one person doesn't, they'll get locked out the next time they try to log in — and if they use "forgot password" to recover it, they'll reset it back to something only they know, locking everyone else out.

Ownership roles survive password changes entirely. In Type 2 accounts, the departing person's ownership or admin role has nothing to do with the shared password. Removing their account or changing a password doesn't transfer their ownership role — that's a separate step inside the application. This is the most common mistake: a startup revokes all individual-seat access and rotates shared passwords, then discovers two weeks later that the departing designer was the sole owner of three Figma projects and nobody can rename or delete them.

The SaaS access sprawl that accumulates over someone's tenure makes this worse — they may have been granted access to tools you've forgotten about, and each of those needs its own offboarding action.

The 4-Step Shared-Account Offboarding Flow

Run these steps in order. The sequence matters — doing Step 3 before Step 2 will break things for your team.

Step 1: Audit before the exit date, not after. Before the person's last day, pull up every shared tool they had access to. Check your password manager for shared credentials they were granted. Look at which apps gave them admin or owner-level roles. This is not a 5-minute task — budget 30–60 minutes and involve their manager. The goal is a complete list of: (a) shared credentials they know, (b) applications where they hold an ownership or admin role, and (c) any service or billing accounts tied to their identity. A who-has-access audit run quarterly makes this step much faster because you already have the inventory.

Step 2: Transfer ownership roles before removing the account. For every Type 2 account, transfer their ownership or admin role to another team member before you deactivate their account. Do this while they're still employed — it's far easier to have them initiate the transfer than to contact the tool's support team afterward to recover orphaned assets. Figma, Notion, GitHub, and Google Workspace all support ownership transfer from within the app, but only while the original owner's account is still active.

Step 3: Rotate shared credentials and update all copies simultaneously. Pick a time when the team is online. Rotate the shared password in the account. Update the credential in your shared password manager immediately — in the same session. Alert all team members who use that credential to refresh their copy before they next log in. This tight coordination is what prevents the "someone resets it to recover access and locks everyone else out" failure mode.

Step 4: Revoke all active sessions. After rotating the password, go into each app's security settings and trigger "log out all devices" or "revoke all sessions." This is the step most offboarding checklists miss. In HubSpot: Account Settings → Security → Active Sessions. In Notion: Settings → My account → Log out of all devices. In Canva: Account Settings → Security → Active Devices. Each app is slightly different, but the option exists on almost every modern SaaS platform.

The Five Tools Where Ownership Transfer Is Most Critical

These are the tools where forgetting Step 2 causes the most damage.

Figma. Every file, project, and team has an "owner" role separate from editor or viewer access. If a designer who's leaving owns team projects, those projects can't be deleted, archived, or moved by anyone else after they're gone. Transfer file and project ownership before their account is deactivated. On paid plans, you can do this from within Figma's settings panel. On the Free plan, the departing designer needs to initiate the transfer themselves.

Notion. Workspace "owners" (not just members) have elevated control over integrations, billing, and workspace settings. A former owner can't take down the workspace remotely, but you'll hit walls when trying to modify integrations or billing if no active owner remains.

GitHub. This is the highest-risk one. GitHub organizations require at least one owner at all times. If the departing developer is the sole org owner, GitHub will prevent you from removing their account. Add a second owner (ideally a technical co-founder or CTO) before offboarding. Also check: repository admin roles, branch protection rule owners, and third-party OAuth app grants — these survive account removal.

Google Workspace. You cannot have zero super admins. Assign another user as super admin before removing the departing employee's account. Also check: Google Groups they own (group ownership transfers aren't automatic), shared drives they manage, and service account keys they may have generated.

HubSpot. The "Super Admin" role controls billing, integrations, and user management. If the person leaving is your only super admin, you'll lose the ability to manage users and integrations until you reassign it. Also check: workflows, sequences, and reports they own — these don't break when their account is removed, but orphaned assets become harder to manage.

When Shared Accounts Are Actually Fine (And When They're Not)

Not every shared account needs the full treatment. Here's a quick heuristic:

Lower-risk shared accounts: Read-only research tools (Crunchbase, G2), stock photo subscriptions with no client data, subscription aggregators with no production access. These still need password rotation when someone leaves, but the risk of a lingering session is low.

Higher-risk shared accounts: Anything that stores client data (HubSpot, Salesforce, Intercom), anything with write access to production or code (GitHub, AWS, Vercel), any tool where the person held a billing or ownership role, and any account where a session persistence could enable data export or deletion after someone leaves. Treat these with the full 4-step process.

The underlying issue — that people accumulate more access than they actively use — is covered in the offboarding gap between HR and IT tools. Shared accounts are the category that falls furthest through that gap, because HR software tracks "this person is an employee" and IT tools track individual SSO logins — and shared credentials on a seat-capped account fall in neither bucket.

Manual vs. Automated: What the Process Looks Like

The manual process works at 5 people. At 20–40 people cycling through roles every year, it fails not because the team is careless but because there's no system that connects the HR event (this person is leaving) to the full scope of their shared access.

FAQ

Does changing a shared password immediately log out the departing employee? Not always. Password changes prevent new logins, but existing browser sessions typically remain valid until they expire (often 30–90 days) or are explicitly revoked. Always use the "log out all devices" option in the app's security settings after rotating a shared password.

What if the departing employee is the only owner of a critical tool and won't cooperate? For most SaaS tools, you can contact support with proof of business ownership (billing records, domain ownership) to recover admin access. For GitHub specifically, you can submit a DMCA-style org recovery request. Prevention is better: always ensure there are at least two owners on every critical tool.

Should we stop using shared accounts altogether? For tools that store sensitive data or production access, yes — per-seat accounts are worth the cost. For low-risk read-only tools, shared credentials with a managed password manager are fine as long as you have a credential rotation protocol on every offboarding. The goal isn't zero shared accounts; it's knowing which ones you have and having a process for them.

How do we track which employees have access to shared accounts? The simplest approach: maintain a shared-account registry — a single doc or spreadsheet listing every shared credential, who has access to it, and when it was last rotated. Update it when someone is onboarded or offboarded. A quarterly access review is a good forcing function to keep this inventory accurate.

Offboard Without the Chaos

Optserv connects the HR event — this person is leaving — to the full scope of their access, including shared accounts, ownership roles, and team credentials. When someone's departure is recorded, the offboarding workflow surfaces every shared credential they touched and walks the team through rotation, ownership transfer, and session revocation in a single flow. Start a free trial at app.optserv.ai and run your next offboarding without the scramble.

Sources

• Figma Help Center — Team permissions and ownership transfer: https://help.figma.com/hc/en-us/articles/360039970673-Team-permissions
• GitHub Docs — Managing organization ownership: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/maintaining-ownership-continuity-for-your-organization
• HubSpot Knowledge Base — User permissions guide: https://knowledge.hubspot.com/user-management/hubspot-user-permissions-guide