Use recurring campaigns to identify idle, non-expiring, or orphaned credentials, then require a concrete action such as rotation, disablement, or ownership reassignment. Pair the campaign with secrets management and offboarding controls so expired business need does not leave credentials active. The control works best when review leads directly to enforced remediation.
Why This Matters for Security Teams
Stale API keys and machine tokens turn routine access into a durable breach path. Once a credential is embedded in code, shared in tickets, or left behind after a project ends, it can outlive the business need that created it. That is why secrets management has to be treated as a lifecycle control, not just a storage problem, as shown in the Guide to the Secret Sprawl Challenge and the 2025 State of NHIs and Secrets in Cybersecurity. In that research, 91% of former employee tokens remained active after offboarding, which shows how quickly an “approved” credential becomes an exposure if ownership is not continuously enforced.
Current guidance from NIST Cybersecurity Framework 2.0 reinforces the need for continuous governance, asset visibility, and timely remediation rather than occasional review. The practical issue is not whether a key was once legitimate, but whether it still has a valid purpose, an accountable owner, and enforced expiry. In practice, many security teams encounter this failure only after an old token has already been reused by an attacker, rather than through intentional review.
How It Works in Practice
The most effective campaigns combine inventory, ownership validation, and enforced action. Start by discovering secrets across source control, chat, ticketing, CI/CD runners, vaults, and endpoint tooling. Then classify each key or token by service, owner, privilege level, and expiry status. The point is to separate active business use from dormant credential drift, a pattern that appears repeatedly in breach reporting such as the Salesloft OAuth token breach and the BeyondTrust API key breach.
Operationally, the campaign should drive one of three outcomes: rotate, disable, or reassign. Rotation is appropriate when the service still needs access but the secret has aged beyond policy. Disablement is the right choice when the business use has ended or the token cannot be confidently attributed. Reassignment should be rare and controlled, because handing off a token without changing its scope simply preserves the risk. Secret managers, PAM platforms, and CI/CD controls should all support this workflow so that a review task can trigger remediation instead of merely recording an exception.
- Use recurring scans to find idle, non-expiring, duplicated, and orphaned credentials.
- Require an owner response with a deadline, not just a notice in a dashboard.
- Link offboarding and project closure to automatic revocation or reassignment.
- Prefer short-lived secrets where technical design allows it.
GitGuardian reported that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is why detection without revocation is insufficient. These controls tend to break down when credentials are hard-coded into legacy services that lack central secret injection because rotation becomes a manual and brittle change process.
Common Variations and Edge Cases
Tighter rotation and review often increases operational overhead, so organisations need to balance exposure reduction against service stability and support load. Not every credential can be treated the same way. Long-lived integrations, external partner APIs, and embedded device tokens may need exception handling, but current guidance suggests those exceptions should be explicit, time-bounded, and reviewed more often than standard accounts. There is no universal standard for this yet, especially for hybrid estates where some systems support ephemeral credentials and others do not.
Some environments also need more than rotation. If a token is overprivileged, rotating it simply hands an attacker a fresh credential with the same excessive access. That is why token cleanup should be paired with scope reduction, RBAC review, and, where possible, JIT access patterns rather than permanent standing access. For organisations dealing with broad secrets sprawl, the Guide to the Secret Sprawl Challenge is a useful operational reference, while NIST Cybersecurity Framework 2.0 remains the clearest external baseline for continuous control and recovery discipline. In practice, the hardest cases are machine-to-machine links that were never designed for rotation, because the cost of change is highest where dependency mapping is weakest.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and SPIFFE/SPIRE set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers stale and overexposed NHI credentials that need rotation or revocation. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access review supports reducing the blast radius of stale machine tokens. |
| SPIFFE/SPIRE | Workload identity helps replace long-lived static secrets with verifiable service identity. |
Inventory NHI secrets, enforce expiry, and rotate or revoke any credential that no longer has an active owner.
