Stale Service Account Credentials Left Active After System Decommission

Stale service account credentials left active after system decommission are a lifecycle design problem. Human accounts have records and events that force access to end. Service accounts often have neither. Closing that gap requires ownership, retirement triggers, and runtime enforcement.

Why service accounts outlive the systems they were built for

The intuitive diagnosis is negligence. Someone retired an application and forgot to delete its account. Human accounts are anchored to an HRIS record, where a termination date triggers offboarding, SSO deprovisioning, and the end of access. Service accounts, which let software authenticate to other systems, have no equivalent anchor by default.

That distinction makes survival the predictable outcome. A service account has no HRIS entry, no termination date, and no joiner-mover-leaver process that necessarily reaches it. Semperis describes how accounts without formal lifecycle management are frequently left behind when their applications are decommissioned. The application’s retirement and the account’s retirement are separate events, with nothing requiring the second to follow the first.

As a result, credentials issued for a 2023 migration can still be authenticating in 2026, long after the integration they served was replaced. Nobody has to decide to preserve them. Their continued existence requires only the absence of a decision to remove them, which is precisely what the missing lifecycle trigger permits.

How ownership evaporates silently when a system retires

A developer creates an API key, embeds it in a script, and later leaves the organization. HR records the departure, and SSO access is deprovisioned. The embedded key keeps authenticating because the offboarding checklist does not scan code for credentials.

The account may have had an owner in practice without ever having one on record. Once the developer leaves, knowledge of its purpose and dependencies can leave too. Static passwords hard-coded into scripts or applications deepen this problem because they are difficult to rotate and become effectively unowned when their creator departs. There is no clear handover when the account loses its owner.

Semperis notes that Active Directory environments often hold years or decades of services that have been added, upgraded, and retired. Each service can introduce accounts whose permissions outlast it, producing hundreds or even thousands of stale, unmanaged identities. HYCU identifies the same pattern in hardcoded credentials that remain unchanged or unmonitored for years. Its description, “out of sight, out of mind,” captures the administrative condition.

What decommission-stage failures actually enable for attackers

HYCU identifies broad, persistent access that is harder to monitor than human access as a reason attackers favor service accounts for quiet lateral movement and durable footholds. Microsoft Defender for Identity warns that malicious activity under accounts without a specific user or interactive monitoring may go unnoticed, delaying detection and response. The credential is not merely forgotten paperwork. It remains a working access path.

In PingCAP’s September–October 2026 incident, an unauthorized party used stolen service account credentials to get into internal systems, copy data, and get source code. PingCAP became aware on October 7 and began disabling the affected credentials that day. In a separate 2025 manufacturing breach, Akira ransomware entered through a ghost third-party vendor account that had never been deactivated.

The ICO’s head of investigations described how a single weak password on an account no longer needed enabled a serious attack affecting thousands in Welsh local government in 2024, disclosed in 2026. Colonial Pipeline’s 2021 breach began through an old, inactive VPN account without MFA. Neither example needs to be relabeled a service-account incident to demonstrate what dormant credentials permit.

At Maximus, decommissioning an application and deleting its service account caused another application to stop because it shared the same identity. Operational experience exposed that dependency, while penetration testing also helped drive standardized management. An account could therefore be obsolete for one application and still essential to another.

Why decommission workflows are structurally blind to service accounts

A standard decommission ticket treats the system as the object being retired. Its authentication paths are not necessarily part of that object. Removing dashboard access, for example, does not remove direct server or application access. SSH authorized keys, Linux users, RDP permissions, and VPN membership each have their own removal requirements. API keys and database users are separate again, as are CI/CD, backup, monitoring, and emergency break-glass credentials.

Semperis notes that application and developer teams sometimes grant more service-account permissions than needed because they do not know Active Directory permission models well. Defender for Identity calls for finding service accounts in privileged groups, including those with direct and nested membership. A system-level retirement process can therefore miss both an account and the privileges attached to it.

What happened at Maximus helps explain why teams hesitate to delete accounts that look suspicious when a retirement process misses them. Semperis notes that locking a service account or changing its password can stop the associated application and halt business operations. Without a dependency map, leaving it alone can look safer than intervening. Shared identities make the choice harder because no single system owner has all the information or authority needed to retire them safely. This is rational risk-aversion within a process that is structurally blind.

The lifecycle infrastructure that human accounts have and service accounts lack

Human-account cleanup has an administrative backbone. An authoritative HRIS record supplies a termination event, and a joiner-mover-leaver workflow propagates that event downstream. Each account belongs to a named person, so a manager can check whether that person still needs access during periodic access reviews.

Service accounts have no such structure by default. Application retirement is not connected to account retirement, and informal ownership can disappear when a creator leaves. Access reviews may exclude these accounts or treat them as a lower-priority category. Static credentials also do not age out unless policy forces rotation. The missing elements reinforce one another because neither a person’s departure nor a system’s retirement necessarily prompts a review.

Defender for Identity illustrates this separate treatment in its stale-account guidance. It recommends disabling and deleting stale user accounts after an extended monitoring period but excludes service accounts from that recommendation. The distinction reflects an operational problem. SOC 2, ISO 27001, SOX IT general controls, PCI DSS 4.0 §8.1.4, NIST CSF 2.0 PR.AC, and CIS Controls v8 §5 and §6 demand timely revocation. They require the outcome without prescribing the non-human identity infrastructure that makes it automatic. A requirement to close the account is not itself a mechanism for knowing when to close it.

Why the standard toolkit — PAM and periodic rotation — does not close the gap

Privileged access management platforms address a real part of the problem. CyberArk, Delinea, and BeyondTrust provide credential vaulting and rotation, reducing exposure through better credential handling. But rotation is not retirement. A vaulted, regularly changed credential remains authorized even when the system for which it was created is gone. Credential hygiene and lifecycle governance answer different questions.

A rotation schedule asks when a secret last changed. Because it runs on a calendar rather than a retirement event, it can keep maintaining an unowned account indefinitely. Missing dependency information also makes intervention hazardous. The shared identity at Maximus shows how deleting an account without knowing what uses it can break other applications, and changing passwords carries a similar risk. Reluctance to rotate is therefore not necessarily resistance to good tooling.

Semperis recommends Group Managed Service Accounts, or gMSAs, for automatic password rotation. That addresses the burden of changing passwords and reduces reliance on static credentials. It does not discover the account’s owner, establish its dependencies, or decide when its purpose has ended. An orphaned gMSA is still orphaned.

What closing the structural gap actually requires

Cleanup automation needs the missing lifecycle infrastructure in place before it can make sound retirement decisions. Semperis recommends discovering service accounts, identifying each account’s owner, purpose, and associated systems, and classifying it by privilege level, organizational unit, and authentication method. That inventory is the prerequisite for removing orphaned or unused accounts. Each account needs an owner on record, a clear business function, limits on its privileges, and a clear chain of what depends on it. Accounts without those details should be treated as possible exposure, even if they are seen as normal application dependencies.

Retirement then needs an identifiable upstream trigger. Application retirement in a CMDB, integration removal, repository archival, or a defined period of inactivity can supply the event that service accounts otherwise lack. The resulting workflow must resolve each separate access object, including the server, application, delivery, database, backup, monitoring, and emergency credentials associated with the retired system. Decommissioning has to reach the identities through which access actually occurs.

That linkage still depends on human judgment. Discovery, rotation, expiry enforcement, and decommissioning can be automated, but deciding what an identity is authorized to do requires a decision about business intent. Automation cannot supply an absent owner’s judgment. Defender for Identity’s recommendation to migrate legacy accounts to gMSAs is useful within that ownership and dependency context. Semperis also recommends least privilege, keeping Domain Admin or Enterprise Admin rights only where they are truly needed and limiting interactive logon where it is not needed.

Runtime monitoring supplies the final enforcement layer. An inventory can establish that an account exists and has an owner without revealing that it is authenticating after its owning system retires. Such anomalous authentication must trigger an alert before the quarterly audit. Governance defines the permitted purpose and lifetime. Runtime detection catches the activity that violates those rules.

How AI agents are multiplying the stale-credential surface before most programs are ready

AI agents add more identities to the non-human accounts that are already growing in number as infrastructure grows. Each agent can become stale. Unlike a service account provisioned once for a deployed service, agent identities can be created per workflow, task type, or session, making the provisioning rate orders of magnitude higher. These identities inherit human-scale access and use it at machine speed.

The embedded-credential surface is growing at the same time. In 2025, millions of hardcoded secrets were pushed to public GitHub repositories, a large year-on-year increase. If no automated link ties what is in a repository to account lifecycle events, credentials can still work after the systems they were made for retire. The non-human identity management market is mobilizing in response to this volume, but recognition of the gap is not the same as operational readiness.

Without ownership records, retirement triggers, and runtime enforcement, an enterprise cannot reliably check that an agent still has a purpose that calls for its access. When it cannot see running agents, monitor approved AI traffic, detect anomalies, and enforce rules, it repeats the same design mistake that leaves service accounts stale. Only the rate and scale have changed.