Secrets rotation is now a governance problem, not just a hygiene task

At a glance

What this is: This is an analysis of why secrets rotation has become a core control for DevSecOps and NHI governance, with the main finding that manual rotation breaks down under scale and exposure pressure.

Why it matters: For IAM, PAM, and NHI teams, the lesson is that secret lifetime, ownership, and offboarding discipline are security controls, not housekeeping tasks.

By the numbers:

• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read Akeyless' analysis of why secrets rotation matters for DevSecOps

Context

Secrets rotation is the practice of replacing credentials, keys, and tokens before their exposure window becomes a liability. In identity terms, it is a lifecycle control for non-human identities, because secrets outlive the humans who create them and often persist across code, pipelines, and infrastructure.

The article argues that the longer a secret exists, the more opportunities there are for disclosure, reuse, and attacker persistence. That maps directly to NHI governance: the control problem is not just protection at rest, but reducing the time a credential remains valid, discoverable, and reusable across systems.

The examples cited, including Uber, Dependabot, and Cloudflare, show how stale or forgotten secrets can turn routine access into broad compromise. That pattern is typical in environments where ownership is unclear, rotation is manual, and hidden dependencies are left behind during change or incident response.

Key questions

Q: How should security teams handle exposed secrets in modern software pipelines?

A: Treat exposed secrets as identity incidents, not just code defects. Identify the owning service, revoke the credential everywhere it may be used, and verify that downstream automation still functions. The goal is to shorten the secret’s usable life while preserving legitimate operations through a controlled rotation process.

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. If downstream systems are not mapped, automated rotation can cause outages or lockouts even while improving exposure posture. Rotate only after confirming every consumer and proving that replacement credentials can be deployed safely.

Q: What do security teams get wrong about secret rotation?

A: They often treat rotation as a substitute for removing the underlying credential model. Rotation lowers exposure time, but it still leaves a secret to steal, bootstrap, and govern. If a workload can avoid holding the secret at all, that is a stronger control than simply changing it more often.

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.

Technical breakdown

Why long-lived secrets create an exposure window

A secret is only as safe as its shortest control chain. Once a credential is embedded in code, scripts, backups, or third-party workflows, every copy becomes part of the attack surface. Rotation matters because compromise does not require instant discovery. Attackers often wait for stale tokens, reused keys, or forgotten service accounts that remain valid long after their original purpose ends.

Practical implication: shorten validity periods and remove hidden copies that keep a credential usable after initial exposure.

Why manual rotation fails under incident pressure

Manual rotation is slow because it depends on human discovery, coordination, and validation across multiple systems. In a real incident, the challenge is not only changing the secret but proving every dependent application, pipeline, and service has moved to the new value. That makes rotation an operational process, not a one-time credential change. At scale, missed dependencies become fresh attack paths.

Practical implication: treat rotation as a repeatable workflow with dependency mapping, validation, and rollback control.

How secrets sprawl undermines governance

Secrets sprawl appears when organisations spread credentials across multiple vaults, repositories, scripts, and cloud services without a unified inventory. The result is fragmented ownership and inconsistent policy enforcement. Governance fails when teams cannot answer basic questions about where a secret lives, who uses it, how often it changes, and what happens when access must be revoked. Visibility is the prerequisite for any credible rotation programme.

Practical implication: inventory all secrets and tie each one to an owner, purpose, rotation rule, and revocation path.

Threat narrative

Attacker objective: The objective is to turn stale credential exposure into durable internal access that can be reused for data theft, impersonation, and broader environment compromise.

1. Entry began when attackers obtained long-lived secrets or tokens that had been hard-coded, forgotten, or left valid after an environment change. Escalation followed when those credentials were used to impersonate legitimate systems or access backup, repository, or support infrastructure. Impact came when the same access was used to collect sensitive data, move through internal tooling, and widen compromise across connected systems.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

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.

Secret sprawl is a governance failure before it is a technical one. When organisations cannot see how many secrets exist, where they live, or which systems still depend on them, rotation becomes partial and fragile. This is why the secret inventory problem keeps reappearing in breaches and incident response. The operational conclusion is simple: unmanaged distribution of secrets creates unmanaged risk.

Automated rotation is the only control that scales with modern DevSecOps estates. The Cloudflare example in the article shows that even a well-resourced response can be strained by a small number of missed secrets. Human operators cannot reliably coordinate rotation across code, cloud, and legacy systems under incident pressure. The discipline is no longer about choosing between manual and automated rotation. It is about recognising that manual rotation cannot be the primary control in high-churn environments.

Long-lived credential trust debt is the right named concept for this problem. Every extra day a secret remains valid adds trust debt, because the organisation continues to trust a credential whose original context may already be gone. That debt accumulates across code, backups, third-party integrations, and inherited systems. Security leaders should measure whether their current estate can actually reduce trust debt, not just document it.

Secrets governance must be evaluated as part of broader identity controls. Rotation, offboarding, recertification, and owner assignment all serve the same purpose across human, machine, and application identities: remove access that no longer has a business reason to exist. In practice, this means secrets management cannot sit outside IAM, PAM, and lifecycle governance. It has to be part of the same control plane.

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.
• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• For deeper lifecycle context, the NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding fit the same governance model.

What this signals

Long-lived secrets create trust debt across the entire identity estate. The practical issue for security leaders is not whether a secret can be rotated, but whether the programme can prove that the old value is no longer usable anywhere it was copied. That puts secrets management squarely into NHI lifecycle governance, where inventory quality and revocation discipline matter as much as tooling.

Secret sprawl should be measured as a governance signal, not an operational inconvenience. When credentials are scattered across repositories, pipelines, and legacy systems, every incident becomes a discovery exercise. Teams that already struggle to maintain ownership boundaries should align their programme with the OWASP Non-Human Identity Top 10 and the Guide to the Secret Sprawl Challenge before the next leak forces the issue.

For practitioners

• Implement automated rotation for high-risk secrets Prioritise hard-coded credentials, service tokens, and keys used in build pipelines, backup servers, and administrative workflows. Automate dependency checks so rotation does not break downstream services or leave orphaned access behind.
• Create a complete secret inventory Map every secret to an owner, use case, system dependency, and rotation interval. Include repositories, scripts, CI/CD pipelines, cloud consoles, and legacy systems so that missed credentials can be identified before they become incident gaps.
• Define revocation playbooks for compromised credentials Establish a response path that covers detection, replacement, validation, and follow-up verification. Use the playbook to confirm that all references to the old secret are removed, not just that a new secret exists.
• Align secrets policy with lifecycle governance Tie secret issuance and rotation to joiner-mover-leaver processes, application ownership, and periodic access review. When a system, team, or vendor relationship changes, the associated secrets should be reviewed as part of the same lifecycle event.
• Use NHI controls for legacy and machine identities Apply NHI governance to service accounts, automation tokens, and older systems that cannot support modern auth patterns. Where credentials remain necessary, reduce their scope, shorten their lifespan, and document their revocation path.

Key takeaways

• Secrets rotation reduces exposure only when the old credential is fully retired across every dependency.
• The article’s real warning is governance failure: manual processes miss hidden copies, forgotten tokens, and orphaned access paths.
• Security teams need automated rotation, complete inventory, and lifecycle ownership if they want secrets management to hold up under real-world pressure.

Key terms

• Secrets Rotation: Secrets rotation is the practice of replacing credentials on a schedule or after an event so exposed values stop working quickly. In NHI programmes, rotation must be tied to ownership and automation, otherwise credentials remain valid long after teams believe the risk has been addressed.
• 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.
• Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

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.

👉 Akeyless' full article covers the policy, automation, and lifecycle detail behind effective secrets rotation.

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.