Secrets management mistakes expose the real NHI governance gap

At a glance

What this is: This is a secrets management analysis that identifies five recurring mistakes and shows how they expose passwords, API keys and database credentials.

Why it matters: It matters because IAM, PAM and NHI programmes fail when secrets are treated as static artefacts instead of governed identities with access, rotation and revocation controls.

By the numbers:

• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Keeper Security's analysis of common secrets management mistakes

Context

Secrets management is the discipline of storing, rotating, monitoring and revoking credentials such as passwords, API keys and database secrets so they are not left embedded in code or spread across uncontrolled systems. In identity programmes, those secrets are not just configuration data. They are non-human identities that carry access and deserve lifecycle governance.

The governance gap appears when secrets are handled as one-time implementation details instead of access-bearing identities. That is where hardcoded credentials, over-provisioning and forgotten secrets turn into persistent attack paths for cloud, application and PAM teams.

Keeper Security's article is a straightforward reminder that many of the failures are operational rather than theoretical. The starting point is typical of most enterprises: secrets are distributed across code, tools and teams before anyone has a complete control picture.

Key questions

Q: How should security teams eliminate hardcoded secrets in application code?

A: Security teams should remove credentials from source code entirely and replace them with runtime injection from a controlled secret store. Repository scanning is still useful, but only as a detection layer. The governing principle is that code should reference a secret at runtime, not contain the secret itself.

Q: Why do duplicated secrets increase the risk of a broader compromise?

A: Duplicated secrets increase risk because one exposed credential can authenticate to multiple systems, creating a larger blast radius than the original leak suggests. When the same secret is reused across applications, compromise of one path can become compromise of several. That is a governance problem, not just a storage problem.

Q: What breaks when organisations do not centralise secrets management?

A: Without centralisation, teams lose visibility into where secrets live, who can access them and whether they have been rotated or revoked. That makes audit, offboarding and incident response slower and less reliable. Fragmented secret storage is one of the clearest signs that lifecycle governance is incomplete.

Q: How should IAM and PAM teams govern secret access after a role change or offboarding?

A: They should treat secret access like any other privileged entitlement: revoke it at the same time the role changes, the application retires or the person leaves. If a credential cannot be proven inactive after offboarding, it remains a standing access path. Pair the process with the NHI Lifecycle Management Guide and the 52 NHI Breaches Analysis.

Technical breakdown

Hardcoded secrets create durable exposure in code repositories

Hardcoding secrets means placing credentials directly in source code, configuration files or scripts. Once committed, they are copied into version control history, build systems and developer workflows, where removal is difficult and exposure can persist long after the original file is changed. Environment substitution helps reduce this pattern, but only if the credential is externalised from the application and injected at runtime. The real problem is that code repositories are poor secret stores because they multiply access paths and make accidental disclosure easy.

Practical implication: remove secrets from code paths entirely and treat repository scanning as a detection control, not a primary safeguard.

Rotation failure turns leaked credentials into standing access

Secret rotation limits how long a compromised credential remains useful. Without automated rotation, a leaked token or password can continue to authenticate indefinitely, especially when nobody owns revocation as a routine control. Rotation only works when it is tied to inventory, ownership and expiry. Otherwise, teams create a false sense of security by storing secrets centrally while leaving them valid far beyond their intended use window.

Practical implication: automate rotation for every credential class that can be rotated and prove that stale values are actually retired.

Least privilege and JIT access reduce secret blast radius

Over-provisioning access means users or systems can retrieve more secrets than their task requires. In IAM terms, that is privilege creep applied to secrets. Role-based access control narrows who can see what, while just-in-time access shortens the period during which elevated access exists. The key design point is that secrets should be retrievable only by the smallest set of identities needed for the shortest workable time. Centralised PAM helps enforce that boundary across multiple platforms.

Practical implication: map secret access to task-specific roles and require time-bound elevation for sensitive retrieval paths.

Threat narrative

Attacker objective: The attacker aims to obtain durable, reusable access through a secret that was never properly governed as an identity.

1. Entry begins when a secret is hardcoded in a repository, copied into tickets, or stored in multiple unsecured locations where it can be harvested.
2. Credential access follows when the exposed secret is reused, duplicated or left unrotated, giving an attacker persistent authentication into the target environment.
3. Impact occurs when the compromised secret is used to access production systems, sensitive data or downstream services that trust the same identity.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• 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

Secrets management is identity governance, not file hygiene. The article's real lesson is that passwords, API keys and database credentials behave like non-human identities with ownership, scope and expiry. When they are hardcoded, duplicated or left unrotated, the organisation has already failed at governance before any attacker enters the picture. Practitioner conclusion: treat every secret as a governed identity object.

Secret sprawl is a control failure because visibility is the prerequisite for lifecycle action. Once secrets are split across code, cloud services, configuration files and ad hoc storage, no team can reliably answer who owns them, where they live, or whether they are still valid. That undermines auditability, offboarding and revocation. Practitioner conclusion: centralisation is necessary because unmanaged distribution defeats lifecycle control.

Least privilege for secrets is a blast-radius problem, not just an access model problem. Over-provisioned retrieval rights mean one compromised account can expose many credentials at once, especially when the same secret is reused across applications. RBAC and JIT help, but only if they constrain retrieval to task scope and duration. Practitioner conclusion: the smaller the secret retrieval set, the smaller the compromise surface.

Lifecycle neglect is the failure mode that turns ordinary credentials into long-lived attack paths. Secrets that are never revoked after use or offboarding remain valid for attackers to find later, which is why lifecycle management belongs in the same governance conversation as PAM and recertification. Practitioner conclusion: if revocation is not measurable, the programme is not actually controlling secrets.

Identity blast radius: repeated secret reuse creates a multiplier effect where one exposed credential opens multiple systems. That concept matters because the article describes over-provisioning, centralisation gaps and lifecycle neglect as separate mistakes, but they combine into the same structural risk. Practitioner conclusion: map where one secret unlocks more than one application and reduce that dependency first.

From our research:

• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• For a deeper governance lens, review NHI Lifecycle Management Guide for provisioning, rotation and revocation patterns that reduce secret sprawl.

What this signals

Identity blast radius: the next control priority is not merely secret storage, but how far one credential can travel across applications and teams before it is detected. With 62% of secrets duplicated across multiple locations in our research, the programme problem is structural, not isolated. Pair this with the OWASP Non-Human Identity Top 10 to map where reuse and overexposure sit in your control stack.

The practical signal for IAM and PAM teams is that lifecycle evidence must become measurable. If you cannot prove where a secret exists, who can retrieve it and when it was last rotated, the control is incomplete. That is why lifecycle governance belongs alongside the Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs, not as an afterthought.

Secret management is increasingly a cross-domain identity problem because application teams, platform teams and security teams all touch the same credentials. The governance model has to absorb human process failure, machine reuse and PAM enforcement together, or duplication will continue to outrun remediation. The organisations that close this gap fastest will be the ones that treat secrets as governed identities rather than configuration artefacts.

For practitioners

• Inventory every secret class and owner Build a living register of passwords, API keys, certificates and database credentials, including where each secret is stored, who owns it and what system consumes it. Without ownership and location data, rotation and revocation remain partial controls.
• Eliminate hardcoded credentials from code paths Move credentials out of repositories and into runtime injection or external secret stores, then add repository scanning to catch regressions. Use it as a detection backstop, not as permission to keep secrets in source control.
• Automate secret rotation and revocation Set rotation policies by secret type and business criticality, and make revocation part of offboarding, incident response and application decommissioning. Track whether old values are retired, not just whether new values were issued.
• Constrain retrieval with RBAC and JIT controls Limit which identities can retrieve which secrets, and require just-in-time elevation for high-risk access paths. Centralise those controls in PAM so teams do not build inconsistent exceptions across cloud and application stacks.

Key takeaways

• Secrets management fails most often when credentials are treated as code snippets rather than governed identities with ownership, scope and expiry.
• The scale of the exposure problem is visible in duplicated secrets, hardcoded credentials and weak lifecycle discipline, not in one isolated control gap.
• Practitioners should focus on centralised ownership, automated rotation and tightly constrained retrieval to shrink the blast radius of any compromise.

Key terms

• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, collaboration tools, cloud services and local files. It creates hidden copies of the same secret, making ownership unclear and revocation incomplete. In practice, sprawl turns routine credentials into persistent exposure points that are hard to inventory or retire.
• Just-in-Time Access: Just-in-time access is a control pattern that grants elevated access only for the minimum period needed to complete a task. For secrets, it reduces the time a credential can be retrieved or used, which lowers blast radius. The control is effective only when elevation is tightly logged and automatically removed.
• Secret Lifecycle Management: Secret lifecycle management covers creation, storage, use, rotation, revocation and expiry of credentials. It ensures that a secret is not only protected while active but also removed when it is no longer needed. Strong lifecycle control is what stops valid credentials from becoming forgotten attack paths.
• Role-Based Access Control: Role-based access control assigns permissions according to job function rather than individual request. In secrets management, it limits which identities can retrieve specific credentials and helps prevent over-provisioning. The model works best when roles are tightly scoped and periodically recertified against actual usage.

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.

This post draws on content published by Keeper Security: Common Mistakes To Avoid in Secrets Management. Read the original.