Close a Departed Employee's Account Without Losing Access

TL;DR — When someone leaves, do not just delete their user right away. First block sign-in, reset or transfer anything shared (email, files, MFA devices, API keys), then remove licenses and disable or delete the account after you confirm no business process still depends on it. Reading time: ~5 min

Goal

When you finish, the former worker will no longer be able to sign in to your systems, their access tokens and sessions will be invalid, any business-owned data you need will be reassigned or exported, and your admin list will show the account as disabled or deleted according to your policy.

Prerequisites

• An admin account for your identity provider (the service that manages logins), email system, and any critical apps the person used
• Permission to disable users, reset passwords, revoke sessions, and manage licenses
• The departing person’s work email address or username
• A list of systems they used: email, file storage, chat, CRM, code hosting, VPN, password manager, payroll/HR, and any cloud dashboards
• Your company’s retention rule for former-user data, if you have one
• A replacement owner for shared mailboxes, files, calendars, dashboards, and API keys
• Optional: access to your audit log (activity history) if you need to confirm what was changed

Steps

⚠️ Disabling or deleting an account can stop email forwarding, scheduled jobs, integrations, and access to shared files. Do not delete the account until you have transferred anything the business still needs.

Step 1: Block sign-in immediately

In your identity provider's admin dashboard, open the user record and use the disable or block action. Typical path: Admin dashboard → Users → search for the person’s email → open the user → Disable user or Block sign-in.

Use these literal actions if your provider shows separate controls:

• Set sign-in status to: Disabled
• Set password reset required to: Yes
• Click: Revoke sessions / Sign out everywhere / Invalidate refresh tokens

What you should see when this succeeds: the user status changes to Disabled, Blocked, or Suspended, and active sessions show as revoked or signed out.

Step 2: Reset the password and revoke MFA

In the same user record, reset the password and remove MFA (multi-factor authentication, an extra sign-in check) methods tied to the person’s device.

Typical path: Admin dashboard → Users → [user] → Authentication / Security.

Set the following literal values where available:

• New temporary password: generate a random value in the dashboard
• Require password change at next sign-in: On
• Remove MFA methods: Authenticator app, SMS number, security key, passkey
• Revoke remembered devices: On

What you should see when this succeeds: old MFA methods are no longer listed, and the account shows no trusted devices or active authentication sessions.

Step 3: Transfer or export business data

Before deleting anything, move ownership of email, files, calendars, documents, and app records.

Use your provider’s admin dashboard and follow these common paths:

• Email: Admin dashboard → Users → [user] → Mail → Forwarding or Convert to shared mailbox
• File storage: Admin dashboard → Users → [user] → Files → Transfer ownership
• Calendar: Admin dashboard → Users → [user] → Calendar → Share or export
• Chat: Admin dashboard → Users → [user] → Data export
• CRM / project tools: Settings → Users → Reassign records from [user] to [replacement owner]

Use these literal values:

• Forward email to: replacement-owner@your-company.com
• Transfer file ownership to: replacement-owner@your-company.com
• Reassign open records to: replacement-owner@your-company.com
• Auto-reply text: "This mailbox is no longer monitored. Please contact replacement-owner@your-company.com."

What you should see when this succeeds: the replacement owner appears on transferred items, forwarding is listed as active, and open records no longer show the departed user as owner.

Step 4: Remove app access and API credentials

Open every critical app and remove the user, then rotate any shared secrets they knew.

Typical path in each app: Settings or Admin → Users / Members → [user] → Remove access.

Also check these specific items:

• VPN account: disable user
• Password manager vault access: remove user from shared vaults
• Code hosting: remove from organization, teams, and deploy keys they created
• Cloud dashboards: remove IAM (identity and access management) roles and access keys
• CI/CD (build and deploy automation): rotate tokens, deploy keys, and service account secrets

If you have shell access for a Linux server account tied to the person, lock it with:

sudo passwd -l username
sudo usermod -L username
sudo pkill -KILL -u username

What you should see when this succeeds: the user no longer appears in member lists, and any access keys or tokens they owned show as revoked, deleted, or rotated.

Step 5: Remove licenses and paid seats

Once access is blocked and data is transferred, remove the user’s paid license so you stop paying for an unused seat.

Typical path: Admin dashboard → Billing or Licenses → Assigned users → [user] → Remove license.

Use these literal actions:

• Unassign product license from the departed user
• If prompted for data retention, choose: Keep data for your standard retention period

What you should see when this succeeds: the product seat count decreases by one, or the user shows as unlicensed.

Step 6: Disable first, delete later if your policy allows it

If your company keeps former-user records for a period, leave the account disabled. If your policy says to delete after transfer/export, delete it now.

Typical path: Admin dashboard → Users → [user] → Delete user.

Before clicking delete, confirm these literal checks:

• Email forwarding or mailbox conversion is already set
• File ownership transfer is complete
• Open records are reassigned
• API keys and tokens are revoked
• License is removed

What you should see when this succeeds: the account disappears from active users, or moves to Deleted users / Suspended users depending on your provider.

Verify it works

Run these checks end to end:

1. In your identity provider, search for the user and confirm the status is Disabled, Blocked, Suspended, or Deleted.
2. In your audit log, confirm entries for session revocation, MFA removal, and license removal.
3. Try a password reset from the sign-in page using the former user’s email. Expected result: either no reset is sent, or the account is shown as blocked according to your provider’s policy.
4. Send a test email to the old address. Expected result: it forwards to the replacement owner, lands in the shared mailbox, or bounces in the way you intended.
5. Open one transferred file, calendar, or CRM record and confirm the new owner is the replacement person.
6. In each critical app, confirm the user no longer appears under Users, Members, Team, or Access.

If you have shell access and disabled a Linux account, verify with:

sudo passwd -S username
id username

Expected result: the password status shows locked, and the account exists only if you chose to disable rather than delete it.

Common pitfalls

Deleted the account before transferring data

Mistake: deleting the user first. Symptom: mailbox contents, cloud files, or app-owned records are missing or hard to recover. Fix: restore the user if your provider allows it, transfer ownership, then disable first and delete later.

Revoked the main login but forgot app-specific access

Mistake: blocking sign-in only in the identity provider. Symptom: the person still has access through local app accounts, VPN credentials, SSH keys, or API tokens. Fix: open each critical app and remove the user there too; rotate tokens, keys, and shared secrets.

Left MFA methods or trusted devices attached

Mistake: resetting the password without removing MFA methods. Symptom: the account still shows registered phone numbers, authenticator apps, passkeys, or remembered devices. Fix: in the user’s Authentication or Security page, remove every MFA method and revoke remembered devices.

Removed the license too early

Mistake: unassigning the paid seat before export or transfer. Symptom: mailbox conversion, file transfer, or admin tools become unavailable. Fix: temporarily reassign the license, complete transfer/export, then remove the license again.

Forgot about shared secrets and automation

Mistake: disabling the person but leaving API keys, deploy keys, SMTP credentials, or scheduled jobs unchanged. Symptom: old integrations keep working, or jobs fail later because nobody knows what they used. Fix: rotate all secrets the person created or knew, then update the integrations with the new values.

Kept the account active for forwarding

Mistake: leaving the user enabled just so mail keeps arriving. Symptom: the former worker could still sign in if they know the password or recover access another way. Fix: use forwarding or convert the mailbox to a shared mailbox if your provider supports it, then disable sign-in.

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