After you disable a departing employee’s account, their access can still survive in several specific places: OAuth tokens they granted to third-party apps, app passwords and service accounts they created, mailbox delegation and forwarding rules, and data they shared externally. Disabling the account closes the front door. These are the side doors, and this guide covers how to check each one.

Where former-employee access survives

OAuth tokens. Apps the person connected can keep working after the account is suspended, until the tokens are explicitly revoked.
App passwords & legacy auth. Older IMAP/SMTP app passwords can bypass MFA and survive a password reset.
Mail forwarding & delegation. Auto-forwarding rules or mailbox delegation can quietly route data out long after departure.
Shared drives & group membership. Ownership of shared content or membership in privileged groups may never get reassigned.
Service & admin accounts. The riskiest case: a departed admin whose credentials were reused for automation.

A quick offboarding-access checklist

Revoke the account’s OAuth tokens and connected apps. Suspension alone leaves them working.
Remove app passwords and disable legacy authentication.
Check for forwarding rules, delegates, and inbox rules before deleting the mailbox.
Reassign ownership of shared drives and files.
Confirm the account is out of all admin roles and privileged groups.
Verify no service account or integration depends on the person’s credentials.

The hard part is finding it

Running this checklist reliably across every departure is the hard part, especially when you’re reconstructing what someone connected years ago. An access audit approaches it from the other side. You get a list of every account, token, and grant that still exists, with former-employee access flagged, and you revoke from that.

Esmeris does this with read-only access and turns it into a graded report. Former-employee access is one of the first things it surfaces.

Start your free audit