What do teams get wrong about non-human account sprawl in CI/CD and legacy systems?

The main mistake is assuming automation or legacy stability means accounts are already controlled. In practice, CI/CD pipelines, hardcoded credentials, orphaned accounts, and outdated applications can multiply access paths without clear oversight. Teams also miss that unused accounts can remain active long after the business need has disappeared.

Where non-human account sprawl actually comes from

Non-human account sprawl is rarely the result of one bad decision. It usually comes from the way modern delivery and old applications both create identity debris: CI/CD jobs mint tokens, scripts hardcode secrets, vendors add service principals, and legacy systems keep integration accounts alive because nobody wants to break a fragile dependency. The result is an access estate that grows faster than ownership, review, or offboarding can keep up.

Teams often focus on the visible account count and miss the real issue, which is the number of active access paths. A single pipeline or application can carry multiple credentials, fallback accounts, and inherited permissions, so the practical blast radius is larger than the directory listing suggests.

That is why sprawl is usually a lifecycle and governance problem before it becomes a technical one. The account exists, but the control story around it does not: no clear owner, no expiration date, no confident inventory, and no consistent decision about whether the access is still needed.

One useful way to frame the problem is to treat CI/CD identities and legacy integration accounts as part of the same control surface. NHIMG’s CI/CD Pipeline Identity Security Guide shows why ephemeral build trust, token scope, and publishing paths matter just as much as code quality. For legacy systems, the equivalent challenge is persistent access that outlives the original business purpose.

Automation creates the illusion of order because it is repeatable. In practice, repeatability can hide uncontrolled growth. Pipelines reuse the same tokens across projects, scripts copy credentials into new environments, and service accounts become the default answer whenever a team needs something to work quickly.

Legacy systems create the opposite illusion, stability. Because they are old and sensitive, teams are reluctant to touch them, so unused accounts, embedded passwords, and shared integration IDs survive for years. That makes the system look quiet while the access model steadily decays underneath it.

The common failure is assuming that “machine access” is inherently easier to manage than human access. It is often harder, because these accounts are less visible to help desks, less likely to be tied to a named owner, and more likely to sit outside standard joiner-mover-leaver processes. NHIMG’s Service Account Security Guide is useful here because it highlights the operational reality that service identities need inventory, ownership, and rotation just as much as employee accounts do.

Another blind spot is trust inheritance. A legacy batch job or build runner may authenticate successfully because it was granted broad permissions years ago, not because anyone still considers it appropriate. Once that happens, the account becomes a hidden dependency that blocks cleanup and expands exposure at the same time.

What teams miss about unused accounts, secrets, and hidden reach

Unused does not mean harmless. An account that is no longer needed can still authenticate, still be reused, and still be abused if it is exposed through source code, pipeline logs, image layers, configuration files, or forgotten automation. That is why sprawl and secret leakage often travel together.

Hardcoded credentials are especially dangerous because they turn dormant access into durable access. Even if the original application is outdated, the secret can remain valid long after the business owner has forgotten it exists. NHIMG’s Guide to the Secret Sprawl Challenge is a strong reminder that the real problem is not just the secret itself, but how many places it has been copied, cached, or inherited.

Teams also underestimate reuse across environments. One non-human account may be shared between test and production, linked to multiple repositories, or trusted by more than one application. When that happens, deleting it feels risky, so the account remains active and the cleanup debt grows.

For CI/CD specifically, the access path matters more than the label on the account. A pipeline token that can publish artifacts, access cloud APIs, or write to a package registry is not a minor utility credential. If it leaks, an attacker can often move from build access to code tampering, artifact poisoning, or broader environment compromise. NHIMG’s GitHub Action tj-actions Supply Chain Attack illustrates how one compromised automation path can expose far more than the original job was intended to touch.

Risk and Threat Considerations

Sprawl increases the chance that an attacker will find a quiet, high-trust identity that nobody is actively watching. The same conditions that make a non-human account convenient, persistence, broad reach, and weak ownership, also make it attractive for lateral movement, secret theft, and long-dwell compromise.

Failure mechanism: Credentials are left active in pipelines or legacy integrations after the business use case has ended, or they are reused across multiple systems with permissions broader than the original task required.

Impact: A single leaked or forgotten account can become a durable foothold, enabling unauthorized access to build systems, data stores, cloud resources, or production services, often without immediate detection.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Unused non-human accounts and stale credentials are central to the question.
	NHI-02 — Secret Leakage	CI/CD and legacy systems often sprawl through exposed hardcoded secrets.
	NHI-05 — Overprivileged NHI	Sprawl becomes risky when non-human accounts retain broader access than they need.
Recommendation — Revoke dormant non-human accounts promptly and verify offboarding removes every active access path. Scan for leaked secrets in pipelines, code, logs and configs, then rotate exposed credentials immediately. Reduce each non-human account to the minimum permissions required for its current task.
CIS Controls v8	CIS-5 — Account Management	The subject is fundamentally about unmanaged and excessive non-human accounts.
	CIS-6 — Access Control Management	Sprawl matters because excess access persists beyond legitimate need.
Recommendation — Centralize account inventory, ownership and periodic review for every non-human identity. Remove stale access paths and revalidate permissions against current business need.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	CI/CD and legacy sprawl often persists through unmanaged credentials and tokens.
	AC-6 — Least Privilege	The question centers on excessive access retained by non-human accounts.
	AU-2 — Event Logging	Sprawl becomes harder to see when account use is not logged consistently.
Recommendation — Enforce credential lifecycle rules for creation, storage, rotation and revocation. Limit every non-human account to the minimum permissions needed for the task. Log non-human account activity so inactive or unexpected use is detectable.
ISO/IEC 27001:2022	A.5.16 — Identity management	Identity governance is needed to keep non-human accounts from accumulating unchecked.
Recommendation — Maintain a current inventory and ownership model for non-human identities.
OWASP API Security Top 10	API2 — Broken Authentication	Automation and legacy integrations often depend on authentication paths that become unmanaged.
Recommendation — Harden machine authentication paths and remove weak or exposed credentials.

Practitioner Guidance

What to prioritise: Start with accounts that can reach production, publish artifacts, or access secrets. Those are the identities where sprawl becomes an incident path, not just an inventory issue.

What to verify: For each non-human account, confirm an owner, a purpose, an expiry or review date, and the exact systems it can reach. If any of those are missing, treat the account as a candidate for removal, scoping, or rotation.

Common mistake: Teams often inventory usernames but not effective access. The better question is whether the account can still do anything meaningful, and whether that capability is still justified.

Practitioner takeaway: The goal is not to count non-human accounts more accurately, but to reduce the number of credentials and access paths that can survive after their business purpose has disappeared.