Who is accountable when leaked secrets remain active after discovery?

Why This Matters for Security Teams

Leaked secrets are not just a detection problem. Once a token, API key, or certificate is exposed, the real question is whether the credential was revoked, rotated, and removed from any place it could still be used. That makes accountability a governance issue across PAM, IAM, cloud operations, and application owners, not only an incident response task. NHI Management Group’s Guide to the Secret Sprawl Challenge frames this as a lifecycle failure, not a one-time leak.

The scale of the problem is also persistent. In The State of Secrets Sprawl 2026, GitGuardian reports that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which means discovery without revocation leaves active access in place. That is why security teams need clear ownership before an incident happens, not a postmortem after the secret has already been abused. In practice, many security teams discover this only after a leaked credential has already been reused for lateral movement or cloud access.

How It Works in Practice

Accountability should follow control ownership, not just detection ownership. The team that finds the leak may operate the scanner, but the team that owns the secret lifecycle must ensure the credential is disabled, rotated, and validated everywhere it can be consumed. That includes CI/CD systems, SaaS integrations, application configuration, and workload identities. The operational model should define who approves revocation, who executes it, and who verifies that downstream systems did not cache the old value.

For mature programmes, this is usually handled through a response playbook tied to the secret type:

• API keys and tokens: revoke immediately, replace with a new value, and audit for abuse.
• Certificates: invalidate or replace according to trust path and expiry impact.
• Cloud credentials: disable access keys, inspect IAM usage, and check for privilege escalation.
• Embedded secrets in pipelines: rotate the secret and patch the pipeline, repository, or secret manager reference.

This is also where deterministic ownership matters. Current guidance from the OWASP Non-Human Identity Top 10 and NHI Management Group’s research on 52 NHI Breaches Analysis shows that leaked machine credentials often remain exploitable because no single owner is accountable for their revocation path. Teams should map every secret to a system owner, a business owner, and a technical revoker, then test that path during tabletop exercises. These controls tend to break down when secrets are copied into unmanaged tools or shared manually across teams because revocation no longer reaches every live dependency.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance faster containment against release friction and service downtime. That tradeoff is especially visible when the leaked secret is shared across multiple services, because immediate revocation can break production if no rotation process exists. In those cases, current guidance suggests treating shared secrets as a design flaw and moving toward scoped, short-lived credentials instead of long-lived static values.

There is also a real exception for forensic containment. If a leaked secret is suspected to be in active abuse, security may need to snapshot logs and preserve evidence before revocation. That does not change accountability. It only changes sequencing. Likewise, some environments use secrets brokers or managed rotation services, but those reduce, not remove, the need for ownership. If a team delegates storage to a platform without assigning revocation responsibility, the organisation still has a gap.

For executive reporting, the simplest rule is this: the finder reports, but the owner fixes. If no owner can be named, the organisation has a control failure, not just a security event. NHI Management Group’s The State of Secrets in AppSec reinforces why this matters: remediation still averages 27 days, which leaves a long window for misuse if accountability is unclear. Best practice is evolving, but the operational expectation is stable: every exposed secret must have one accountable owner, one revocation path, and one verification step.

Related resources from NHI Mgmt Group

• Why do leaked secrets remain such a persistent NHI risk?
• Who is accountable when third-party access remains active after the task is complete?
• Why do leaked private keys remain dangerous after discovery?
• Why do leaked secrets remain a problem after developers delete them?