Topic starter
22/08/2025 2:54 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Corsha: “a\”.
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
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: API secrets management can be widely adopted and still leave material exposure if lifecycle controls are weak.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
06/10/2026 11:26 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: API secrets management is still failing to deliver security