Credentialitis shows why secrets sprawl is still an NHI governance failure

At a glance

What this is: This is a vendor essay that reframes secrets sprawl as “Credentialitis,” arguing that the persistence of passwords, API keys, tokens, and hardcoded blobs reflects a deeper NHI governance failure.

Why it matters: It matters because IAM and security teams cannot treat workload credentials as a cleanup exercise; they need governance that changes how non-human access is issued, owned, and reduced over time.

Context

Credential sprawl is the accumulation of passwords, API keys, tokens, certificates, config values, and hardcoded secrets across systems that were never designed to govern them as a lifecycle. The problem is not just exposure volume. It is that many organisations keep applying rotation and scanning to a model that still assumes credentials are the right long-term answer for workloads.

In NHI governance terms, that makes secrets sprawl a structural access issue, not a housekeeping issue. When identities for applications, pipelines, and services keep inheriting brittle credentials, the organisation ends up managing leakage symptoms instead of controlling how machine access is created, scoped, and retired.

Key questions

Q: How should security teams reduce secrets sprawl without disrupting delivery?

A: Start by classifying secrets by business criticality, lifetime, and exposure path. Replace the highest-risk shared credentials with workload identity or short-lived access first, then connect revocation to ownership and offboarding. The goal is not zero secrets overnight, but fewer reusable secrets and fewer places where they can be copied or forgotten.

Q: Why do vaults and scanners fail to eliminate credential sprawl?

A: Because they act after the secret already exists. Vaults centralise custody and scanners find exposure, but neither changes the dependency on embedding credentials in code, pipelines, and configuration. The underlying problem remains when the architecture still assumes reusable secrets are the normal way for machines to authenticate.

Q: What are the signs that NHI credential governance is broken?

A: Common signs include secrets in repositories, repeated rotation work with no net reduction in exposure, unclear ownership across DevOps and security, and credentials that survive beyond the workload that was meant to use them. Those patterns show that the programme is managing leakage, not governing the credential lifecycle.

Q: When should organisations move from vault-based secrets to workload identity?

A: Organisations should make the move when workloads are growing faster than manual credential handling can safely support, or when the same secret is reused across services. If onboarding, rotation, and offboarding are already brittle, workload identity becomes a governance necessity rather than an optimisation.

Technical breakdown

Why secrets sprawl persists in workload environments

Secrets sprawl persists because modern delivery pipelines distribute credentials faster than governance processes can inventory them. Developers and DevOps teams embed secrets in Git repositories, .env files, build steps, and configuration stores because the credentialing model is still the easiest way to make systems talk to each other. The result is not a single failure but a distributed control problem: each secret has a different owner, context, and exposure path. Vaults and scanners can reduce some risk, but they do not change the underlying dependence on reusable secrets for machine access.

Practical implication: map where workload credentials originate, move, and persist before you decide which controls to automate.

Why rotation and scanning only treat the symptoms

Rotation and scanning are downstream controls. Rotation shortens exposure after a secret exists; scanning tries to find it after it has already been created or leaked. Neither control removes the need to place credentials into pipelines, code, or runtime configuration in the first place. That is why these tools often feel busy but incomplete. They help when leakage has already happened, yet the same architecture keeps generating new secrets faster than they can be retired, especially in environments with multiple repos, teams, and deployment paths.

Practical implication: treat rotation and scanning as compensating controls, not as a substitute for reducing secret dependence.

How workload identity changes the governance model

Workload identity replaces the assumption that non-human systems should authenticate by carrying reusable secrets everywhere they go. Instead of pushing static credentials through delivery chains, teams bind access to the workload itself and issue access in a more constrained, contextual way. That changes governance from secret custody to identity lifecycle management: who or what is allowed to access a system, under what conditions, and for how long. For NHI programmes, this is the point where secrets management stops being the centre of gravity and becomes one control in a broader access model.

Practical implication: evaluate where workload identity can replace persistent secrets rather than asking how to secure every existing secret better.

NHI Mgmt Group analysis

Credentialitis is an NHI governance failure, not a hygiene problem. Secrets sprawl persists because organisations keep managing the symptom, which is leaked or misplaced credentials, instead of the underlying access model that depends on them. Vaults and scanners can reduce exposure, but they do not change the fact that workloads are still being built around brittle, reusable credentials. The practitioner conclusion is that the real control question is how machine access is issued, scoped, and retired.

Secrets rotation is an exposure-control measure, not a governance model. Rotation shortens the useful life of a secret after it already exists, but it does not remove the dependency on placing that secret into code, pipelines, or configuration. That means the same pattern keeps reappearing under new names and in new locations. The implication for identity programmes is that lifecycle control must move upstream of credential creation, not just downstream of leakage detection.

Workload identity is the correct policy boundary for this problem. Once access is governed at the workload level, the security conversation shifts from secret custody to identity issuance, scope, and revocation. That is a more durable way to reduce the sprawl problem because it addresses why the secret exists in the first place. The practitioner conclusion is to treat workload identity as the control plane for non-human access.

Credential sprawl creates hidden ownership debt across DevOps and security teams. The article’s core insight is not that secrets exist, but that nobody clearly owns their end-to-end lifecycle once they are embedded in delivery systems. That ownership gap is why cleanup never finishes. The practitioner conclusion is to assign explicit governance for NHI credential lifecycle, not leave it as a shared annoyance.

Credentialitis gives the problem a useful name, but the disease is structural. Naming the condition helps teams recognise a pattern they have normalised, yet the pattern only changes when organisations stop treating every workload access path as a secret-management exercise. The practitioner conclusion is to align secrets, workload identity, and lifecycle governance into one operating model.

What this signals

Credentialitis is a useful label for a familiar failure mode: organisations keep trying to clean up secret sprawl without changing the workload access pattern that produces it. That means the control conversation should shift from where secrets are stored to whether they should exist at all for the workload in question.

NHI programmes should expect secrets management to remain necessary, but no longer sufficient, in mature environments. Once workload identity is available for a meaningful share of machine access paths, the governance burden moves from secret custody to identity lifecycle and scope control.

For practitioners

• Define the workload credential inventory Catalogue where passwords, API keys, tokens, .env files, and hardcoded blobs are created, stored, copied, and retired across delivery pipelines and runtime systems.
• Reduce persistent secret dependence Identify services and pipelines that can move from reusable credentials to workload identity, then prioritise those paths where secrets are currently baked into deployments.
• Reclassify rotation as a compensating control Use rotation and scanning to limit exposure while you redesign the access model, rather than treating either one as the end-state governance answer.
• Assign end-to-end ownership for NHI lifecycle Make one team accountable for creation, storage, use, rotation, and revocation of machine credentials so sprawl does not sit between DevOps and security.

Key takeaways

• Secret sprawl persists because teams keep layering vaults, rotation, and scanning over a credentialing model that still depends on reusable secrets.
• The article’s central point is that workload access is the real governance problem, not the presence of secrets alone.
• Reducing NHI risk requires changing how machine access is issued and retired, not only how existing credentials are cleaned up.

Key terms

• Credential Sprawl: Credential sprawl is the uncontrolled accumulation of machine secrets, keys, and tokens across systems, teams, and environments. It usually starts with a single use case and ends with overlapping permissions, unclear ownership, and a larger attack surface than the organisation expected.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Secrets Rotation: Secrets rotation is the practice of replacing credentials on a schedule or after an event so exposed values stop working quickly. In NHI programmes, rotation must be tied to ownership and automation, otherwise credentials remain valid long after teams believe the risk has been addressed.
• NHI lifecycle governance: NHI lifecycle governance is the set of policies and controls used to manage non-human identities from creation to retirement. It covers approval, issuance, rotation, monitoring, access review, revocation, and deletion for service accounts, API keys, tokens, certificates, and AI agents, so machine identities remain accountable, least privileged, and auditable.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.