Credential management is failing where NHI risk is expanding

At a glance

What this is: A credential management guide that frames secure handling, lifecycle control, and privileged access as the core defenses against unauthorized access and data leakage.

Why it matters: It matters because IAM teams have to govern far more than human logins: the same lifecycle gaps that break password hygiene also create exposure across service accounts, API keys, and other NHIs.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Zluri's guide to credential management and secure access controls

Context

Credential management is the operational discipline of creating, storing, updating, and revoking credentials so that access follows policy instead of convenience. In practice, that means the controls around passwords, tokens, API keys, certificates, and vaulting have to work across the full identity surface, not just employee logins.

The governance gap appears when organisations treat credentials as static artefacts instead of lifecycle objects. Once secrets sprawl into code, CI/CD, and third-party integrations, the same access logic that supports human IAM no longer contains NHI exposure, and compromise becomes a matter of finding the weakest stored secret rather than defeating authentication.

That is why credential management now sits directly inside NHI governance, PAM, and access review programmes. The topic is no longer only about user convenience or password policy. It is about whether the organisation can still account for every identity that can act on its behalf.

Key questions

Q: What breaks when credentials are stored outside a secrets manager?

A: When credentials live in code, config files, or CI/CD systems, they bypass the controls that make secrets governable. Rotation, revocation, and auditability become fragmented, and attackers can recover valid access without defeating authentication. The result is not just weaker security, but an identity estate that no longer knows where its own access paths exist.

Q: Why do service accounts and API keys create outsized IAM risk?

A: Service accounts and API keys often outlive the task, team, or vendor relationship that created them. If they are not rotated and revoked on schedule, they become standing access paths with little human visibility. That is why NHI governance has to cover entitlement scope, ownership, and lifecycle, not only the initial provisioning event.

Q: How do organisations know if credential management is actually working?

A: Look for evidence that secrets are vaulted, rotated, and revoked on time, and that orphaned credentials are being removed quickly after the owner changes. If secrets still appear in code or build tools, or if stale keys remain valid for long periods, the programme is only controlling a portion of the problem.

Q: Who is accountable when exposed credentials are used in an attack?

A: Accountability usually sits across IAM, security operations, application owners, and platform teams because the failure is rarely isolated. If the credential was created, stored, or shared outside policy, ownership needs to be explicit before the incident happens. Post-incident, the key question is which control failed to revoke access before misuse became possible.

Technical breakdown

Credential sprawl and secret storage outside vaults

Credential sprawl happens when secrets move beyond controlled repositories into code, configuration files, CI/CD pipelines, endpoints, and shared documents. Once that happens, the secret is no longer governed by the vault’s access policy or audit trail. Attackers do not need to defeat authentication if they can recover a usable token, API key, or certificate from a place designed for convenience rather than control. This is the structural weakness credential management is supposed to remove, yet many environments still treat scattered secrets as an acceptable trade-off for speed.

Practical implication: inventory where credentials live outside approved vaults and remove every persistent secret from build and deployment paths.

Why privileged access management is not enough on its own

PAM protects elevated sessions, but it does not automatically solve credential provenance, rotation, or offboarding. A privileged account can be tightly monitored and still remain dangerous if the underlying secret is long-lived, shared, reused, or copied into downstream systems. Credential management has to govern the lifecycle of the credential itself, not just the user interface around it. Otherwise, the organisation sees activity logging without true containment, which is a common failure mode in hybrid identity estates where humans, service accounts, and workloads overlap.

Practical implication: pair PAM controls with rotation, revocation, and lifecycle ownership for every privileged credential.

Zero trust and least privilege depend on credential lifecycle discipline

Zero trust assumes each request must be verified continuously, while least privilege assumes access can be scoped tightly enough to reduce blast radius. Both assumptions collapse when credentials persist too long, are reused across systems, or are never revoked after role change or project exit. Credential management is therefore the enforcement layer that makes these models real. Without timely deactivation, token expiry, and access review, zero trust becomes an authentication slogan and least privilege remains a provisioning ideal rather than an operational control.

Practical implication: align credential expiry and access review cycles so zero-trust and least-privilege controls are enforceable in practice.

Threat narrative

Attacker objective: The attacker wants valid access that bypasses authentication controls and opens a direct path to sensitive systems, data, and operational actions.

1. Entry occurs when attackers recover exposed credentials from code, configuration files, or other insecure storage locations and use them as valid access paths.
2. Escalation follows when those credentials grant broad or persistent access, allowing abuse of service accounts, privileged actions, or downstream systems without friction.
3. Impact comes through data access, manipulation, or lateral movement across the environment once the credential is accepted as legitimate.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Credential management fails when organisations treat credentials as objects to store rather than identities to govern. The article describes passwords, MFA, SSO, PAM, and vaulting as separate mechanisms, but the real risk is the lifecycle gap between issuance, use, rotation, and revocation. That gap is where service accounts and API keys become long-lived access paths instead of governed identities. Practitioners should treat every credential as an identity with an expiry, not a static secret.

Secret sprawl is the named governance problem this article exposes. Credentials in code, config files, CI/CD, and shared environments are no longer governed by a single control plane, which means auditability fragments before access is even used. That is why credential management cannot be reduced to password policy or vault adoption. The practitioner conclusion is to govern where secrets are allowed to exist, not only how they are protected once found.

Least privilege is only real when credential scope and credential lifetime are both constrained. The article correctly ties credential management to zero trust, but many programmes stop at authentication and ignore persistence. Excessive privilege becomes more dangerous when the credential itself is durable, portable, and reusable across systems. Practitioners should measure whether access can be removed as quickly as it is granted.

PAM without credential lifecycle control leaves a false sense of containment. Logging privileged sessions does not fix an orphaned API key, a forgotten certificate, or an unrotated service account. The discipline has to extend across human and non-human identities because attacker value comes from whichever credential remains valid the longest. The practitioner conclusion is to unify PAM, secrets management, and lifecycle governance under one operating model.

Credential governance is now a board-level identity control, not a back-office hygiene task. The article links credential control to compliance, auditing, and risk reduction, which is the right framing for modern identity programmes. Once secrets are embedded in delivery pipelines and third-party access paths, the blast radius is organisational, not just technical. Practitioners should position credential management as part of identity resilience.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That lifecycle gap is why Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the right next reference for teams building revocation discipline.

What this signals

Secret sprawl will keep outpacing control-plane maturity unless identity teams treat every stored secret as a governed asset. The operational signal is not just how many credentials exist, but how many exist in places that the access programme cannot see. That is where NHI governance becomes a prerequisite for zero trust rather than a downstream clean-up activity.

Credential lifecycle ownership is becoming the differentiator between mature IAM and ceremonial IAM. When owners cannot answer who revokes a token, when it expires, or where it is stored, the programme has already lost the control boundary. Teams should expect auditors and incident responders to ask the same question from different angles.

As credential populations grow, the identity blast radius expands faster than most review cadences can contain. A useful reference point is the 52 NHI Breaches Analysis, which shows how quickly a single exposed secret can cascade into broader access compromise. Teams that want to reduce that radius need to align vaulting, rotation, and offboarding into one operational chain.

For practitioners

• Map every credential repository and spill point Inventory code repositories, CI/CD variables, configs, shared documents, endpoints, and ticketing systems for stored secrets, then remove any persistent credential that can be replaced with vault-backed retrieval.
• Tie rotation to identity lifecycle events Rotate API keys, tokens, and certificates when roles change, vendors offboard, or workloads are reconfigured, instead of relying on calendar-based rotation alone.
• Separate privileged access from credential persistence Use PAM for session control, but enforce short-lived issuance, revocation, and ownership for the underlying secret so a logged session does not mask a durable compromise path.
• Measure orphaned and unrevoked credentials as risk indicators Track the count of unused accounts, stale API keys, and certificates that remain valid after their owner or workload should no longer need them, then escalate those as governance defects.

Key takeaways

• Credential management is no longer just about passwords and MFA. It is about governing every secret that can act as an identity.
• The evidence points to a persistent lifecycle gap, with secrets still living outside vaults and privileged access remaining overly broad.
• Teams that want real reduction in identity risk need to connect vaulting, rotation, revocation, and ownership into one operating model.

Key terms

• Credential Management: The controlled process of creating, storing, updating, rotating, and revoking credentials so that access remains authorized throughout its life. In identity programmes, it is the mechanism that keeps passwords, tokens, API keys, and certificates tied to ownership, policy, and auditability instead of drifting into unmanaged access.
• Secret Sprawl: The uncontrolled distribution of credentials across code, configuration, build systems, shared files, and other locations outside approved vaults. It weakens governance because the organisation loses a single authoritative place to rotate, revoke, and audit the secret, which makes compromise easier to miss and harder to contain.
• Privileged Access Management: A control discipline that governs elevated accounts and high-risk sessions by limiting what can be done, when it can be done, and how it is recorded. It reduces exposure, but it only becomes effective when the underlying credential lifecycle is also managed and orphaned access is removed quickly.
• Zero Trust: An access model that assumes trust should not be granted by default and that every request must be verified against current context. For credentials, this means short-lived access, continuous review, and rapid revocation, especially where service accounts and other NHIs can otherwise keep acting long after they should have been removed.

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 Zluri: Security & Compliance Credential Management: The Ultimate Guide. Read the original.