Secrets management mistakes expose the real NHI governance gap

At a glance

What this is: This is a Keeper Security analysis of five common secrets management mistakes and the finding that weak lifecycle governance, not tooling alone, is what leaves NHI credentials exposed.

Why it matters: It matters because IAM, PAM and NHI teams need to manage secrets as governed identities with ownership, rotation and offboarding, not as static configuration buried in code or cloud settings.

Context

Secrets management is the discipline of controlling passwords, API keys, tokens, certificates and database credentials across their full lifecycle. The governance gap appears when those secrets are treated like configuration values instead of identities with ownership, scope, rotation and revocation requirements.

Keeper Security frames five recurring failure modes: hardcoding, missed rotation, over-provisioning, lack of centralised monitoring and poor lifecycle management. Those mistakes are familiar, but the article’s sharper point is that they are symptoms of a broader NHI governance problem, not isolated hygiene issues.

Key questions

Q: What breaks when secrets are hardcoded in development repositories?

A: Hardcoded secrets break the assumption that code repositories are only source artefacts. They become credential stores that persist across Git history, forks, and build outputs, which means a single exposure can outlive the file that originally contained it. The practical result is wider blast radius and slower containment than many teams expect.

Q: Why do stale secrets create such a large security risk?

A: A stale secret can still authenticate if no one has revoked it, which means an old credential can remain a live entry point long after the system or team that created it has changed. The risk is not the age alone, but the combination of lingering validity and unclear dependency ownership.

Q: Where does secrets management fail when access is over-provisioned?

A: It fails when more users, services or tools can reach a credential than actually need it. That widens the attack surface, increases the chance of accidental disclosure and makes it harder to prove who should have access. Least privilege only works if secret access is narrowly scoped and continuously reviewed.

Q: How should teams govern secrets when workloads span multiple regions?

A: Treat multi-region secrets as a governance problem, not just a deployment issue. Document which secrets are static, which are time-bound, and which must be available locally. Then align replication, rotation, and revocation policy to the workload’s failure domain so regional scale does not create inconsistent access or recovery outcomes.

Technical breakdown

Hardcoded secrets turn source code into an access path

Hardcoded secrets create a direct dependency between application code and credentials, which means source repositories, build logs and developer workstations can become unintended distribution points. Once a secret is embedded in code, it is far harder to inventory, rotate or revoke cleanly. The security failure is not only exposure, but persistence: the credential now exists in multiple copies and often outlives the application change that introduced it. That is why hardcoding is one of the clearest examples of secrets becoming unmanaged identities rather than controlled assets.

Practical implication: remove embedded credentials from code paths and shift secret issuance to controlled runtime injection.

Rotation and lifecycle control define whether a secret remains governable

Rotation reduces the value of a stolen secret by shortening the time it can be abused, but rotation alone is insufficient if issuance, revocation and expiry are not managed together. Secrets lifecycle management covers creation, storage, rotation, revocation and expiration as one control plane. Without that lifecycle view, organisations can have technically stored secrets that remain valid long after the business need has ended. The operational risk is that every stale credential becomes a standing access path, even when the original purpose has disappeared.

Practical implication: tie each secret to an owner, expiry condition and revocation trigger so validity never outlasts business need.

Centralised secrets management is about visibility, not just storage

Centralisation matters because fragmented vaults, environment variables and cloud-native stores fragment accountability. When different teams manage secrets in different places, the organisation loses the ability to answer basic governance questions such as which secrets exist, who can use them and whether they were rotated on schedule. Auditing and versioning become essential because they create traceability across the secret’s life rather than only at the point of storage. The underlying problem is not simply sprawl, but loss of control fidelity across the estate.

Practical implication: build a single inventory of secrets and enforce auditability across every storage location and consumer.

Threat narrative

Attacker objective: The attacker seeks durable access to sensitive infrastructure and data by abusing credentials that were never properly governed.

1. Entry occurs when secrets are hardcoded into repositories or scattered across unmanaged storage locations, giving an attacker a path to discover credentials outside normal control workflows.
2. Credential access follows when stale, over-provisioned or unrotated secrets remain valid long enough to be harvested and reused.
3. Impact occurs when the exposed secret is used to reach sensitive systems, databases or cloud resources before the organisation can revoke it.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• BitMart hot wallet hack 2021: A stolen private key let an attacker drain two BitMart hot wallets on Ethereum and Binance Smart Chain of about $150 million in December 2021.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets are not configuration objects, they are governed identities: When a password, API key or database credential can authenticate to a system, it needs ownership, scope, lifecycle and offboarding discipline. The article’s five mistakes all point to the same governance failure: organisations still treat secrets as static plumbing. That model breaks as soon as the credential itself becomes the access mechanism, so practitioners should govern secrets as non-human identities, not incidental settings.

Centralisation is the prerequisite for accountability, but not the endpoint: A single repository for secrets improves visibility only if it also supports rotation, audit, versioning and revocation. Without those controls, centralisation merely concentrates risk in one place. The practitioner lesson is that visibility without lifecycle enforcement does not reduce exposure, it just makes exposure easier to catalogue.

The real gap is validity windows that outlive purpose: The article shows how stale, over-provisioned and unreconciled secrets stay usable after teams forget why they exist. That is a governance defect, not just an operational one, because the organisation cannot prove when access should stop. The practical conclusion is to measure whether secret validity is still aligned to business need at every point in the lifecycle.

Least privilege for secrets fails when access is treated as permanent: RBAC and JIT help only when they are applied to secret consumption as well as human administration. If a workload or user can repeatedly reach the same credential without re-approval or expiry, the organisation has recreated standing privilege in another form. IAM teams should therefore assess secrets as part of privilege governance, not as a separate vaulting exercise.

From our research library:

• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• Read next: Service Account Security Guide

What this signals

Secrets sprawl is a governance problem before it is a tooling problem: When credentials live in code, pipelines and multiple vaults, the organisation loses the ability to prove where access begins and ends. That is why lifecycle ownership matters as much as storage controls.

Lifecycle-managed secrets are the decisive control boundary: The useful question is not whether a secret is encrypted or centrally stored, but whether its validity, owner and revocation path are still aligned to the workload that uses it. When they are not, the secret has become a standing NHI risk.

Teams that rely on manual review cycles will keep finding exposed credentials after the fact, because the control point is too late in the lifecycle. NHI programme owners should move governance upstream to issuance, rotation and revocation rather than assuming monitoring alone will contain the problem.

For practitioners

• Eliminate hardcoded credentials from delivery pipelines Scan repositories, build logs and deployment scripts for embedded passwords, API keys and database credentials, then replace them with runtime secret retrieval.
• Attach ownership and expiry to every secret Assign a human owner, business purpose and revocation condition to each secret so it can be retired when the application, vendor relationship or workload changes.
• Enforce automated rotation for high-risk secrets Prioritise credentials that unlock production systems, cloud services or databases, and make rotation automatic rather than dependent on manual change windows.
• Reduce secret sprawl with central auditing Inventory every storage location that can issue or hold credentials, then require audit trails and version history across all of them so access can be traced end to end.

Key takeaways

• Secrets management failures are usually governance failures in disguise, because hardcoding, over-provisioning and stale credentials all extend the life of access beyond its intended purpose.
• The source article shows that organisations can be highly confident in their secrets programmes while still leaving exposures unresolved for weeks.
• The strongest control response is to govern secrets as lifecycle-managed non-human identities with ownership, rotation and revocation built in.

Key terms

• Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines, typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Lifecycle Management: Lifecycle management is the process of creating, reviewing, rotating, and retiring identities and their secrets in a controlled way. For NHIs, it is essential because stale credentials, orphaned accounts, and incomplete offboarding are common paths to long-lived exposure and unauthorised access.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.