Revoke them when the application is no longer needed, ownership changes, the user leaves, the business purpose ends, or the granted scopes no longer match the task. If a connection is dormant, broad, or undocumented, it should be treated as a candidate for removal.
Why This Matters for Security Teams
OAuth grants and refresh tokens are not “set and forget” assets. They are live authorization paths, and the risk changes as soon as the business context changes. If a tool is retired, a team re-orgs, or the scopes no longer match the task, the token can outlive its legitimate purpose. That is how dormant integrations become shadow access, and why lifecycle discipline matters as much as initial approval.
The problem is familiar across NHI programs: credentials remain active long after the human owner has moved on, the application has been replaced, or the original use case has been forgotten. NHIMG research on The 2025 State of NHIs and Secrets in Cybersecurity found that 91% of former employee tokens remain active after offboarding, showing how weak revocation hygiene turns routine admin changes into exposed access paths. That pattern is also consistent with the OWASP Non-Human Identity Top 10, which treats unmanaged lifecycle and excessive standing access as core failure modes.
In practice, many security teams encounter token misuse only after an integration has already drifted out of ownership, rather than through intentional lifecycle control.
How It Works in Practice
The cleanest revocation trigger is a change in business reality: the app is no longer needed, the customer or employee departs, the connector is replaced, the scopes are reduced, or the owner cannot justify continued access. That is the operational logic behind the NHI Lifecycle Management Guide and the broader lessons in Guide to the Secret Sprawl Challenge: inventory first, then revoke what is no longer serving a documented purpose.
For refresh tokens, teams should assume the token is a standing privilege even if the access token is short-lived. Best practice is evolving toward event-driven revocation plus periodic entitlement review. That means tying revocation to offboarding, app decommissioning, scope changes, and owner changes, while also checking for dormant tokens that have not been used within an approved window. If your stack supports it, pair this with short TTLs, token rotation, and immediate invalidation of the refresh token when the underlying trust boundary changes. The same discipline applies when OAuth is used for machine-to-machine access, because the token often becomes the de facto workload identity.
- Revoke immediately when ownership changes or the business purpose ends.
- Revoke when scopes no longer match the minimum required task.
- Revoke dormant connections that have no documented owner or current use case.
- Prefer short-lived credentials and rotate refresh tokens on a fixed policy.
- Validate that revocation actually propagates to the resource server and downstream caches.
Recent breach analysis such as the Salesloft OAuth token breach shows why this matters: once a token is stolen or reused outside its intended context, revocation speed becomes the difference between contained exposure and broad data access. These controls tend to break down in SaaS sprawl and partner integrations because ownership is distributed, inventory is incomplete, and revocation does not always reach every cached or federated trust path.
Common Variations and Edge Cases
Tighter revocation control often increases operational overhead, so organisations must balance security gain against integration friction. That is especially true for long-lived partner connections, legacy applications, and workflows that lack strong automation.
There is no universal standard for when a refresh token should be revoked in every environment, but current guidance suggests using business triggers rather than arbitrary calendar dates alone. Some teams combine calendar-based review with event-driven revocation to catch stale grants that were never formally closed. Others use a risk-based model, where high-scope or high-sensitivity grants are removed faster than low-risk ones. The important point is consistency: if an org cannot explain why a token still exists, it should not remain active.
Be careful with edge cases where revocation can break production flows. Shared service accounts, embedded third-party automations, and poorly documented vendor callbacks often fail when a token is removed without a replacement path. In those cases, the right move is usually to replace static standing access with a controlled successor rather than preserving the old grant indefinitely. NHIMG’s Top 10 NHI Issues and Guide to NHI Rotation Challenges both point to the same conclusion: lifecycle control fails most often where ownership, telemetry, and dependency mapping are weakest.
For organisations building more formal controls, the right operational target is not “never use refresh tokens.” It is “revoke them as soon as the authorizing condition no longer exists, and make that decision auditable.”
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 NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle and rotation control is central to revoking stale OAuth grants. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access review maps directly to OAuth scope reduction and removal. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero trust supports continuous verification and short-lived authorization paths. |
Revoke grants when purpose or ownership changes, and enforce documented token lifecycle reviews.
