What happens to your accounts when you leave the company

TL;DR — When someone leaves a company, their accounts should usually be disabled first, access tokens and sessions revoked, ownership of shared assets transferred, and only then should deletion be considered. The key takeaway: "delete the user" is rarely the first step; the safer default is "block sign-in, preserve business data, transfer ownership, then remove what is no longer needed." Reading time: ~7 min

What it is and where it sits

"What happens to your accounts when you leave the company" is really an offboarding process: the set of actions that removes a person’s access to systems while keeping the company’s data, services, and audit trail intact. In plain terms, it answers questions like:

• Can the person still sign in?
• Do their phone, laptop, and browser sessions still work?
• What happens to email, files, code repositories, cloud access, and billing logins?
• Who now owns the things they created?

This sits in the company’s identity and access management stack, often shortened to IAM (the system that decides who can sign in and what they can access). In many organizations, one central identity provider such as Google Workspace, Microsoft Entra ID, Okta, or another directory is the starting point. That identity system talks to:

• email and calendar
• file storage
• chat tools
• source code hosting
• cloud dashboards
• VPN or single sign-on apps
• device management tools
• password managers

What it replaces is the old, risky pattern of removing access one app at a time by memory or spreadsheet. A mature setup uses one identity source, group-based access, and a repeatable checklist.

In a typical flow, the identity system is the hub. Disabling the person there should stop access to many connected systems, but not always all of them. Some systems have local accounts, API keys, or shared credentials that must be handled separately.

HR / manager notice
        |
        v
Identity system (directory / SSO)
        |
        +--> Email account disabled or delegated
        +--> File access removed / ownership transferred
        +--> Chat and calendar access blocked
        +--> Cloud / Git / VPN access revoked
        +--> Sessions, MFA devices, API tokens revoked
        +--> Device marked for wipe or return
        |
        v
Audit logs and retention

The important architecture point is this: a person usually has three kinds of access at once, and each must be handled differently.

Three kinds of access

1. Identity account — the main user login in your directory or SSO provider.
2. Sessions and credentials — active browser sessions, mobile app logins, MFA devices (multi-factor authentication devices), SSH keys, API tokens, personal access tokens.
3. Owned resources — email mailbox, files, repositories, dashboards, cloud projects, DNS zones, CI/CD pipelines, invoices, and automation accounts.

If you only disable the identity account but forget owned resources, the business can lose access to important assets. If you only transfer assets but forget sessions and tokens, the former employee may still have working access for hours, days, or longer.

How it actually works

Let’s walk one realistic example end to end.

Example: a project manager leaves an agency

Assume the person has:

• a company email account
• access to Slack or Teams
• access to Google Drive or SharePoint
• a GitHub account connected by SSO
• access to a cloud dashboard
• a password manager vault
• a company laptop

The manager tells HR that the employee’s last day is today at 5 PM.

Step 1: Freeze sign-in at the identity provider

In your identity provider’s admin dashboard, open the user and choose the equivalent of:

• Directory / Users → [Person] → Block sign-in
• or Users → Suspend user
• or Identity → People → Disable account

This is usually the first action because it stops new logins through SSO.

⚠️ If you delete the account immediately instead of disabling it first, you can break email forwarding, lose access to files the person owns, and remove evidence you may need for audits or disputes.

At this point, the person often cannot start new sessions. But existing sessions may still work until they expire unless you revoke them.

Step 2: Revoke active sessions, MFA, and tokens

Still in the identity or app admin dashboard, use the actions that usually read like:

• Security → Sign out user from all sessions
• Authentication methods → Remove MFA devices
• Applications → Revoke app tokens / OAuth grants
• Developer settings / Access tokens → Revoke personal access tokens

Why this matters: if the person signed in on a phone yesterday, disabling the main account may not instantly kill every app session. Revoking sessions forces re-authentication. Since the account is disabled, re-authentication fails.

Step 3: Transfer ownership of business assets

Now preserve continuity.

For email, use your mail admin console to either:

• delegate mailbox access to a manager, or
• set forwarding to a shared mailbox, or
• convert to a retained/inactive mailbox if your platform supports it

For files, use the file admin console to transfer ownership:

• Admin console → Users → [Person] → Transfer files
• or Drive / OneDrive admin → Reassign ownership

For Git hosting, transfer repositories, teams, and deploy keys away from the user’s personal account and into an organization account.

For cloud dashboards, remove the user from projects and check for resources they created with personal credentials, such as:

• API keys
• service accounts (non-human accounts used by software)
• DNS zones
• billing contacts
• Terraform or CI/CD secrets

This is the part many teams skip, and it is where outages happen. The user may not just have access; they may be the only listed owner of something critical.

Step 4: Remove local and non-SSO access

Not every app uses central SSO. Some systems still have local usernames, SSH keys, or shared secrets.

Examples:

• VPN account created directly in the VPN tool
• database user created manually
• WordPress admin account
• cPanel or hosting login
• AWS access key created for a human user
• SSH public key on a server

These must be removed in each system’s own dashboard or config.

⚠️ Removing the wrong cloud key, database user, or SSH key can break production systems if automation is using that credential. Before deleting a credential, check where it is used and replace it with a service account if needed.

Step 5: Handle devices and local data

If the person had a managed laptop or phone, the device management tool should mark it for return, lock, or wipe.

Typical dashboard path is something like:

• Devices → [Device] → Lock
• Devices → [Device] → Wipe corporate data

This protects cached email, downloaded files, and saved sessions.

Step 6: Retain logs and then decide on deletion

Only after access is blocked, assets are transferred, and retention is confirmed should the company decide whether to delete the account.

Deletion may be immediate for contractors with no retained data needs, or delayed for employees where legal, finance, or operational records must be preserved.

The practical sequence is:

1. Disable sign-in
2. Revoke sessions and tokens
3. Transfer ownership
4. Remove local access
5. Secure devices
6. Retain logs and data according to policy
7. Delete later if appropriate

When to use it (and when not to)

You need a formal offboarding process whenever a person had access to business systems, even if they were a freelancer or temporary contractor.

You probably do not need account deletion on day one if:

• the mailbox may need to receive client replies
• the person owned files or repositories still in use
• finance or legal records must be retained
• you may need audit evidence later

You probably do need immediate revocation on day one if:

• the departure is involuntary
• there is concern about data theft or sabotage
• the person had privileged access (admin access)
• they had access to production systems or customer data

Trade-offs

Every offboarding choice has a benefit and a cost.

The biggest trade-off is convenience versus control. The fastest action is deleting the user. The safer action is staged offboarding.

In practice

Below are examples you can adapt. Use the dashboard path first where possible; use command line only if your team already manages systems that way.

Example 1: Disable a Linux account and expire access immediately

If a departing person had direct server access, remove their ability to log in. In your server control panel, use the user-management screen if one exists. If your team manages Linux servers directly, this command locks the account password and sets the account expiration date to today.

sudo usermod -L alice
sudo chage -E 0 alice

Gotcha: this does not remove SSH keys from ~alice/.ssh/authorized_keys, and it does not stop running processes owned by that user. If the server uses SSH keys, remove those too or disable SSH access in your access-management tool.

Example 2: Remove a departing user’s SSH key from a server

If the user had key-based server access, edit the authorized keys file and remove only that person’s line.

⚠️ Editing authorized_keys on a production server can lock out administrators if you remove the wrong key. Keep another admin session open while you test.

sudo cp /home/deploy/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys.bak
sudo nano /home/deploy/.ssh/authorized_keys

After saving, test a new SSH connection from an approved admin account before closing your current session. Gotcha: many teams share a deploy user; if so, one person’s key may be mixed with automation keys. Label keys with comments so you can identify them safely.

Example 3: Rotate a shared credential in an app config

If a departing person knew a shared SMTP password, database password, or API secret, rotate it in the provider dashboard first, then update the application config.

SMTP_HOST=smtp.example.com
SMTP_PORT=587
SMTP_USERNAME=notifications@example.com
SMTP_PASSWORD=replace-with-new-secret

This .env example shows the kind of application setting that must be updated after secret rotation. Gotcha: changing the secret in the provider but forgetting to update the app will break email, backups, or integrations until the new value is deployed.

Example 4: Transfer repository ownership in GitHub-style workflows

In your code host dashboard, move personal repositories into the organization and remove the user from teams. If your workflow is managed as code, a team membership file may look like this:

{
  "team": "client-project",
  "members": [
    "bob",
    "carol"
  ],
  "maintainers": [
    "engineering-manager"
  ]
}

This example represents the desired state after removing alice from a project team. Gotcha: removing a user from the team does not automatically rotate deploy keys, personal access tokens, or CI secrets they may have created.

Further reading

• NIST SP 800-53 — Access Control and Personnel Security families
• CIS Controls — Account Management
• OWASP Cheat Sheet Series — Credential Stuffing Prevention and Secrets Management
• The "Authentication" and "HTTP Cookies" sections of the MDN Web Docs
• Your identity provider’s admin guide section named "Suspend users", "Block sign-in", or "Revoke sessions"

This article was written by an AI system and published pending human review. Verify anything you intend to act on.