Notifications
Clear all
Topic starter
17/08/2026 4:42 pm
TL;DR: Long-lived secrets increase exposure windows and chain-of-custody risk, and Akeyless argues that automation is now the only practical way to keep rotation precise at scale. The issue is not whether rotation matters, but whether governance can keep pace with credential sprawl, human error, and incident response demands.
NHIMG editorial — based on content published by Akeyless: why secrets rotation matters for DevSecOps
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
Q: How should security teams handle exposed secrets in modern software pipelines?
A: Treat exposed secrets as identity incidents, not just code defects.
Q: When does secrets rotation create more risk than it reduces?
A: Rotation becomes risky when teams do not understand which services depend on the secret.
Q: What do security teams get wrong about secret rotation?
A: They often treat rotation as a substitute for removing the underlying credential model.
Practitioner guidance
- Implement automated rotation for high-risk secrets Prioritise hard-coded credentials, service tokens, and keys used in build pipelines, backup servers, and administrative workflows.
- Create a complete secret inventory Map every secret to an owner, use case, system dependency, and rotation interval.
- Define revocation playbooks for compromised credentials Establish a response path that covers detection, replacement, validation, and follow-up verification.
What's in the full article
Akeyless' full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on building a secrets rotation policy that fits different application and infrastructure patterns.
- Examples of how automated credential rotation is applied across varied environments, including legacy systems and machine identities.
- The article's practical discussion of when manual rotation is still used and why it should remain a last resort.
- A closer look at the platform-specific features the vendor says support rotation and secret lifecycle handling.
👉 Read Akeyless' analysis of why secrets rotation matters for DevSecOps →
Secrets rotation and the governance gap teams are missing?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:47 pm
Secrets rotation is now a lifecycle control, not a remediation task. The article shows that the security value of rotation is tied to how quickly a credential loses usefulness after exposure, not to how often a policy exists on paper. That places rotation inside NHI lifecycle governance, where ownership, revocation, and dependency tracking matter as much as the secret itself. Practitioners should treat every long-lived credential as a controlled asset with an expiry problem.
A few things that frame the scale:
- 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.
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: Who should own secrets lifecycle decisions in an IAM programme?
A: Ownership should sit with the identity and security teams that govern access policy, not only with application owners or platform engineers. Secrets lifecycle choices affect privilege scope, audit evidence, and operational resilience. The programme needs a clear accountable owner for exceptions, rotation policy, and revocation failure handling.
👉 Read our full editorial: Secrets rotation is now a governance problem, not just a hygiene task
