The Dormant Account Dilemma
Dormant accounts are a well-known risk. Keeping them enabled is an obvious expansion of your attack surface. For that reason, most compliance frameworks call them out specifically, mandating processes that shut them down in 30-90 days.
They’re a non-controversial topic. After reviewing countless access management policy documents, nobody in the industry disagrees. It sounds like a simple task. Identify identities that haven’t checked in recently and disable them. Done, right?
Unfortunately not. Even when identity security and compliance teams believe this is taken care of, the data shows it rarely is. Why is something that seems so simple such a widespread problem? Let’s dig in.
Business Disruption
Like many others in security, identity security teams have to walk a fine line. They’re directly responsible for managing the gateway to business-critical systems. While it’s easy to run a report and find a list of accounts that haven’t had an interactive sign-in in the last 30 days, disabling an account based on that data alone can lead to significant business disruptions.
The Scream Test
Many teams have personal stories about shutting down an account they thought was no longer in use, only to get a call from the business asking why something stopped working. It’s happened so many times that there’s a relatively well-known term for it: The Scream Test. Failing the Scream Test isn’t a good look. You can feel directly responsible for an outage, even if it was a data hygiene issue, failed process, incomplete investigation, or exception that got you there.
So, how do you confront this problem? In the following sections, we’ll discuss what we’ve seen work by covering unique account types, account ownership, detecting true dormancy, and dormant account due investigations.
Account Types
To start looking at how to address this problem, let’s start with the highest level. Dormant accounts can fall into one of a few categories.
Internal Employees: These named accounts are your employee’s primary ID. If employees come and go happily, onboarding & offboarding processes take over, and they’re usually not a big problem. HRIS systems can do the heavy lifting if they’re integrated. Otherwise, they’re managed with tickets or communication between HR and Identity Management stakeholders.
But what about the exceptions? An employee leaving the company without notice, being converted to a long-term consultative role (infrequent access), or even a missed ticket can cause them to appear in a dormant account report.
Third-Party Users: Most businesses rely heavily on outside help. So when outside help is involved, employees won’t think twice about sharing a document or giving third parties access to a system. Even though policies typically require a formal review before doing so, they’re given access without that review more often than not. Come cleanup time, that business practice can make these accounts extra tricky and often leads to them being the leaders in non-compliance.
Non-Human Identities: Service accounts, API keys, and a multitude of other authentication methods responsible for machine-to-machine interactions can be especially hard to govern. Stakeholders inside the company with Admin access have free reign to set these up. And with the digitization of business operations continuing to increase in velocity, these accounts are becoming increasingly numerous. In many cases, these accounts don’t perform interactive sign-ins, so they may show up on a dormant account list even if they’re working in the background.
Non-SSO’d Accounts: Without a single-pane-of-glass for identity management, it’s important to note that this problem extends into all systems outside of your SSO. A quick shoutout to all those SaaS companies that charge extra for SSO functionality.
Some companies take a strict stance: No SSO, no approval. If that’s not your company, the good news is that there are Identity automation companies working on building a connector-less future, making centralized management a reality, even when SaaS isn’t SSO joined. Either way, for the best coverage, consider dealing with the accounts in your privileged systems first: SSO, Network, and Cloud.
Account Ownership
For good hygiene that supports lifecycle management and security, a little bit of work at the time of account creation goes a long way. Ensuring there’s a forcing function to capture and keep track of an account stakeholder will ensure you always know who you can go to for questions. Current org charts are crucial if your stakeholders are outdated and you need to go one step up in the reporting chain for help.
If you don’t have a system of record for account stakeholders, you can try returning to the history tracked in your access request system. For some, that might be as simple as a Slack channel, and for many, this will be a ticketing system. Searching for the primary identifier should give you a good history, bringing you back to the initial request and who made it.
Account ownership seems to be one of the most common missing steps in the process. When teams don’t have a simple way of tying account creation to an initial request, it haunts them down the line.
What to watch out for? Recency in your data hygiene. Employees come and go, so being proactive about keeping account owners up to date at the time of transfer or departure will go a long way toward keeping this information up to date. That will entail making account ownership recertification a part of your transfer and offboarding process.
Detecting (True) Dormancy
So, what makes an account dormant? It usually starts with a simple report that looks for accounts with no interactive sign-ins in 30 days. But to identify true dormancy, you’ll want to go beyond just interactive sign-ins.
We’ve seen a number of cases where accounts appeared dormant but were still active in the business. A few examples:
Specialty workers don’t always use core productivity tools integrated into your SSO. Not everyone uses email regularly. This part of your workforce may use a specialized, decentralized system daily. So, if you’re just looking at the SSO, you’ll have a blind spot.
Long token lifespans can cause users to appear dormant. Tools like Slack or Gong have long token lifespans once they’ve been installed as a client on someone’s machine. The user won’t be required to authenticate every time they use that core service, so the only way to understand true dormancy here is to look for usage reporting in the SaaS app.
Non-interactive sign-ins will tell you a lot if a named credentialed account was used for integration between systems. Unfortunately, products like Entra-ID didn’t report on this until recently. To this day, they’re a part of the beta API, which is a different endpoint to hit, so if you’re consolidating data somewhere, these sign-ins won’t be easy to access.
Oauth grants can tell you if a user account was used to set up an integration between two apps. This type of activity doesn’t always show up in sign-in logs, so you’ll want to take a closer look at the user’s configurations and the scope of any grants to see if admin-level scopes were included that could impact more than just the user’s personal processes.
This context is important to give you a complete view of the missing activity indicators on an account that goes beyond interactive sign-ins in your SSO.
The Investigation Checklist
In an audit, you’ll likely be asked to show your process for identifying and shutting down dormant accounts. This checklist is intended to give you a starting point, as there’s always the chance that something specific to your organization needs to be considered.
Start with a report of all user records with no interactive sign-ins in the last 30 days. To that report, do the necessary work to add the following data:
Account ID
Account Type
Account Owner / Stakeholder / Hiring Manager
The last non-interactive Sign-in date
Admin-level Oauth Grants on the account
Last logins from other core systems
Take a pass at your access request system of record. This may give you some other important context:
The account owner/stakeholder if one wasn’t stored
The initial reason for the account creation
Missed offboarding requests if your offboarding is done manually
Estimate the cost of leaving the access open. In most cases, a license directly tied to a dormant account can be recovered and re-assigned or shut down prior to a renewal. This information will help express relevance to the business owner, especially if it hits their budget.
The report you have here will help you prioritize the most impactful account shutdowns. Start contacting stakeholders to notify them that the account looks to be no longer in use and get their historical context on the account. Ultimately, you want to know if they can confirm whether or not it’s needed anymore. It’s important to present this as a policy-based process so people know that leaving the account open without a justification is considered a violation.
If the stakeholder doesn’t know, you can ask around. Others in the department may have the details you’re looking for. And if you don’t get a response, make sure to follow-up. Requests like this can slip through the cracks if people don’t consider it urgent. To drive urgency, let them know that they have a few days before you’ll take action to disable the account. Once you’ve done all of this, you’ll have a lot of context to work with.
Most policies lay out a specific timeframe for account shutdown if you haven’t gotten a response. Ninety days dormant is a good standard. At that threshold, it’s time to shut the account down and run your Scream Test.
If this checklist isn’t complete, we’re always grateful for contributions from the community. If you see something that we’ve missed, please don’t hesitate to let us know.
An Agent for Dormant Accounts
Managing dormant accounts is a complex, multifaceted challenge. The amount of manual effort required to gather the right context, verify exceptions, and make informed decisions is staggering. But what if there was an Agent for that?
Agentic automations are perfect for bringing all of this context together, including messaging or interviewing account stakeholders and chasing down originating access request tickets.
A properly architected Agent can build up institutional knowledge over time through a feedback loop. If a negative consequence was experienced based on a blindspot, the next employee who is put in charge of this process might be missing that historical knowledge. Ideally, a process documentation update solves this, but we know how easy it is to stay on top of documentation.
Instead of manually compiling reports, logging into multiple systems, and chasing down stakeholders, agents can do the heavy lifting. This allows you to stay compliant with your policies without spending hours—sometimes days—on routine investigations.
Are you compliant with your policy?
Many of the teams we’ve worked with were shocked to discover how many dormant accounts they still had lying around in their systems. Implementing a policy to address this is easy, but it's very hard to stay on top of a continuous process when other priorities seem more pressing.
Continuous identity governance is required in the modern world, where everything moves fast. If you’re ever interested in a quick assessment to see how your controls compare to your Identity Governance-related policies, reach out. We love delving into these details.
