What breaks when a secret is deleted from code but not revoked?

Why This Matters for Security Teams

Deleting a secret from code only removes one copy of the credential. It does not invalidate the credential itself, so the standing privilege can remain usable until the backing service revokes it. That is why secret leakage is an identity event, not a file hygiene issue. Current guidance from the OWASP Non-Human Identity Top 10 and NHI Management Group research on the Ultimate Guide to NHIs — Static vs Dynamic Secrets both point to the same failure mode: exposed secrets often stay valid long after discovery.

The operational risk is simple. Attackers who copied the secret before deletion can continue authenticating, sometimes from outside normal monitoring paths, until rotation or revocation closes the door. In environments with CI/CD, shared service accounts, or hard-coded API keys, cleanup in Git does not touch tokens already issued by cloud platforms, SaaS tools, or internal services. Secret sprawl makes that persistence worse because the same credential may exist in logs, builds, artifacts, and developer machines. In practice, many security teams discover the exposure only after the secret has already been abused, rather than through intentional revocation testing.

How It Works in Practice

A deleted secret breaks the source of truth, not the identity itself. If the secret is a long-lived API key, service account password, or certificate, the authenticating system still trusts it until the credential is explicitly invalidated. That means response needs three steps: revoke the old credential, issue a replacement if the workload still needs access, and verify that the old value no longer works. NHI lifecycle controls described in the NHI Lifecycle Management Guide are designed for exactly this kind of offboarding and replacement.

• Find every place the secret may have been copied, including code, CI logs, container layers, and deployment variables.
• Invalidate the credential at the issuing service, not just in the repository.
• Rotate dependent secrets that may have been derived from or shared with the exposed value.
• Check for successful reuse attempts, because deletion alone does not prove containment.

Where static secret are unavoidable, shorter TTLs reduce the time an exposed value remains useful. Where possible, best practice is evolving toward dynamic secret, workload identity, and just-in-time issuance so there is less to revoke after a leak. This is especially important in supply chain scenarios such as the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack, where secrets can be harvested before defenders notice. These controls tend to break down when the credential is shared across many services because revocation can trigger unexpected outages and reveal hidden dependencies.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance faster containment against service continuity. Not every secret can be rotated instantly, and some legacy systems only support manual invalidation or coarse-grained account resets. In those cases, current guidance suggests treating the leaked secret as compromised even if the repository has been cleaned, then scheduling rapid replacement and downstream testing. The Guide to the Secret Sprawl Challenge shows why this is difficult when secrets are duplicated across developer laptops, pipelines, and vendor integrations.

There is no universal standard for this yet, but the practical rule is consistent: removal from code is evidence of cleanup, not evidence of security. If the secret was embedded in a third-party integration, a mobile build, or a token with broad scope, assume the blast radius is larger than the repository suggests. Teams that rely only on Git history or secret scanners also miss old clones and forked repositories. In high-churn delivery pipelines, the real control is not deleting the secret after exposure, but proving the old credential is dead and the replacement is constrained to the minimum required scope. That distinction matters most in environments with automated deployment, because the same credential may already be in flight when the leak is discovered.

Related resources from NHI Mgmt Group

• What breaks when a secret is deleted from Git but not rotated?
• What breaks when SCIM provisioning code uses unsafe secret handling?
• How should security teams handle leaked JWTs that cannot be centrally revoked?
• When do AI-generated code and assistants increase secret exposure risk?