API secrets management is still failing to deliver security

At a glance

What this is: This is Corsha’s survey of API secrets management practices, and its core finding is that operational effort and perceived control still do not translate into security.

Why it matters: It matters because API secrets sit at the intersection of NHI, workload identity, and access governance, so weak handling increases risk across cloud, application, and automation estates.

By the numbers:

• 86% of respondents spend up to 15 hours a week provisioning, managing, and dealing with secrets.
• (53%) of respondents have already experienced a data, ced a data breach due to unauthorized access to their networks or apps due to compromised API secrets.
• 72% of respondents use a secrets management solution, but 56% are still concerned about a potential data breach.

👉 Read Corsha's state of API secrets management report

Context

API secrets management is the discipline of provisioning, storing, using, and retiring the credentials that let applications, services, and automation authenticate to each other. In practice, the security gap is often not whether a vault exists, but whether the organisation can keep credential exposure, rotation, and offboarding aligned with how those secrets are actually used.

Corsha’s survey shows the familiar pattern: organisations think they have a secrets solution, yet still carry breach exposure and high manual effort. That is a governance problem as much as a tooling problem, because API secrets behave like non-human identities and must be managed with lifecycle discipline, not just central storage.

For IAM and security leaders, the signal is that secrets sprawl is now an operating-model issue, not a niche platform concern. The question is whether access governance, workload identity, and secrets handling are being treated as one control surface or as disconnected tasks.

Key questions

Q: What breaks when API secrets are managed centrally but not governed through their full lifecycle?

A: Central storage without lifecycle governance leaves shared, long-lived credentials alive after scope changes, ownership changes, or compromise. The result is a false sense of control: teams can see the secret, but they cannot prove who uses it, where it propagates, or how quickly it can be revoked everywhere it matters.

Q: Why do API secrets create lateral movement risk in cloud and application environments?

A: API secrets often authenticate directly into services without human friction, and they are frequently reused across pipelines, applications, and environments. If one secret is exposed, attackers may inherit access that spans multiple systems, which turns a single credential leak into a broader authenticated attack path.

Q: How do security teams know whether their secrets programme is actually reducing risk?

A: Look at ownership, scope, rotation speed, revocation speed, and the number of places a secret is accepted. If the programme cannot answer those questions for every credential, it is managing storage rather than reducing exposure. The most useful metric is the time a secret remains viable after compromise.

Q: Who is accountable when a compromised API secret is reused across multiple systems?

A: Accountability usually sits across application owners, platform teams, and identity governance because the failure spans issuance, distribution, and revocation. Mature programmes assign a single owner per secret class, define who can rotate or retire it, and require evidence that downstream consumers were updated.

Technical breakdown

Why API secrets are a lifecycle problem, not just a storage problem

API secrets are credentials, not configuration. A secret can appear in code, CI/CD, a vault, a ticket, or an environment variable, but its risk comes from how long it lives, where it is copied, and whether it can be revoked everywhere it was used. When teams treat secrets management as simple storage, they miss the real control points: issuance, binding, rotation, and retirement. That is why a solution can centralise secrets yet still leave exposure intact if applications and automation continue to reuse long-lived credentials.

Practical implication: map every secret to an owner, a workload, and a retirement path before you treat it as governed.

Why breached API secrets create fast lateral movement paths

A compromised API secret is often enough to authenticate directly into an application, cloud service, or internal integration without triggering the same friction as a human login. Once an attacker has that credential, the next step is usually not password guessing but privilege discovery and reuse across adjacent systems. The danger is greatest when secrets are shared across services, embedded in pipelines, or granted broad scopes. In that environment, one exposed token can become a reusable access path rather than a single failed authentication event.

Practical implication: assume any exposed API secret is a valid entry point into multiple systems until scope and reuse are proven otherwise.

Why “we have a secrets manager” is not the same as secure secrets governance

A secrets manager reduces some classes of exposure, but it does not automatically fix lifecycle drift, orphaned credentials, or poor developer discipline. Secure governance depends on whether the organisation can answer who issued the secret, where it is used, how often it rotates, and how quickly it can be revoked after compromise. If those answers are unclear, the programme still depends on manual follow-up and tribal knowledge. The survey’s gap is not the absence of tooling. It is the absence of end-to-end control over secret usage.

Practical implication: test your secrets programme against issuance, rotation, revocation, and ownership, not just vault adoption.

Threat narrative

Attacker objective: The attacker’s objective is to turn a single compromised API secret into authenticated access that can be reused across applications and networks.

1. Entry occurs when an attacker obtains an API secret from code, logs, a repository, or another exposed location and uses it as a valid credential.
2. Escalation follows when the secret grants access to multiple services or carries broader scope than the original application needs.
3. Impact occurs when the attacker uses that authenticated access to move into networks or applications, steal data, or disrupt services.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• 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

Good secrets management is not the same as secure secrets governance. Corsha’s survey confirms a familiar failure mode: many teams can centralise secrets, but they still cannot prove the credential lifecycle is under control. The relevant benchmark is not whether a vault exists, but whether issuance, scope, rotation, and revocation are actually enforced across every workload that uses the secret. The practitioner conclusion is simple: storage alone does not equal governance.

API secrets behave like non-human identities, so the control model must treat them that way. A service credential is an identity object with lifecycle, scope, and blast-radius properties, not just a password replacement. That means secrets management has to align with NHI governance, zero standing privilege thinking, and workload identity design. If the credential outlives the workload or outscopes the task, the identity model is already broken. Practitioners should assess API secrets as governed identities, not as passive configuration.

Standing secret exposure window is the right name for the problem Corsha surfaces. The survey’s combination of weekly admin effort, breach experience, and ongoing concern shows that credentials remain live long enough to be found, copied, and reused. That is not a patching issue or a single control gap. It is a structural exposure window created by long-lived secrets and slow operational response. The implication is that teams must measure how long a secret remains viable in practice, not how quickly it can be rotated on paper.

The breach signal is telling the market to move from centralisation to enforceable lifecycle control. Organisations are past the point where a central vault is enough to claim maturity. The discipline now is provable ownership, constrained scope, rapid revocation, and visibility into where each secret is consumed. That direction aligns with OWASP NHI and NIST CSF control intent, not just operational convenience. Practitioners should re-evaluate whether their secrets programme can actually prove containment.

From our research:

• 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.
• Only 44% of organisations are currently using a dedicated secrets management system, which helps explain why secrets governance still fragments across teams and tools.
• For a broader lifecycle lens, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding fit together.

What this signals

Teams should expect API secret governance to get pulled into broader workload identity programmes rather than remain a separate vaulting exercise. The operational sign is whether access reviews can actually see secrets in use, or whether they only catalogue what was issued. With 43% of respondents in one NHIMG survey citing lack of central management, the structural issue is already visible in the data.

Standing secret exposure window: the practical measure is how long a credential remains usable after it should have been retired, rotated, or revoked. That concept will matter more as organisations tighten zero trust controls around machine access, because a secret that survives policy changes becomes a residual attack surface even when the surrounding environment looks hardened.

Security teams should also prepare for stronger linkage between secrets management, CI/CD security, and workload identity. The next maturity step is not just storing credentials more safely, but reducing how often humans have to touch them at all. That is where lifecycle controls start to outperform manual process.

For practitioners

• Inventory API secrets by workload and owner Build a live register of every API secret, token, and certificate, then bind each one to a named workload, system owner, and retirement path. If a secret cannot be tied to a consumer and an owner, treat it as unmanaged exposure.
• Measure secret exposure window instead of vault adoption Track how long each secret remains valid after creation, after rotation, and after suspected compromise. Use that metric to expose whether your programme depends on manual cleanup that attackers can outrun.
• Constrain scope for every credential issued to automation Reissue broad shared credentials as task-scoped identities with the narrowest permissions needed by the calling workload. Remove reuse across pipelines, applications, and environments unless a business exception is explicitly approved.
• Test revocation paths before incident day Validate that a compromised secret can be revoked everywhere it is accepted, including CI/CD jobs, runtime services, and downstream integrations. If revocation depends on a manual search, the control is not operational.

Key takeaways

• Corsha’s survey shows that API secrets are still being handled as an operational burden rather than as governed identities.
• The evidence points to a mismatch between tool adoption and security outcomes, with breach experience and manual effort remaining high.
• Practitioners should focus on ownership, scope, revocation, and exposure window if they want secrets management to reduce real risk.

Key terms

• API Secret: A credential used by applications, services, or automation to authenticate to another system. In identity governance terms, it is a non-human identity artefact with lifecycle, scope, and revocation requirements that must be controlled as tightly as any other privileged credential.
• Standing Secret Exposure Window: The period during which a secret remains usable after it should have been rotated, retired, or revoked. This is the real risk measure for machine credentials because compromise is only one part of the problem. Persistence after compromise often determines the final blast radius.
• Secrets Governance: The discipline of controlling who can issue, use, rotate, and retire secrets across their full lifecycle. It goes beyond vaulting and storage by demanding ownership, policy enforcement, visibility into usage, and fast revocation when a credential is no longer trustworthy.

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 programme maturity, it is worth exploring.

This post draws on content published by Corsha: Corsha State of API Secrets Management Report, 2023. Read the original.