Credentialitis shows why secrets sprawl is still an NHI governance failure

At a glance

What this is: This Aembit post reframes secrets sprawl as “Credentialitis” and argues that the real issue is a brittle credentialing model, not a simple hygiene problem.

Why it matters: It matters because IAM, PAM, and NHI programmes cannot reduce risk if they only rotate and scan secrets without fixing ownership, lifecycle, and workload identity controls.

👉 Read Aembit's full Credentialitis experience and workload IAM recovery guide

Context

Secrets sprawl is the accumulation of passwords, API keys, tokens, configuration files, and hardcoded credentials across systems and repos. In NHI terms, that means the organisation is managing too many standing secrets with too little lifecycle control, and the result is a governance problem rather than a tooling problem.

Aembit’s framing is deliberately blunt: vaults, rotation schedules, and scanning can help, but they do not remove the brittle credentialing model that keeps creating exposure. For IAM, PAM, and workload identity teams, the question is not how to clean up one more secret, but how to stop depending on long-lived secrets as the default access pattern.

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 rotation fail to eliminate credential exposure?

A: Vaults and rotation control handling, but they do not remove the underlying dependency on reusable secrets. If teams still issue long-lived credentials for services, pipelines, and integrations, exposure will keep reappearing in repos, config files, and handoffs. The control is useful, but it is not a substitute for changing the access model.

Q: What do security teams get wrong about secrets scanning?

A: They often treat scanning as proof of governance when it is only a detection layer. Scanning finds leaked secrets, but it does not tell you whether the secret should exist, who owns it, or whether it was revoked after use. Effective programmes pair detection with inventory, lifecycle control, and replacement of standing credentials.

Q: How do IAM teams know whether workload identity adoption is working?

A: Look for fewer reusable secrets, fewer manual rotation exceptions, and fewer access paths that depend on copied credentials. If workload identity is working, teams should see less secret handling in delivery pipelines and a cleaner offboarding process for applications and integrations. The signal is reduced credential dependency, not just a larger vault.

Technical breakdown

Why secrets sprawl persists in modern delivery pipelines

Secrets sprawl persists because development and operations pipelines still rely on reusable credentials to make systems work across services, environments, and build stages. A password or token embedded in a repo, .env file, or config blob is easy to create and hard to govern once it leaves the intended boundary. Rotation and scanning reduce exposure, but they do not change the fact that the secret is still the control plane for access. That creates blind spots around ownership, revocation, and reuse across services.

Practical implication: teams need a precise inventory of where secrets are created, copied, stored, and consumed before they can reduce standing exposure.

Why vaults and rotation do not solve the underlying model

Vaults and rotation are compensating controls. They limit how long a secret remains valid and centralise some handling, but they still assume the system should depend on a secret that can be stolen, shared, or embedded. That is why secret sprawl often survives even in organisations that have invested in secret management. The governance failure is structural: the access model is still credential-centric rather than identity-centric, so the same patterns reappear in new tools and new pipelines.

Practical implication: move from secret handling to workload identity patterns where the service proves who it is without persistent shared secrets.

Workload IAM as the exit path from credentialitis

Workload IAM shifts the security model from storing reusable secrets toward issuing bounded, contextual credentials tied to the workload’s identity and runtime. In practice, that means reducing the number of secrets that developers must manage manually and narrowing the places where secrets can be exfiltrated. It also improves accountability because the identity is attached to the workload lifecycle rather than to a copied credential artifact. This is where governance becomes measurable instead of aspirational.

Practical implication: define a roadmap that replaces the highest-risk long-lived secrets first, starting with cross-environment and third-party access.

NHI Mgmt Group analysis

Credentialitis is a useful name for a familiar failure mode, but the real issue is credential dependency. Organisations do not just have too many secrets; they have built critical access paths on artefacts that are easy to copy, hard to revoke, and impossible to observe everywhere at once. That is why scanning and rotation keep feeling productive while the exposure surface stays large. The practitioner takeaway is that the problem is architectural, not cosmetic.

Vault-first programmes often reduce the symptoms without changing the disease. Centralising secrets can improve control, but it still leaves teams managing long-lived bearer credentials as the default access mechanism. The discipline gap is that ownership, rotation, and offboarding remain fragmented across DevOps, platform, and security teams. The practitioner takeaway is that governance must track the lifecycle of the credential model itself, not just the secret inventory.

Workload identity is the named concept that emerges from this post. In this context, it means reducing reliance on reusable secrets by binding access to the workload’s identity and runtime context instead of to copied credentials. That matters because it changes the security boundary from secret storage to identity assertion. The practitioner takeaway is to treat workload identity as the control objective, not a specialised add-on.

Secrets sprawl is now an identity governance issue as much as an engineering issue. The more secrets exist outside managed lifecycle controls, the more likely it is that access reviews, offboarding, and exception handling will miss them. That creates an NHI management blind spot that can outlive individual teams and tools. The practitioner takeaway is to align identity governance, platform engineering, and security operations around one shared inventory and one shared revocation process.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• The same research also shows that 1 in 4 organisations are already investing in dedicated NHI security capabilities, which is why the Ultimate Guide to NHIs is the right next step for teams reworking secret-heavy access models.

What this signals

Credentialitis is what happens when secret sprawl becomes normalised as an operational cost. Teams then optimise for keeping delivery moving instead of reducing the number of reusable credentials that need to be managed, scanned, and rotated. That is why the governance conversation needs to shift from secret handling to workload identity, and why the broader issue is visible in Top 10 NHI Issues.

The practical signal for IAM and platform teams is that vault growth does not equal risk reduction. If every new integration still produces another long-lived secret, the programme is preserving the same dependency tree in a cleaner interface. The better metric is how many access paths no longer rely on copied credentials at all.

For practitioners

• Map all standing secrets by owner and runtime Build an inventory of passwords, API keys, tokens, config files, and hardcoded blobs across repos, pipelines, and application runtimes. Assign a clear owner to each secret and define where it is used, who can rotate it, and how it is revoked.
• Replace cross-environment shared credentials first Prioritise secrets that grant access across multiple environments, teams, or vendors because they create the widest blast radius. Convert those access paths to workload identity or short-lived credentials before tackling lower-risk local credentials.
• Tie secret revocation to offboarding events Connect credential revocation to joiner-mover-leaver processes, vendor offboarding, and service retirement so access does not persist after business need ends. A secret that survives the workload lifecycle is a governance failure, even if it was rotated recently.
• Measure reduction in reusable secret count Track the number of long-lived reusable secrets, not just the number of scans completed or vault entries created. A lower count of reusable credentials is a better indicator of risk reduction than a higher count of secrets stored in a central tool.

Key takeaways

• Credentialitis is a governance problem caused by overreliance on reusable secrets, not just a hygiene issue.
• Rotation and vaulting help, but they leave the underlying credential-centric access model intact if nothing else changes.
• Workload identity is the clearer control objective because it reduces dependency on standing secrets and improves lifecycle accountability.

Key terms

• Credential sprawl: Credential sprawl is the uncontrolled spread of passwords, API keys, tokens, certificates, and other access artefacts across code, systems, and teams. It creates hidden attack surface because each extra secret increases the number of places where access can be copied, leaked, or forgotten before revocation.
• Workload identity: Workload identity is the practice of giving applications and services a verifiable identity so they can authenticate without relying on shared, long-lived secrets. It shifts governance from managing copied credentials to managing who the workload is, what it can access, and when that access should expire.
• Standing secret: A standing secret is any credential that remains valid beyond a narrow task or session and can be reused repeatedly. These secrets are efficient for developers, but they create persistent exposure because they stay usable until someone rotates or revokes them, often outside normal lifecycle controls.
• Secret lifecycle management: Secret lifecycle management is the discipline of creating, storing, rotating, monitoring, and revoking secrets according to business need. In mature programmes, it is tied to ownership and offboarding, so credentials do not outlive the workload, integration, or vendor relationship that required them.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Aembit: Credentialitis and the AccessZero experience. Read the original.