Salesforce refresh tokens expire after 30 days idle: what changes from 4 November 2026

Worth knowing: at enforcement, Salesforce immediately expires refresh tokens that are already 30+ days idle. So a job whose refresh token was last used more than 30 days before your org is switched over can fail on its next run. The control also caps access tokens at 30 days since last login for integrations that don't use refresh tokens. (Source: Salesforce Help KA 005461275.)

What changes

Salesforce is turning on the Limit Idle Refresh Token Time-to-Live (TTL) to 30 Days OAuth setting for connected apps and external client apps, including apps installed in subscriber orgs. According to KA 005461275, enforcement has three effects:

1. Immediate expiry of existing idle tokens. Any refresh token unused for 30 days or longer expires at enforcement, along with its access token.
2. Immediate expiry for flows without refresh tokens. Existing access tokens whose last login date is more than 30 days ago expire.
3. Ongoing enforcement. From then on, a refresh token expires after 30 days of inactivity. For flows without refresh tokens, access tokens expire 30 days after their last login date.

After enforcement, Salesforce Customer Support can no longer change the setting. Salesforce's 26 October update to the article clarifies that it does not expire all access tokens at enforcement, only the ones described above. If you read an older summary that says every token is revoked, the current Salesforce article is the one to follow.

Who's affected

Anyone who builds, distributes or installs OAuth apps. The integrations most at risk are:

• Background jobs that store a refresh token and run less than every 30 days. Think quarterly reports, annual loads, disaster-recovery syncs or month-end tools. When the token expires, Salesforce returns invalid_grant with the description expired access/refresh token.
• Interactive apps used now and then. After 30 idle days the user is logged out and must log in again.
• Integrations without refresh tokens. Their access tokens now expire 30 days after the last login. Resource requests such as SOAP API calls return INVALID_SESSION_ID; /services/oauth2/singleaccess returns invalid_token.

The limit already applies to Partner Apps and apps created in July 2026 or later.

A note on JWT bearer and client credentials: these server-to-server flows don't rely on a stored refresh token, but they aren't simply exempt. Their access tokens are capped at 30 days from last login. Salesforce lists the action as "None" because the integration just runs the flow again. That only holds if your code handles the expiry error instead of failing.

How to check your org

Salesforce's suggested audit uses Login History (KA 005461275):

1. In Setup, enter Login History in Quick Find and open it.
2. Create a new view, or edit an existing one.
3. Filter on Login Subtype equals OAuth Refresh Token and O Auth Refresh Token for Hybrid Apps (the values as Salesforce lists them).
4. Add Login Subtype and Login Time to the columns, then save.

Focus on apps with gaps longer than 30 days, and integrations you know exist that don't appear in the last month at all.

To test how an app copes, the KA describes a revocation test. Get a token, go to Setup → Users, open the user associated with the app, click Revoke next to the app under OAuth Apps, then use the app. Salesforce notes this tests revocation, not idle expiry exactly, but it's a quick way to see whether an app recovers or fails silently.

What to do

From the KA guidance:

• Handle the error. Background integrations should catch invalid_grant / expired access/refresh token and run the OAuth flow again automatically, or alert someone when that needs a human.
• Monitor background jobs so failures don't go unnoticed for weeks.
• Don't fake activity. Salesforce says plainly: "Don't create artificial refresh activity solely to prevent token expiration." A cron job that refreshes tokens just to keep them alive goes against the intent of the control.
• Redesign rare jobs. If an integration is legitimately used less than once every 30 days, set up a reauthorization process, or evaluate a flow without refresh tokens that meets its security needs.
• Test in a sandbox. Sandbox enforcement started rolling out on 21 October, so a sandbox is the place to see how your integrations behave.
• Tidy policy settings after enforcement. Some refresh-token policy screens and metadata don't update automatically, so update the app to match.

Timeline

The rollout is rolling, so not every org switches on 4 November itself. Treat it as the earliest date.

FAQ

Does every Salesforce refresh token expire on 4 November 2026?

No. Only refresh tokens unused for 30+ days expire when your org is enforced, and enforcement rolls out from 4 November rather than hitting every org that day. Tokens in regular use keep working.

What error will I see when a refresh token expires?

For an expired refresh token: invalid_grant with the description expired access/refresh token. The integration has to run the OAuth flow again to get new tokens. For flows without refresh tokens, an expired access token shows up as INVALID_SESSION_ID on API requests.

Are JWT bearer and client credentials integrations exempt?

Not exactly. Their access tokens expire 30 days after the last login. That's fine if the integration requests a new token when it gets INVALID_SESSION_ID or a similar error.

Can I ask Salesforce Support to turn this off?

Not after enforcement. KA 005461275 says you can no longer contact Support to change the setting once it's enforced.

Should I schedule a job to refresh tokens every few weeks?

No. Salesforce says not to create artificial refresh activity. Build in reauthorization or choose a flow that fits the job.

Are sandboxes already affected?

Sandbox enforcement began on a rolling basis on 21 October 2026, so yours may already be enforced or may be switched over soon.

Sources

• KA 005461275, Security Change: Refresh Token Idle TTL Is Limited to 30 Days (publish date Oct 26, 2026)
• KA 005461287, Connected App & External Client App Security Requirement Updates (roadmap table, Oct 14, 2026)

Last checked: 29 October 2026, against the Salesforce Help pages above. If Salesforce's page and this article ever disagree, Salesforce's page is correct.