Refresh tokens become the bigger risk whenever they can persist beyond the original business need or bypass normal MFA and password controls. A short-lived access token limits abuse windows, but a refresh token can renew access repeatedly. That makes long-lived refresh grants the main source of durable SaaS exposure.
Why This Matters for Security Teams
Short-lived access tokens are easier to contain because their value decays quickly. Refresh tokens are different: they can mint new access repeatedly, so a single exposed grant can outlive MFA, password resets, and even some offboarding steps. That is why the practical risk shifts from “can this token be used now?” to “can this token still renew trust later?” The distinction matters most in SaaS and automation-heavy environments, where tokens are often copied into tickets, logs, browsers, or integrations.
NHIMG research shows how often that happens in the wild. The Salesloft OAuth token breach is a reminder that OAuth grants can become durable access paths, while the Guide to the Secret Sprawl Challenge shows how quickly credentials spread across collaboration tools and code. Current guidance from the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 points toward least privilege, lifecycle control, and rapid revocation rather than blind reliance on token type.
In practice, many security teams discover refresh-token risk only after a downstream SaaS account has already been quietly reissued access through an old grant.
How It Works in Practice
Operationally, the risk threshold is crossed when the refresh token becomes a durable bearer credential that can survive the original business purpose. A short-lived access token may be acceptable for a single session or API call, but a refresh token should be treated as a standing capability unless its renewal path is tightly controlled. That means binding refresh grants to a known client, limiting token lifetime, revoking on offboarding, and watching for abnormal renewal patterns. If the refresh token can be reused without re-authentication or re-approval, it is functionally closer to persistent access than to a temporary session artifact.
For most environments, the practical control set includes:
- Issue access tokens with short TTLs and keep refresh tokens as narrow as possible in scope and audience.
- Rotate refresh tokens on use where supported, and invalidate the previous grant immediately.
- Revoke refresh rights when the user, workload, or integration no longer has an active business need.
- Store tokens only in controlled secret managers, not in tickets, chat, or source control.
- Review SaaS app consent and delegated OAuth grants as part of identity governance.
The 2025 State of NHIs and Secrets in Cybersecurity found that 44% of NHI tokens are exposed in the wild, which helps explain why long-lived refresh grants are so dangerous in real workflows. For lifecycle and access discipline, the NIST Cybersecurity Framework 2.0 reinforces asset visibility, access control, and recovery as operational expectations rather than optional hygiene. These controls tend to break down when legacy SaaS apps lack refresh-token rotation, because the platform cannot distinguish normal renewal from stolen reuse.
Common Variations and Edge Cases
Tighter refresh-token controls often increase operational overhead, requiring organisations to balance user convenience against breach containment. That tradeoff is real, especially for mobile apps, background sync jobs, and third-party integrations that expect uninterrupted access. Current guidance suggests that refresh tokens are not inherently unsafe; they become riskier when their lifetime, reuse rules, and revocation process are looser than the business need. In regulated or high-trust environments, best practice is evolving toward shorter renewal windows and more explicit re-authorisation.
Edge cases matter. Some systems use rotating refresh tokens, which lowers replay risk but does not eliminate it if the rotation chain is not immediately invalidated on compromise. Others rely on device binding, sender-constrained tokens, or step-up reauthentication to make stolen grants harder to reuse. For NHIs, the problem is often worse because the token may represent an integration rather than a person, so offboarding checks are missed. The Dropbox Sign breach and the JetBrains GitHub plugin token exposure both show how exposed credentials can become long-tail access risks when they are not revoked fast enough. The OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both support a lifecycle-first approach, even though there is no universal standard for refresh-token TTLs yet.
Where teams get into trouble is assuming a refresh token is “safe” because it is not directly usable as an API bearer token, when in reality it may be the easiest path back into the environment.
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 | Refresh tokens become standing NHI credentials when rotation and revocation are weak. |
| NIST CSF 2.0 | PR.AC-4 | OAuth refresh tokens are access entitlements that must be governed by least privilege. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires re-evaluating trust instead of letting old tokens renew indefinitely. |
Review delegated grants and remove stale access as part of regular access governance.
