TL;DR: A 2023 survey of more than 400 professionals found that 86% spend up to 15 hours a week provisioning and managing secrets, while 53% have already faced a breach tied to compromised API secrets and 56% still worry about data loss, according to Corsha. The problem is no longer visibility alone; it is whether secret handling is actually reducing exposure.
At a glance
What this is: Corsha’s survey shows that API secrets management adoption is widespread, but many teams still report breach exposure and lingering security concern.
Why it matters: IAM, PAM, and NHI teams should treat secrets management as a lifecycle control problem, not a tool adoption problem, because unmanaged exposure persists after deployment.
By the numbers:
- 86% of respondents spend up to 15 hours a week provisioning, managing, and dealing with secrets
- Over half 53% of respondents have already experienced 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
- 56% of respondents are still concerned about a potential data breach
Context
API secrets management is the discipline of issuing, storing, rotating, and revoking credentials such as tokens and keys that let software access APIs and connected systems. The central governance gap in this report is that many teams have adopted secrets tooling without proving that the lifecycle is actually reducing exposure.
Corsha’s survey suggests that operational burden and security confidence are moving in opposite directions. That matters because the control point is not whether a secrets platform exists, but whether it can bound blast radius across provisioning, rotation, and revocation in a way IAM and NHI programmes can govern.
For IAM and NHI practitioners, the practical question is whether secrets management is being used as a record-keeping layer or as an enforced access-control mechanism. This report points to the latter as the standard teams still struggle to reach.
Key questions
Q: Why do API secrets create breach risk even when organisations already use a secrets manager?
A: A secrets manager helps centralize storage, but it does not automatically prove that secrets are scoped, rotated, monitored, and removed correctly. Risk persists when credentials are over-exposed, reused, hard-coded, or left active longer than needed. In practice, attackers exploit gaps in operational discipline, not just gaps in tooling. Secure management requires governance, inventory, and continuous verification.
Q: How should IAM teams prioritise fixes when API secrets are already in use?
A: Start with the credentials that have the widest reach and the least visible ownership, because those secrets create the largest blast radius when compromised. Then tighten rotation, revoke stale credentials, and remove reuse across services. The goal is to reduce exposure first, not simply to increase the number of secrets under management.
Q: How do security teams know whether secret management is actually reducing risk?
A: Look for fewer reusable credentials, shorter credential lifetimes, and a lower number of systems that still depend on manually rotated secrets. If the environment still depends on stored tokens for routine workload access, the programme is managing exposure, not removing it.
Q: When should organisations replace reusable API secrets with shorter-lived credentials?
A: They should do so whenever a credential is used across multiple systems, survives beyond a single workflow, or cannot be confidently revoked after a change in service ownership. In those cases, reuse creates unnecessary exposure, and shorter-lived credentials reduce the period in which compromise can be exploited.
Technical breakdown
Why secrets management can still leave exposure
Secrets management reduces manual handling, but it does not automatically make a secret safe. If a token or key is still long-lived, broadly scoped, or reused across services, the attack surface remains even when the credential is stored in a vault. The control fails when teams confuse storage centralisation with lifecycle governance. That means a secret can be well managed operationally and still be insecure from an IAM perspective because the real risk sits in how long it lives, where it works, and how quickly it can be revoked.
Practical implication: measure secrets management by exposure window and privilege scope, not by whether a vault exists.
Why API secrets create recurring governance burden
API secrets are machine credentials, so their risk profile is closer to NHI governance than to human password management. They often sit inside application pipelines, shared services, and integrations that are hard to inventory completely. Once teams lose visibility into where secrets are deployed, they also lose reliable offboarding and rotation discipline. The result is governance drift: the secret remains valid after the original business need has changed, which is exactly where compromised credentials become durable access paths.
Practical implication: inventory API secrets by owning system and business purpose, then tie each one to a revocation owner.
Why centralised tooling does not guarantee secure outcomes
A secrets management platform can improve consistency, but control quality depends on policy enforcement, not tool presence. The report’s tension between adoption and concern is typical of programmes that have not closed the loop between discovery, rotation, and validation. In practice, teams can have a ‘managed’ estate that still contains stale credentials, over-privileged tokens, and forgotten integrations. That is a governance problem, because the programme lacks assurance that the control is actually constraining access rather than simply recording it.
Practical implication: test whether rotation, revocation, and access logging are enforced across every secret class and integration.
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.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
API secrets management still fails when the programme stops at centralisation. A vault or secrets platform reduces sprawl, but it does not by itself prove that access is short-lived, scoped, or offboarded correctly. The important issue is whether the control reduces the chance that a stolen secret remains usable long enough to matter. Practitioners should treat the gap between storage and governance as the real security defect.
Compromised API secrets are an NHI problem, not just an application problem. The report’s breach concern shows that machine credentials behave like persistent access paths when they are not lifecycle-governed. That places API secrets squarely inside NHI, PAM, and IAM operating models rather than leaving them as an engineering-only concern. The implication is that ownership, revocation, and review need to be defined at the identity layer, not only in application pipelines.
Secret visibility without revocation discipline creates false confidence. A team can know where secrets exist and still fail to control how long they remain exploitable. That is why high adoption can coexist with breach anxiety. The security question is not whether the estate is recorded, but whether every secret can be invalidated when usage changes. Practitioners should judge their programme by containment speed, not by dashboard completeness.
Ephemeral secret trust debt: the longer a machine credential remains valid after issuance, the more security work is deferred into the future. This article shows that many organisations are carrying that debt even after adopting formal secrets management. The corrective lens for identity teams is to treat every long-lived secret as accumulated exposure until proven otherwise.
From our research library:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
- Read next: NHI Lifecycle Management Guide
What this signals
Ephemeral secret trust debt: the gap between secret issuance and actual revocation is now a governance metric, not just an operations detail. When teams cannot prove how quickly a compromised credential can be invalidated, they are carrying avoidable exposure across their API estate.
API secrets should be governed as NHI credentials with ownership, expiry, and revocation evidence attached. That shifts the programme away from inventory-first thinking and toward measurable containment, which is the only outcome that matters when secrets are already embedded in live integrations.
For practitioners
- Map every API secret to an owner and expiry rule Assign a named business or platform owner to each credential, then require an explicit expiry or rotation condition so the secret does not outlive the service purpose.
- Separate stored from usable secrets Track not only where secrets are stored, but where they are accepted at runtime, because a credential can be centrally managed and still be broadly usable across environments.
- Test revocation as a governance control Validate that a compromised API secret can be disabled across dependent services without manual hunting, and record the time to effective cut-off as a control metric.
- Reduce long-lived credential reuse Replace reusable API secrets with shorter-lived, purpose-bound credentials wherever integrations allow, and flag shared secrets as a priority remediation class.
Key takeaways
- API secrets management can be widely adopted and still leave material exposure if lifecycle controls are weak.
- The report shows that operational burden and breach concern continue even where teams already use a secrets management solution.
- The practical fix is to govern ownership, rotation, reuse, and revocation as identity controls, not as tooling features.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on compromised API secrets and persistent exposure. |
| NHI-07 — Long-Lived Secrets | The report's risk is driven by secrets that remain usable long after issuance. | |
| NHI-05 — Overprivileged NHI | Compromised API secrets become more dangerous when their scope is wider than necessary. | |
| Recommendation — Scan for leaked API secrets and revoke any credential exposed outside governed storage. Replace long-lived API secrets with shorter-lived credentials and enforce rotation deadlines. Reduce secret scope to the minimum access needed and remove shared credentials where possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | API secrets are authenticators whose lifecycle must be managed and rotated. |
| Recommendation — Apply authenticator lifecycle controls to rotate, replace, and revoke API secrets on schedule. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Compromised API secrets enable credential access and follow-on abuse in the article's breach pattern. |
| Recommendation — Map compromised secret scenarios to credential-access detections and prioritize exposed token hunting. | ||
Key terms
- API Secret: An API secret is a credential that allows a machine or application to access an API. It may be a key, token, password, or certificate. If exposed, reused, or left long-lived, it can be copied by attackers and used to impersonate the original workload.
- 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.
- Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org