Treat refresh tokens as durable non-human identities with owners, expiry dates, and revocation procedures. Map where they are stored, who can redeem them, and which third parties hold them. Then tie offboarding, access review, and incident response to token custody, not just to user accounts.
Why Refresh Tokens Need NHI Governance
Refresh tokens are not just authentication leftovers. In SaaS environments they often behave like durable non-human identities because they can outlive sessions, bypass normal password change events, and continue to redeem access long after the original user interaction ended. That makes them a custody problem as much as an identity problem. Security teams that only track user accounts miss the real control point: where the token is stored, who can present it, and whether a third party can redeem it on the organisation’s behalf. The risk shows up quickly when tokens are copied into support tools, chat threads, or integration platforms, which is why secret sprawl guidance matters here, including the Guide to the Secret Sprawl Challenge and the Salesloft OAuth token breach. NIST Cybersecurity Framework 2.0 reinforces the same operational logic: know what exists, where it sits, and how it is controlled, not just who nominally owns the account behind it. In practice, many security teams discover token misuse only after a SaaS integration has already been abused, rather than through intentional custody review.How to Operationalise Token Custody, Rotation, and Revocation
Security teams should treat every refresh token as a governed asset with an owner, scope, expiry expectation, and revocation path. That starts with inventory. Map each SaaS app to the exact token types it uses, where those tokens are stored, and which systems can redeem them. If a token is embedded in CI/CD, ticketing, or automation tooling, it needs the same visibility as any other secret. The Top 10 NHI Issues and the Internet Archive breach both show how quickly long-lived access becomes a persistence mechanism when custody is unclear. NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward asset visibility, access control, and response discipline rather than ad hoc token handling.- Assign an accountable owner for each refresh token family, not just the parent SaaS account.
- Set rotation and expiry policy based on risk, API sensitivity, and third-party storage.
- Revoke tokens automatically when staff leave, apps are replaced, or integrations change purpose.
- Log every redemption event so unusual geography, volume, or client type can be reviewed.
- Require break-glass handling for high-privilege tokens, with documented approval and rapid cleanup.
Where the Guidance Gets Messy in Real SaaS Environments
Tighter refresh token governance often increases operational overhead, requiring organisations to balance resilience against support friction. That tradeoff is real in SaaS estates with legacy integrations, outsourced administrators, and vendor-managed automation. Best practice is evolving, but current guidance suggests avoiding broad, permanent refresh tokens where short-lived, narrowly scoped sessions are viable. This is especially important when tokens are duplicated across tools, because duplicated custody makes revocation incomplete. Entro Security’s research found that 44% of NHI tokens are exposed in the wild, and that 91% of former employee tokens remain active after offboarding, which makes token governance a lifecycle issue, not a one-time hardening exercise. For teams building stronger controls, the same principles that apply to secrets sprawl and SaaS compromise patterns in the Dropbox Sign breach remain relevant: shorten exposure, reduce duplication, and make revocation actionable. For standards alignment, NIST Cybersecurity Framework 2.0 provides the governance baseline, while NIST Cybersecurity Framework 2.0 also supports the response discipline needed when a token must be killed fast. The hardest cases are vendor-owned SaaS connectors and shared service accounts, because control over the token often sits outside the security team’s direct administrative boundary.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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Refresh tokens need rotation, expiry, and revocation as governed NHI credentials. |
| NIST CSF 2.0 | PR.AC-4 | Token redemption is an access-control issue tied to least privilege and session governance. |
| NIST CSF 2.0 | DE.CM-8 | Monitoring token use helps detect abuse, duplication, and abnormal redemption patterns. |
Log token redemption events and alert on unusual client, location, or volume changes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on May 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
Reviewed and updated by the NHIMG editorial team on May 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
