Service Account Sprawl: How to Find and Fix Orphaned Identities in 90 Days

Service account sprawl is not a technical problem. It is a governance failure that compounds over time until it becomes a security emergency. Every enterprise with more than a few years of operational history has it: hundreds or thousands of service accounts accumulated across Active Directory, cloud IAM platforms, and application-specific identity stores, created informally over years of IT operations, never inventoried, never reviewed, never decommissioned. Many have passwords set at creation and never changed. Many have permissions granted for convenience and never trimmed. Most have no documented owner. All of them represent credential-based attack surface that requires no vulnerability to exploit.

How Sprawl Accumulates: The Lifecycle Failure

Service accounts are created when applications and services need to authenticate — to run Windows services, connect to databases, execute scheduled tasks, integrate with other systems. The creation is always driven by an immediate need: a project deadline, a new application deployment, an integration requirement. The governance record that should be created alongside — an owner, a scope justification, a rotation schedule, a decommissioning plan — almost never is, because those governance steps add friction to an already-pressured deployment process.

Once created, service accounts enter a state of benign neglect. They work, so nobody touches them. The application they support is too critical or too complex to risk modifying, so the password never rotates. The developer who created the account moves to a different team or leaves the company; institutional memory of the account's purpose leaves with them. The project that needed the account completes; the project decommissioning checklist (if it exists) does not include credential revocation. And the account persists — active, valid, unmonitored — in Active Directory for years.

The accumulation dynamics are asymmetric: service accounts are created at a rate driven by business activity (project starts, application deployments, integration requirements), while decommissioning is driven by a governance process that typically does not exist. Over time in a growing organisation, the population grows monotonically. Discovery exercises at organisations that have not run systematic service account audits in more than 12 months consistently find accounts dating back five, seven, or ten years — accounts that predate most of the current IT staff's tenure at the company.

Cloud adoption accelerates the problem. Cloud IAM platforms — AWS IAM, Azure AD service principals, GCP service accounts — make it trivially easy to create new identities for workloads, functions, and integrations. The same governance gap that affects on-premises Active Directory service accounts affects cloud workload identities, but the creation velocity is higher because cloud-native development practices encourage fine-grained workload identity creation. A single cloud-native application may create dozens of IAM roles and service accounts across its development, staging, and production environments — most of which survive environment teardowns as orphaned identities.

Why Sprawl Is a Security Problem, Not Just Housekeeping

Service account sprawl is not a compliance documentation problem that can be managed with better record-keeping. It is an attack surface problem. Every orphaned service account — one with no active consuming application, no current owner, and no recent use — is a persistent, valid credential that an attacker can use to access the systems it was provisioned for. If that credential has never been rotated, the password may be findable in configuration files, backup archives, or infrastructure-as-code repositories that have not been secured against credential exposure.

The specific attack pattern is well documented: an attacker obtains an orphaned service account credential (from a code repository, a configuration file, a backup, or simply by guessing a weak default password that was set years ago and never changed). They authenticate with the credential — successfully, because the account is still active. They access the systems the account was provisioned for — a database, a file share, an administrative API. They use that initial access to enumerate the environment, find additional credentials in reachable configuration stores, and expand their footprint. The entire lateral movement chain runs under service account credentials that the organisation did not know it had, making detection through user behaviour analytics nearly impossible because there is no human behavioural baseline to deviate from.

NIS2 and DORA both require organisations to be able to account for all identities with access to in-scope systems. A service account inventory that misses 40% of active accounts — which is conservative for organisations that have not run systematic discovery — is a demonstrable control failure in a regulatory examination. Examiners who ask for an Active Directory service account report and find accounts with no owner, five-year-old passwords, and no access review records will not view this as a minor finding.

Days 1–30: Discovery and Inventory

The first 30 days of the programme are entirely about establishing ground truth. You cannot triage, prioritise, or remediate what you have not found. The discovery phase must cover all identity stores where service accounts can exist — not just the ones that are well-governed.

For Active Directory environments, run a comprehensive export of all accounts flagged as service accounts by convention (accounts in service account OUs, accounts with naming conventions that identify them as service accounts) and all accounts that authenticate non-interactively (accounts running services, scheduled tasks, COM+ applications, and IIS application pools). PowerShell queries against AD can produce this inventory; tools like Microsoft's Active Directory PowerShell module, or commercial NHI discovery tools from vendors including CyberArk and Delinea, automate the collection and enrich the output with last-login timestamps, password age, and group membership.

For cloud environments, export IAM role and service account inventories from each cloud platform. AWS IAM Access Analyzer can enumerate all IAM entities with their associated policies; the output will include many IAM roles created for workloads that have been decommissioned. Azure's service principal export via the Microsoft Graph API provides the equivalent for Azure AD. GCP's IAM recommender surfaces service accounts with unused permissions, which is a useful starting point for the over-privilege analysis in phase two.

For application-specific identity stores — database accounts used by applications, accounts in LDAP-based application directories, credentials embedded in middleware platforms — the discovery method depends on the platform. Build a list of all applications in your portfolio and query each application's identity store for service-type accounts. This is the most labour-intensive discovery step and the one most likely to surface the biggest surprises, because application-specific identity stores are often entirely outside the scope of any existing governance programme.

The output of the discovery phase is a unified inventory with, for each account: the account name, the system it lives in, the systems it has access to, the date it was created, the date its password was last changed, the date it last authenticated (where available), and the nominal owner if one can be determined from Active Directory attributes or application documentation. This inventory is the working document for phase two.

Days 31–60: Triage and Prioritisation

The inventory produced in phase one is not a remediation list — it is a triage input. Attempting to remediate every service account simultaneously will produce operational disruption and stakeholder resistance that kills the programme. Effective triage identifies the accounts that need immediate action versus those that can be addressed in a structured queue.

Prioritise by blast radius: the combination of the permissions the account holds and the systems it has access to. Service accounts with Domain Admin membership, local administrator rights on multiple systems, or access to production databases and application servers are the highest priority regardless of their activity status. A service account with Domain Admin rights that has not been used in two years is not safe — it is a ticking clock. Revoke or strictly control these accounts first.

The second triage criterion is password age. Accounts with passwords more than 365 days old that have not been reviewed are high priority for rotation or revocation. Accounts with passwords more than 730 days old that have not been reviewed should be treated as critical — a credential that has persisted unchanged for two years in a modern threat environment has had ample opportunity to be compromised through any number of routes (data breaches at third-party services, configuration file exposure, network sniffing).

The third criterion is activity status. An account that has not authenticated in 90 days is a candidate for revocation; an account that has not authenticated in 180 days is a strong candidate; an account that has not authenticated in 365 days should be revoked unless a specific justification for retention is provided by an identified owner. The "revoke and observe" approach — revoking the account and monitoring for one to two weeks for any application failure or user complaint — is operationally efficient: active accounts generate immediate complaints that allow re-provisioning with proper governance; truly orphaned accounts generate silence.

Through this triage process, the inventory splits into three buckets: immediate remediation (high-privilege accounts regardless of activity status, and all inactive high-priority accounts), structured queue (active accounts with governance deficiencies that need rotation and ownership assignment), and monitor (recently active accounts with acceptable privilege scope that need owner assignment and periodic review but no immediate credential action).

Days 61–90: Remediation and Governance Foundation

The final 30 days execute the remediation backlog and establish the governance processes that prevent the sprawl from re-accumulating. These two activities must proceed in parallel — remediation without governance is a one-time clean-up that will need repeating in two years; governance without remediation leaves the current exposure in place.

For the immediate remediation bucket: revoke or disable all accounts in this category. For accounts that are in active use (confirmed by application dependency review), migrate them to a PAM-managed credential — Delinea Secret Server, CyberArk Privilege Cloud, or BeyondTrust Password Safe — before revoking the old credential. PAM management provides rotation, session recording, and audit logging that transforms an unmanaged service account into a governed one. For accounts with no confirmed active use, disable first (rather than delete) to allow a two-week observation window, then delete if no issues arise.

For the structured queue: rotate all passwords using your PAM platform's automated rotation capability, assign a documented owner to each account (using the triage data to identify the most likely owning team), and set a review date 90 days out. Accounts that go through this process are no longer sprawl; they are managed credentials with governance records.

The governance foundation has three components that must be operational before the 90-day programme concludes. First, a provisioning process that requires service account requests to include an owner, a justification, an access scope, and a review date — and routes new account creation through an approval workflow rather than allowing direct AD object creation. Second, an offboarding trigger that automatically generates a service account review task when the employee who owns an account leaves the organisation. Third, a continuous discovery scan — automated, recurring, alerting on new accounts that do not match the provisioning workflow — so that shadow service account creation is detected within days rather than discovered in the next annual audit.

At 90 days, the programme should have produced: a current, complete service account inventory, a governance record for every account that remains active, a significant reduction in the unmanaged account population, and a process that prevents the previous accumulation pattern from restarting. The inventory and governance records are also your evidence package for the next NIS2 or DORA examination — demonstrating that you know what service accounts exist, who owns them, and how they are controlled is one of the most credible identity security maturity signals you can present to a regulator.