Refresh token governance is the missing layer in SaaS identity security

At a glance

What this is: This article explains why refresh tokens create persistent SaaS access and shows how token governance gaps let stolen or orphaned credentials outlive the user and bypass MFA.

Why it matters: IAM and security teams need to treat refresh tokens as governed identities, because lifecycle blind spots in SaaS integrations create hidden access paths across third-party applications and downstream tenants.

By the numbers:

• The tokens remained, granting access to 700+ organizations.

Context

Refresh tokens are long-lived OAuth credentials that can mint new access tokens without forcing a fresh login. In SaaS environments, that makes them a hidden persistence layer that sits outside the usual user lifecycle controls, even when the original account is no longer active.

The governance gap is simple: organisations often manage user accounts, SSO sessions, and MFA, but not the downstream tokens issued to third-party integrations. Once a refresh token is stored in a vendor environment or application workflow, it can continue authorising access independently of employment status, device state, or re-consent.

The article uses the Salesloft incident to show that this is not a theoretical edge case. It is a common SaaS identity problem where delegated access outlives the person and the control plane that originally approved it.

Key questions

Q: What breaks when an app relies on refreshable third-party tokens without lifecycle controls?

A: The main failure is that access continues to exist outside the normal review cycle, even when users disconnect, orgs change, or tokens are revoked. That creates hidden delegated access paths and weakens accountability. Without lifecycle control, teams can no longer prove who can still act on behalf of whom.

Q: When does refresh token rotation reduce risk, and when is it not enough?

A: Rotation helps when you need replay detection and rapid invalidation of reused credentials. It is not enough when an attacker uses the token first, when a vendor stores the token insecurely, or when no behavioural monitoring exists. In those cases, the trust problem remains even if the token family changes.

Q: How should security teams reduce refresh token risk in SaaS environments?

A: Start with the basics that actually shrink blast radius: rotate tokens on every use, constrain sender context where possible, limit lifetimes by application sensitivity, and maintain fast revocation paths. Then add behavioural detection so you can spot active abuse, because static controls alone only reduce exposure after compromise, not during it.

Q: Should organisations treat third-party OAuth apps as part of identity governance?

A: Yes. Third-party OAuth apps can hold valid credentials into SaaS systems, so they are effectively non-human identities with delegated access. That means ownership, approval, scope review, offboarding, and behavioural monitoring should apply to them just as they do to other privileged access paths.

Technical breakdown

Why refresh tokens outlive user lifecycle controls

A refresh token is a bearer credential that exchanges for new access tokens after the original OAuth consent. Because the token is validated by the authorization server, not by repeated user authentication, it can continue working long after the user has left or the app owner has changed. That breaks the assumption that access reviews and offboarding cover all active access. In SaaS, the durable credential often sits inside a third-party integration, not in the user account teams are reviewing.

Practical implication: build token inventory and revocation into offboarding, not just account disablement.

Why rotation helps, but does not eliminate token theft

Refresh token rotation replaces a used token with a new one and invalidates the previous value, which helps detect replay. The weakness is timing: if an attacker uses the stolen token first, they can establish continued access before defenders notice. Rotation therefore reduces reuse risk, but it does not remove the original trust problem that possession equals authorization. Without sender constraint or behavioural checks, a stolen refresh token still functions like a renewable session key.

Practical implication: treat rotation as detection and containment, not as proof that the token layer is safe.

How SaaS-to-SaaS integrations turn tokens into lateral movement paths

When one SaaS platform stores refresh tokens for another, a compromise in the intermediary can become downstream access to customer tenants. The attacker does not need malware, password guessing, or MFA bypass at the user layer; the OAuth token already carries the delegated scope. That is why traditional controls often miss the abuse. The activity looks like legitimate application traffic unless teams baseline normal token behaviour and monitor for abnormal usage patterns, unusual refresh frequency, or access from unexpected infrastructure.

Practical implication: monitor token usage as an identity signal, not only as an API activity log.

Threat narrative

Attacker objective: The attackers aimed to preserve renewable SaaS access and reach downstream customer data through delegated third-party integrations.

1. Entry occurred when attackers compromised a third-party SaaS environment that already stored customer refresh tokens for delegated access.
2. Credential access came from the refresh tokens themselves, which functioned as bearer credentials and did not require MFA or re-authentication once issued.
3. Escalation happened through repeated token use that preserved access after the original user context had changed, allowing the attackers to operate as a legitimate integration.
4. Impact followed as downstream Salesforce access spread across 700+ organizations through the compromised SaaS supply chain.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Refresh token governance is the missing control layer in SaaS identity security. Organisations have spent years hardening login flows, MFA, and SSO, yet the real persistence mechanism often lives in OAuth token storage and reuse. The article shows that a token can remain valid long after the original user lifecycle has ended, which means identity governance stops too early if it ends at the account boundary. The practitioner conclusion is that token lifecycle must be treated as part of identity lifecycle, not as an app-layer afterthought.

Bearer token architecture creates trust debt that traditional IAM programmes do not account for. Once a refresh token exists, possession becomes authorization, and the system no longer asks whether the original user is still the right actor. That is a structural weakness in SaaS delegation models, especially when third-party vendors store customer tokens on their own behalf. The implication is that the security model depends on continuous stewardship of delegated credentials, not just on the original consent event.

Salesloft-style SaaS supply chain exposure proves that delegated access can outlive accountability. When integrations persist across employee moves, vendor relationships, and app changes, organisations lose the ability to answer who should still have access and why. That is not just poor hygiene; it is a lifecycle control failure that expands the identity blast radius across tenants. The practitioner conclusion is to govern delegated access with the same discipline applied to privileged human access, because the risk behaves like privilege creep with machine speed.

Token rotation is necessary, but it does not solve the underlying trust assumption. Rotation detects replay and narrows some abuse windows, but it still assumes the legitimate and malicious user will surface in a way the authorization server can compare. In SaaS token abuse, the attacker often wins first and the valid application loses later. The implication is that modern SaaS identity security has to move from static token possession to behavioural assurance around how tokens are used.

Identity security for SaaS now includes downstream custodianship of non-human credentials. If a vendor stores a refresh token on a customer’s behalf, the customer still owns the governance problem even if they do not directly hold the credential. That makes third-party integration review a core identity control, not a procurement checkbox. The practitioner conclusion is to treat every delegated token as an owned identity artefact with a lifecycle, an owner, and a revocation path.

From our research library:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• Read next: Guide to NHI Rotation Challenges

What this signals

Refresh token governance belongs in the identity programme, not just in application security. The practical shift for most teams is to extend lifecycle controls from user accounts to delegated tokens, especially where vendors custody OAuth credentials on behalf of customers. Without that move, offboarding and quarterly reviews will continue to miss the credential that actually keeps access alive.

Token custody is the new SaaS trust boundary. If a third party stores the refresh token, that storage decision becomes part of your risk model and your incident response plan. Security teams should prepare for vendor compromise scenarios in which the first sign of trouble is legitimate-looking OAuth activity rather than a clear account takeover.

For practitioners

• Inventory delegated refresh tokens Map every SaaS integration that stores refresh tokens, including vendor-managed connectors, automation platforms, and app-to-app OAuth grants. Record owner, scope, issuing user, storage location, and revocation path so offboarding and vendor review can target the actual credential.
• Tie token revocation to offboarding Make refresh token revocation part of employee leaver workflows, contractor exit handling, and application decommissioning. Disabling the user account is not enough when the token remains valid inside a third-party system.
• Set absolute token lifetimes Use short access-token lifetimes and impose a hard maximum age on refresh tokens, even where rotation is enabled. Long-lived tokens should not survive indefinitely just because they are periodically exchanged.
• Baseline refresh behaviour Establish expected refresh frequency, source infrastructure, client IDs, and geographic patterns for each integration. Alert on duplicate use, unusual refresh volume, and access from unexpected ASNs or service locations.
• Review third-party custodianship Require vendors and internal platform teams to explain where refresh tokens are stored, how they are encrypted, how they are rotated, and how bulk revocation works during incidents. Vendor trust should be evaluated as token custody, not just as application uptime.

Key takeaways

• Refresh tokens create a durable access layer that can survive user departure, re-authentication boundaries, and routine MFA checks.
• The article ties that risk to real SaaS supply chain exposure, including 700+ downstream organizations in the Salesloft incident.
• Security teams need lifecycle governance, behavioural detection, and explicit revocation paths for delegated tokens, not rotation alone.

Key terms

• Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• Token Rotation: Token rotation is the practice of replacing a refresh token with a new one after use and invalidating the previous token. It helps detect replay and reduces reuse risk, but it does not solve compromise on its own. Strong implementations combine rotation with atomic invalidation, telemetry, and full-family revocation.
• Delegated OAuth Access: Delegated OAuth access is a permission model where an application acts on behalf of a user or workspace after consent is granted. In NHI terms, the app becomes a non-human identity with real reach, so scope, revocation, and monitoring matter as much as the original account credentials.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.