Orphaned and Dormant Accounts

Two different findings get confused under one heading, and treating them the same produces either wasted money or a security gap.

The two categories

Orphaned: the account belongs to someone who is no longer with the organisation, or to nobody identifiable. A security problem.

Dormant: the account belongs to a current employee who has stopped using it. A cost problem.

A third category: service and shared accounts with no individual owner, which are neither and need their own treatment.

Finding orphans

Compare each application's user list against the current directory. Anyone in the first and not the second is an orphan.

The join is on email address usually, which breaks when addresses change or when people signed up with variants.

Check name matches for the residue, by hand.

Non-federated applications are where orphans concentrate, because deprovisioning never reached them.

Run this quarterly, per application, starting with the ones holding sensitive data.

Acting on orphans

Close them, with the standard caution about service accounts that look like people.

Check what they own first. Documents, automations, integrations and scheduled jobs frequently belong to a departed person's account and break when it is closed.

Transfer ownership before closing, which is why this is a process rather than a bulk action.

Record each one as an offboarding failure, and look at which applications they cluster in. That distribution tells you exactly where the leaver process is not reaching.

Finding dormant accounts

Last activity per user per application, from the vendor's admin data or from your identity provider.

Ninety days is a common threshold and it should vary by application. A quarterly-use tool has different norms from a daily one.

Watch for the false positives described in the unused-licences note: API usage, mobile sessions, seasonal roles.

Acting on dormant accounts

Confirm with the owner and the user before removing.

Suspend, do not delete, for a period. Reversible actions produce far less resistance.

Reclaim the licence, which is the point.

Record the outcome so the same accounts are not re-examined next quarter.

Service and shared accounts

The category that causes the most trouble.

Service accounts used by integrations look permanently dormant and must not be touched. Identify and tag them explicitly in the register.

Shared accounts used by a team with a common password are a security problem in their own right: no attribution, no offboarding, and the credential spreads.

Migrate shared accounts to individual accounts wherever the application supports it. Where it does not, move the credential into a managed vault with access logging and rotate it when anyone with access leaves.

Every shared account should have a named owner and a documented reason for existing.

The metrics

Orphan count, by application, quarterly. Trending down means offboarding is improving.

Dormant seat count and its value, which funds the work.

Shared account count, which should trend to as close to zero as the estate allows.

Time from departure to orphan closure, which measures the process rather than the backlog.

Migrating away from shared accounts

Shared credentials are the hardest access problem to fix and the one with no attribution at all.

Inventory them first. Every account used by more than one person, with who has the credential.

Check whether the application supports individual accounts, which most now do and which the shared arrangement predates.

Migrate where possible, which is usually cheaper than the shared account's licence saving suggests once you count the risk.

Where it is not possible: vault the credential, log retrieval, rotate on any departure, and name an owner.

Rotate immediately when anyone with access leaves, which requires knowing who had access — hence the inventory.

Report the count. It should fall, and a shared account created after the migration is a process failure worth investigating.

Checking what an account owns before closing it

Closing an orphaned account without checking what depends on it causes a second incident.

Documents and folders, where ownership affects whether others can access or edit.

Scheduled jobs and automations running under the account, which fail silently.

Integrations authenticated as that user.

Repositories and pipelines.

Application administration, where they may be the only administrator.

Distribution lists and shared mailboxes they manage.

Reassign each before closing, which is why orphan cleanup is a process rather than a bulk action, and why it goes faster when ownership was recorded properly in the first place.