Dormant Account Cleanup: How to Do It Without Breaking Things

Every security team has a version of this problem. Someone exports a list of accounts that haven't logged in for 90 days. There are 2,000 of them. Some are clearly no longer in use. But some are service accounts that run on a schedule and never show up in login logs. Some are shared accounts with no individual owner. Some are contractor accounts from a project that technically ended but might still be active. Disable the wrong one and you take down a production system.

So the list sits. For months. Sometimes years.

This post is about how to not let that happen, with a process designed around the actual operational complexity of enterprise identity environments.

What Makes an Account "Dormant"?

Vague definitions are one of many reasons that cleanup projects stall before they ever start. Here's a working taxonomy:

These are not interchangeable terms, and how you handle each one differs. An orphaned account is a higher-priority risk than a dormant one because there's no employee to vouch for it. A stale account needs investigation before any action.

On threshold: 90 days is a reasonable default for human accounts. Pick a number, document it, and apply it consistently. The specific threshold matters less than having one.

As for why this matters beyond hygiene: dormant accounts are a lateral movement vector. An attacker with compromised credentials on an account nobody monitors can move through your environment for months without triggering an alert. They also generate audit findings under SOC 2, ISO 27001, HIPAA, and FedRAMP, and inflate licensing costs on every SaaS platform that charges per seat.

Why Dormant Account Cleanup Projects Stall

Most teams know dormant accounts are a problem. They still struggle to clean them up anyways. Here's why:

Ownership is unknown. The account was provisioned three years ago. The original manager has changed roles. HR has no current record. Nobody knows who to ask, so nobody asks anyone.

Fear of breaking things. What is the ripple effect of removing the account with no login activity for 120 days? It might be running a cron job, a monitoring agent, or a batch process that fires quarterly. Inactivity in the login logs doesn't mean inactivity in the system.

No confirmation workflow at scale. Even when you're confident an account looks safe to disable, you need a stakeholder to sign off before acting. Manually emailing 300 managers doesn't scale, and most of those emails don't get answered anyway.

One-time cleanups don't fix the underlying problem. Run the cleanup in Q1, and by Q3 the list has grown back. Without a recurring process, you're doing archaeology on a backlog that keeps generating itself.

A Step-by-Step Process for Safe Dormant Account Cleanup

Step 1: Build your inventory

Pull all accounts from every identity source: Active Directory, Entra ID, Okta, cloud IAM providers, and any SaaS platforms that manage their own access. This is the step most teams skip or do partially, which is why the cleanup always misses accounts.

Cross-reference against your HR system. Any account where the associated person shows as terminated in HR is immediately elevated to high priority. These are orphaned accounts, not just dormant ones, and they should be treated differently.

Step 2: Classify before you act

Separate human accounts from non-human accounts. Service accounts, API tokens, shared mailboxes, and automation credentials all require a different process.

For human accounts: 90-day inactivity is a reasonable trigger for review.

For non-human accounts: Do not apply the same inactivity rule. A service account that runs a weekly batch job hasn't logged in because it doesn't need to. For these, the questions are: Is it still in use? Who created it? What does it have access to? Is that access still appropriate?

Step 3: Find the owner

For each flagged account, trace to a current owner:

• Human accounts: the direct manager in your HR system as of today, not as of when the account was created
• Service accounts: the team or individual who provisioned them, which you can often find in ITSM ticket history
• Unknown: escalate to the application or system owner

If you can't find an owner after a reasonable effort, that account goes on a separate watchlist. Accounts with no identifiable owner are among your highest-risk items.

Step 4: Send targeted confirmation requests

Don't send a mass email with a spreadsheet attached. For each flagged account, send a targeted message to the identified owner with specific context: account name, last login date, what systems it has access to, and the proposed action.

Give them a clear yes or no: does this account need to stay active? Include a deadline. If they don't respond within the window, escalate to their manager.

This step is where most manual cleanup processes break down. At 500 accounts, following up on non-responses becomes a job in itself.

Step 5: Act on confirmed accounts only

Disable, don't delete. An account disabled with no complaints after 30 days is a strong signal it's safe to remove. An account disabled that triggers a production alert tells you something you needed to know before you deleted it permanently.

Log everything: account name, who confirmed, when, what action was taken. This is your compliance evidence.

Step 6: Build a recurring process

A one-time cleanup is not a cleanup program. Set up automated alerts for accounts that cross the inactivity threshold so you're working a rolling list, not a 2,000-row spreadsheet once a year. Quarterly is a reasonable cadence for most enterprises. Monthly if you're in a heavily regulated environment.

How Automation Changes This at Enterprise Scale

The six steps above are sound. At 500 accounts they're manageable. At 10,000 employees across multiple identity systems, the confirmation workflow alone becomes a part-time job.

The coordination overhead is the actual bottleneck. Discovery is automatable. Cross-referencing HR is automatable. What bogs teams down is the human parts: finding the right owner, sending the right message with the right context, tracking who responded, chasing who didn't, logging what happened.

Luckily, agentic workflows handle that flow. Surf AI's Dormant Account Cleanup use case runs the entire process end-to-end: continuous discovery across identity systems, automatic cross-reference against HR to flag orphaned accounts, ownership tracing via a live context graph (not a stale CMDB), targeted stakeholder confirmation with full context, escalation on non-response, and account disabling with a complete audit trail, all with human approval before any action is taken.

The result is that a cleanup process which would take a team weeks of manual coordination runs continuously in the background, surfacing only the decisions that require human judgment.

What "Done" Looks Like

A dormant account cleanup program is complete when:

• All accounts 90 or more days inactive have been reviewed and dispositioned
• All orphaned accounts (HR-terminated employees) have been disabled or explicitly confirmed as needed
• Ownership is documented for all remaining active accounts
• A recurring process is in place so the backlog doesn't regenerate
• An audit trail exists for every action taken, reportable on demand

(That last point matters more than most teams realize until the auditor asks for it.)

Frequently Asked Questions

What is the difference between a dormant account and an orphaned account?

A dormant account belongs to someone who is still with the organization but hasn't logged in recently. An orphaned account belongs to someone who has left, with no current owner. Both are security risks, but orphaned accounts are typically higher priority because there's no active employee to confirm the account's purpose or flag unexpected activity on it.

How long should an account be inactive before being considered dormant?

90 days is the most common threshold for human accounts and aligns with several compliance framework guidance documents. The specific number matters less than applying it consistently and documenting it. For non-human accounts, inactivity alone isn't a reliable signal since service accounts and automation credentials may run on irregular schedules.

Is it safe to disable service accounts that haven't logged in?

Not based on inactivity alone. Service accounts require investigation: what process runs under this account, is that process still active, and who currently owns it. Disabling a service account without that context is how production incidents happen. Classify them separately, investigate before acting, and get explicit confirmation from a technical owner before making any changes.

What compliance frameworks require dormant account remediation?

SOC 2 (CC6.2, CC6.3), ISO 27001 (A.9.2), HIPAA (164.308(a)(3)), and FedRAMP all include access review requirements that cover inactive and orphaned accounts. The specifics vary, but the common thread is: you need documented evidence that you review and act on unused access, and that you can produce that evidence on demand.

Surf AI's Dormant Account Cleanup use case automates the full process, from discovery to stakeholder confirmation to account disabling, with human approval at every step and a complete audit log. See how it works.