Ghost Accounts: Find Access Former Employees Still Hold

What a ghost account actually is

A ghost account is access that outlived the relationship. The person is gone. The account is not.

The category is wider than most offboarding checklists assume. When someone joins, they accumulate access across the systems they touch. A directory account. App accounts inside and outside single sign-on. OAuth grants they issued to connect one tool to another. Service accounts they created to run a script or an integration. Shared logins they were handed. Tokens and API keys they generated. By the time they leave, the access is spread across more places than any single person remembers.

When they leave, IT closes the directory account. That step happens reliably because IT owns it and it is the obvious one. Everything else depends on whether each of those other systems was connected to the directory, whether anyone built a step to close it, and whether that step ran.

A ghost account is what is left when one of those conditions did not hold. It belongs to:

• A departed employee whose directory account was disabled, but whose Notion login, set up with a personal email, still works.
• A contractor whose engagement ended six months ago, whose OAuth grant connecting a reporting tool to your CRM is still live.
• A former admin who created a service account to run a nightly export, left, and the service account is still running with their permissions and a password only they knew.
• Someone who knew the shared password to a billing portal, left, and the password was never changed.

None of these are exotic. They are the ordinary residue of people doing their jobs across a growing stack of tools. Manual offboarding breaks at scale, not because people are careless, but because the number of systems an employee touches grew faster than any manual checklist could track. The checklist closes the doors someone thought to list. The ghost accounts sit behind the doors nobody listed.

Why the directory account is only the first door

The directory account, the one in Active Directory, Entra ID, Okta, or Google Workspace, is the front door. Disabling it is necessary and it does real work. It blocks the person from logging in to the directory itself, and it blocks every application that authenticates through that directory by single sign-on.

That last part is the catch. Single sign-on only covers the apps you connected to single sign-on. For everything else, the directory account is just one credential among several, and disabling it does nothing.

Here is what disabling the directory account does not touch.

An app that authenticates with its own password. A SaaS tool the team adopted on its own, set up with email-and-password and never connected to single sign-on, has no idea the directory account was disabled. The login still works. If the person set it up with a work email, you might find it later. If they used a personal email, the directory has no record it exists.

A token still living in a script. An API key or access token the person generated, pasted into a scheduled job or an automation, keeps working. Tokens do not check whether the human who created them still has a job. They authenticate the request and they expire on their own schedule, which is often never.

A personal-email account used for a work tool. This is the one that leaves no trace. Someone signed up for a tool with their personal Gmail because it was faster than filing a ticket. The work data went in. The directory never knew. When the person leaves, the account stays, attached to an email address you have no control over.

An OAuth grant the person issued. When someone clicks "Allow" to connect one app to another, that grant persists through a refresh token. Disabling the directory account does not revoke the grant in many cases. The connection keeps pulling data on the schedule it was set up with.

A shared login the person knew. Shared credentials do not belong to one account. Disabling the directory account does nothing to a password the person memorised. It stays valid until someone changes it.

So the directory account is the first door, and an important one. It is not the whole building. The rest of this guide is about the other doors.

How to find ghost accounts

Finding ghost accounts is a series of cross-references. Each one compares a list of accounts against a list of people who should have them. Where an account has no matching current person, you have a candidate.

Work through these in order. The first one is the highest yield and the easiest. The later ones find what the first one cannot.

1. Cross-reference the directory against HR

Pull the full list of accounts from your identity provider. Pull the list of current employees and active contractors from your HR system. Compare them.

Any account in the directory that does not match a current person in HR is a ghost account, or close to one. This finds directory accounts that were never disabled, accounts for people whose departure was never communicated to IT, and accounts for contractors whose end date passed without anyone acting on it.

This is the single most productive check, because the directory is the one place with a reasonably complete list and HR is the one place with a reasonably complete list of who is still here. The gap between them is your starting set.

It will not be perfect. HR records contractors inconsistently. Service accounts and shared accounts show up in the directory with no matching human, which is expected and handled separately below. But the cross-reference gives you a ranked list of human accounts to close, and that is the fastest cleanup you will do.

2. Review app accounts and last-login dates

Go application by application. For each app that holds something you care about, pull its own user list. This is the list the app keeps internally, which is not the same as the list of people who reach it through single sign-on.

For each user in each app, check two things. Does this person still work here. When did they last log in.

A user who left the company is a ghost account in that app. A user who has not logged in for ninety days is a candidate worth checking, because dormancy often means the person is gone or no longer needs the access. Last-login dates turn a long user list into a short list of things to investigate.

This is slower than the directory cross-reference because it is per-application and the data lives in each app's own admin panel. It is also where you find the accounts the directory cross-reference cannot see: the ones that authenticate with their own password, outside single sign-on.

3. Review OAuth grants and tokens tied to departed users

For the major platforms in your stack, pull the list of OAuth grants and issued tokens. Most identity providers and major SaaS platforms expose this in an admin view: which third-party apps are connected, and which user authorised each one.

For each grant, find the user who issued it. If that user has left, the grant is a ghost connection. It is still moving data between two systems on the authority of a person who is gone.

Do the same for API tokens and personal access tokens where the platform records who created them. A token created by a departed employee is access that survives the person, often with no expiry.

This check matters because OAuth grants and tokens are the access type most likely to be missed entirely. They are not accounts in the usual sense, so account-focused reviews skip them. The guide to OAuth grant governance covers this layer in depth.

4. Check service and shared accounts for departed owners

Service accounts and shared accounts have no person attached by design, which is exactly why they become ghost accounts when their owner leaves.

For each service account, find out who created it and who is responsible for it now. A service account whose only knowledgeable owner has left is orphaned. It is still running, still holding whatever permissions it was given, and nobody currently employed knows what would break if it were disabled. The orphaned accounts page covers this pattern and why it is one of the higher-risk findings in any cleanup.

For each shared account, list who knew the password. If anyone on that list has left, the credential is compromised in the literal sense: a person outside the company holds a working login.

These accounts do not appear in the HR cross-reference because they were never tied to a single person. You have to find them by going through the directory and the platforms directly and asking, for each non-human account, who stands behind it.

5. Check connected apps that authenticate outside single sign-on

Finally, look for the apps that the previous checks could not see, because they sit entirely outside your managed environment.

These are the tools adopted without IT, set up with personal emails or standalone passwords, never connected to single sign-on. There is no directory account to cross-reference and no admin view you control.

You find these through discovery, not cross-reference. Expense reports show recurring charges for tools nobody catalogued. Browser and network signals show traffic to SaaS domains. And the most reliable method for the personal-email case is a short survey of the team: ask each manager and each remaining team member what tools the departed person used, what they signed up for, and what they had access to that the rest of the team did not.

This is the layer that the honest scope note below is about.

How to close ghost accounts properly

Finding the account is half the work. Closing it properly means the access is actually gone and you can show that it is. Each type closes a little differently.

Disable, then remove. For a human account in an app or the directory, disable it first. Disabling is reversible and immediate. It blocks access while you confirm nothing breaks and nothing important is tied to the account. After a holding period, remove it. Removal cleans up the record so the account does not reappear in next quarter's review as something to investigate again.

Revoke tokens and OAuth grants. Disabling an account does not always revoke the grants and tokens it issued. Revoke them explicitly, at the application level, in the admin view where they are listed. A revoked OAuth grant stops the connection. A revoked token stops the script that was using it, so check what depends on it before you pull it, then revoke.

Reassign or retire service accounts. A service account that is still needed gets a new, current owner who knows what it does and can speak for it. Reset its credential so the departed creator no longer holds a working login. A service account that is no longer needed gets disabled, then retired, the same way as a human account, with a holding period to confirm nothing breaks.

Rotate any shared credential the person knew. If a departed person knew a shared password, change it. There is no partial version of this. The credential is only secured again once the password is different from the one the person remembers. Update the people who still need it through your password manager, not by emailing the new one around.

Record what you did. For each ghost account you close, write down what it was, when you closed it, and how. This is what turns a cleanup into evidence. When an auditor asks how you handle leaver access, or when the same questions come up next quarter, the record is the answer. It also tells you what you already checked, so the next pass starts where this one ended.

The honest scope note

A directory-and-HR cross-reference finds a lot. It is the highest-yield check in this guide. But it has a hard limit, and being clear about it matters more than overstating what the method can do.

The cross-reference works by matching accounts against people. It can only find accounts that show up in a list you can pull. A directory account, an app account with a work email, an OAuth grant recorded against a user: these leave a trace you can compare against HR.

An app a former employee used with a personal email and no single sign-on connection leaves no such trace. It is not in your directory. It is not tied to a work identity. The platform has no idea the person is connected to your company at all. No cross-reference will surface it, because there is nothing on your side of the comparison to match.

This is why the app-by-app review and the survey are not optional extras. They are the only way to reach the access that the automated checks structurally cannot see. The cross-reference gives you the bulk of the findings quickly. The manual review and the conversations with the team give you the ones that would otherwise stay invisible until they caused a problem.

A cleanup that relies only on the cross-reference is a good cleanup with a known blind spot. A cleanup that adds the app review and the survey closes the blind spot. Knowing which one you ran is part of the work.

Preventing the next batch

Finding ghost accounts is cleanup. It addresses the access that already exists. It does nothing to stop the next person who leaves from leaving their own residue behind.

The durable fix is an offboarding process that reaches every system, not just the directory. One that closes app accounts outside single sign-on, revokes grants and tokens, reassigns service accounts, and rotates shared credentials as a matter of routine, on the day the person leaves, rather than as a cleanup discovered months later.

‍