Legacy secrets management is failing modern NHI governance

At a glance

What this is: This webinar argues that legacy secrets management is no longer fit for today’s NHI-heavy application environments, because secret volume, sprawl, and operational overhead have outgrown static vault models.

Why it matters: IAM and PAM teams need to treat secrets governance as a lifecycle and blast-radius problem, not just a storage problem, because unmanaged NHI credentials expand both operational burden and breach exposure.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Akeyless's webinar analysis of legacy secrets management and NHI risk

Context

Secrets management is the discipline of controlling credentials, tokens, API keys, and certificates across applications, pipelines, and runtime environments. In this article, the core governance problem is that legacy vault approaches assume a smaller, more static identity footprint than modern software now creates. That assumption breaks as non-human identities multiply across cloud and multi-cloud deployments.

Akeyless positions the issue as one of scale, operational friction, and risk concentration rather than simple storage. The practical identity question is how to govern secrets when the number of machine identities and their dependencies outpaces manual review, rotation, and offboarding cycles.

For IAM and security leaders, this is no longer a narrow DevOps issue. It is a broader identity lifecycle problem that touches access governance, privileged access, application security, and the boundary between human intent and machine execution.

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 legacy secrets management approaches struggle in cloud and multi-cloud estates?

A: Because they were designed for slower-changing environments where secrets and access relationships were easier to track. Cloud and multi-cloud estates create more identities, more integrations, and more movement between systems, which makes manual rotation and static governance too slow to keep up.

Q: What breaks when organisations rely on long-lived credentials for modern applications?

A: The main failure is blast-radius expansion. If a reusable secret leaks, it can unlock multiple systems, survive beyond the original workflow, and remain useful until it is discovered and revoked. That turns a single exposure into persistent access and delayed containment.

Q: What is the difference between ephemeral credentials and secretless access for NHI governance?

A: Ephemeral credentials still issue a short-lived secret for a task or session, while secretless access removes reusable secrets from the workflow where possible. Both reduce standing exposure, but secretless patterns push governance further by eliminating the durable secret altogether.

Technical breakdown

Why legacy vault models struggle in dynamic application estates

Traditional secrets vaults were built around relatively stable systems where credentials changed infrequently and access paths were easier to enumerate. Modern application estates are different: containers, APIs, CI/CD pipelines, service accounts, and workload identities all generate short-lived or frequently reused secrets. That creates a control problem because the vault is only one part of the chain. The harder problem is governing issuance, distribution, use, and revocation across systems that continuously create new identity relationships.

Practical implication: Map where secrets are created and consumed, then identify where current vault controls stop short of runtime governance.

Secret sprawl as an identity lifecycle failure

Secret sprawl is not just a storage problem. It is an identity lifecycle failure caused by duplicated credentials, unmanaged rotation, orphaned access, and inconsistent ownership across environments. When secrets proliferate faster than teams can classify and retire them, security leaders lose visibility into which identities are active, which are stale, and which are exposed. That is why sprawl tends to correlate with both operational burden and breach likelihood.

Practical implication: Treat secrets inventory, ownership, and retirement as lifecycle controls, not as a periodic hygiene task.

Why ephemeral and secretless access change the control model

Ephemeral credentials reduce the persistence of standing secrets by limiting exposure windows and making access more task-scoped. Secretless patterns go further by removing reusable secrets from the workflow where possible, shifting trust to federated identity, short-lived tokens, or workload-native authentication. The architectural benefit is not just reduced leakage risk. It is also lower remediation cost because there are fewer durable credentials to find, revoke, and replace after misuse or exposure.

Practical implication: Prioritise short-lived credential patterns for high-churn workloads and use federated identity wherever reusable secrets can be removed.

Threat narrative

Attacker objective: The attacker wants durable access to applications and cloud resources by exploiting reusable secrets that outlive the system that issued them.

1. Entry begins when reusable secrets are embedded in applications, pipelines, or shared vaults and then exposed through compromise, misconfiguration, or developer workflow leakage.
2. Escalation follows when the exposed secret grants access to additional systems, allowing the attacker to move from one workload or service account to broader application or cloud privileges.
3. Impact occurs when the attacker uses those privileges to exfiltrate data, alter code, or persist through copied credentials and untracked downstream dependencies.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Legacy secrets governance is a lifecycle problem, not a storage problem. The article shows that the real issue is not whether a vault exists, but whether the organisation can classify, rotate, revoke, and retire secrets across a fast-moving application estate. When secrets are duplicated across pipelines, environments, and teams, control ownership breaks down. The practitioner conclusion is that secrets must be governed as identities with lifecycles, not as static objects.

Secret sprawl is the named failure mode modern IAM programmes keep underestimating. Organisations often measure vault adoption while missing the operational reality that multiple manager instances, manual rotation, and inconsistent developer behaviour create fragmented control. That fragmentation weakens accountability and slows remediation. The practitioner conclusion is that centralisation without lifecycle governance only consolidates risk.

Static secret assumptions fail when application identity is no longer stable. Traditional controls assume a secret will exist long enough to be inventoried, reviewed, and retired on schedule. In dynamic application environments, that assumption erodes because secrets are created, copied, and reused faster than review cycles can catch up. The practitioner conclusion is that standing credential models do not align with modern software execution patterns.

Ephemeral credential trust debt: the hidden cost of delaying modernisation. The article’s strongest signal is that legacy secrets strategy keeps organisations paying for manual work, duplicated effort, and higher exposure windows. That is not just inefficiency. It is accumulated governance debt that increases the chance of breach and slows recovery. The practitioner conclusion is to treat secret modernisation as a risk-reduction programme, not an optimisation project.

From our research:

• 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.
• From our research: Only 44% of organisations are currently using a dedicated secrets management system, according to The 2024 State of Secrets Management Survey.
• Short-lived credential patterns are the natural next step, and Ultimate Guide to NHIs , Static vs Dynamic Secrets gives the operational baseline.

What this signals

Secret sprawl is becoming a governance debt item, not a tooling issue. With 27-day remediation cycles still common in the research base, organisations cannot rely on ad hoc rotation and manual investigation to contain exposure. The programme impact is straightforward: secrets management needs the same ownership, review cadence, and offboarding discipline that IAM teams apply to other high-risk identities.

Static-vs-dynamic is now the decisive design choice for secrets programmes. The organisations that keep persistent credentials in pipelines, applications, and shared vaults will keep paying for leakage recovery and audit friction. Teams that move toward short-lived credentials and federated access reduce the number of durable secrets they must govern and investigate.

A useful way to frame the change is to treat the secret lifecycle as part of the identity lifecycle, not as a separate operations function. That makes it easier to align with NIST Cybersecurity Framework 2.0 and to connect governance decisions back to access, detect, and respond outcomes.

For practitioners

• Build a complete secrets inventory across environments Identify every place credentials, tokens, API keys, and certificates are created, stored, or copied. Include CI/CD pipelines, application configs, shared vaults, developer laptops, and cloud runtime services so ownership and rotation responsibilities are explicit.
• Replace long-lived secrets with short-lived access patterns Prioritise ephemeral credentials, federated identity, and secretless workflows for high-churn applications and pipeline access. Start with systems where compromise impact is highest and where manual rotation has already become operationally fragile.
• Reduce vault fragmentation and duplicated control planes Consolidate overlapping secrets manager instances where possible and standardise on a single governance model for issuance, rotation, and revocation. Fragmentation makes it harder to prove control ownership and slows incident response when a leak occurs.
• Tie secret rotation to ownership and offboarding events Rotate and revoke secrets when teams change, applications are retired, or service accounts lose purpose. If the lifecycle event is not linked to revocation, orphaned secrets will persist long after the workload they served is gone.

Key takeaways

• Legacy secrets management fails when organisations confuse vault storage with lifecycle governance.
• Secret sprawl turns one leaked credential into a broader access problem that can persist for weeks.
• Short-lived credentials and tighter ownership are the controls that most directly reduce exposure and recovery cost.

Key terms

• 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.
• Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.
• Secretless Access: Secretless access is a pattern where workloads authenticate and receive access without relying on long-lived embedded credentials. It typically uses runtime identity verification, federation, and short-lived authorization decisions. The goal is to reduce exposure from hardcoded or reusable secrets while keeping machine-to-machine access functional.

What's in the full article

Akeyless's full article covers the operational detail this post intentionally leaves for the source:

• The webinar framing around legacy secrets failure modes and the shift from static vaults to modern secrets patterns.
• The “Secrets Management Maturity Model” introduced in the session and how it is used to assess programme progress.
• The operational trade-offs between unified secrets control, developer friction, and secretless or ephemeral approaches.
• The practical narrative used in the webinar to connect manual rotation, overhead, and application development impact.

👉 Akeyless's full post covers the modern secrets strategy, maturity model, and operational burden behind secret sprawl.

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.