Salesforce’s 30-day refresh-token limit: prepare integrations for November 2026

Salesforce is introducing a mandatory 30-day idle limit for OAuth refresh tokens. Enforcement begins in sandboxes on a rolling basis from 21 October 2026, followed by production orgs, scratch orgs and Developer Edition orgs from 4 November 2026.

This is more than a future expiry rule. When Salesforce enables the control, it will revoke all existing access tokens and immediately expire refresh tokens that have not been used for 30 days or more. Well-designed integrations may recover automatically. Low-frequency jobs, neglected applications and clients with weak error handling may instead stop and require reauthorisation.

The dates are close, but the right response is measured. Platform teams need to understand which applications use refresh tokens, how often they use them and what happens when either an access token is revoked or a refresh token has expired.

What Salesforce has confirmed

The control applies to connected apps and external client apps, including apps installed in subscriber orgs. Salesforce will enable the setting named Limit Idle Refresh Token Time-to-Live (TTL) to 30 Days. After enforcement, Salesforce says Support can no longer change that limit despite older explanatory text that may still appear below the setting.

The 30 days form a sliding inactivity window. When an application successfully uses its refresh token, the inactivity period starts again. This is not the same as an absolute expiry 30 days after the token was first issued.

Salesforce already applies the limit to partner apps covered by its 2026 connected-app and external-client-app security controls, and to apps created in July 2026 or later. Platform owners should therefore verify actual behaviour rather than assume every application is waiting for the October or November rollout.

The one-time enforcement event matters

Salesforce identifies three effects when the setting is enforced:

1. All existing access tokens are revoked.
2. Refresh tokens already idle for 30 days or longer expire immediately.
3. Unused refresh tokens continue to expire after 30 days of inactivity.

An integration with a valid stored refresh token should be able to exchange it for a new access token after the first revocation. If the refresh token has already crossed the idle threshold, Salesforce returns an invalid_grant response with an expired access or refresh token description. The application then needs a new authorisation rather than another blind retry.

Interactive applications behave similarly: a current refresh token can usually renew behind the scenes, while an expired one requires the user to sign in again. Authentication flows that do not use refresh tokens must repeat their initial flow to obtain a new access token.

These distinctions are confirmed product behaviour. The likely business impact for a particular organisation is an operational assessment: it depends on the flow, token policy, client implementation, usage frequency and availability of somebody authorised to reconnect the app.

Which integrations deserve attention first?

Frequently used integrations may refresh often enough that the ongoing idle limit causes little disruption, provided their client handles the one-time access-token revocation correctly. The higher-risk group is usually less visible:

• month-end, quarter-end or annual data jobs;
• disaster-recovery and contingency processes that are deliberately dormant;
• desktop or mobile tools used intermittently by named employees;
• supplier applications with unclear token handling;
• old middleware connections whose original owner has left;
• test, training and support integrations that are needed only occasionally;
• shared tokens copied into more than one runtime or manually maintained secret stores.

A rarely used integration is not automatically expendable. It may support a critical process precisely when it is invoked. Record business criticality separately from frequency so that dormant but important capabilities receive an appropriate recovery plan.

Build an evidence-based inventory

Start with connected apps, external client apps and OAuth usage in Salesforce Setup, then reconcile that view with middleware, application registers, credential vaults and supplier records. For each integration, capture:

• application and app owner;
• business process and criticality;
• production and non-production orgs;
• OAuth flow and whether a refresh token is issued;
• integration user or authorising user;
• usual run frequency and last successful use;
• token storage and renewal behaviour;
• supplier support route and current product version;
• person able to reauthorise and the required approval path.

Do not infer token behaviour solely from an app’s name or consumer key. Confirm it through client documentation, code, logs or a controlled test. Named Credentials can manage token refresh and storage for some Salesforce-originated callouts, but that does not remove the need to test what happens when the underlying authorisation is no longer valid.

Test two different failure conditions

A realistic sandbox test should prove both branches of the change.

First, revoke an active access token while leaving a recently used refresh token available. Confirm that the client recognises the authentication failure, performs the refresh flow once, stores any replacement token correctly and resumes the interrupted work without duplication or data loss.

Second, test the behaviour when no valid refresh token is available. Confirm that the client stops safely, surfaces a useful error and directs the right person through reauthorisation. A background job must not spin through endless retries, hide the failure until the next business day or partially process a batch without a clear reconciliation route.

Where refresh-token rotation is also enabled, the application must store the newly issued refresh token after each exchange. Salesforce’s partner guidance also warns about race conditions when multiple processes share token state. Treat concurrency and secret-storage behaviour as developer or supplier responsibilities that require evidence, not assumptions.

A practical preparation plan

1. Identify the rollout window. Use Salesforce Trust and your instance details to watch the relevant maintenance timing, while planning against the published rolling start dates.
2. Prioritise by failure impact. Review low-frequency, unowned and business-critical applications before high-volume integrations that already renew predictably.
3. Contact suppliers early. Ask whether the product handles access-token revocation, 30-day refresh-token inactivity, rotation and reauthorisation, and whether a supported update is required.
4. Test in a representative environment. Exercise both successful renewal and expired-token recovery with realistic users, permissions, schedules and data.
5. Prepare reauthorisation. Confirm who can approve access, which credentials or certificates are needed and how service can be restored outside normal hours.
6. Monitor the change window. Watch authentication failures, job queues, missed schedules and downstream reconciliations during and after enforcement.
7. Close the governance gap. Add token lifecycle, ownership and recovery evidence to the integration register and recurring operational review.

Avoid turning the control into a keep-alive exercise

It may be technically possible to invoke a refresh flow periodically just to prevent a token becoming idle. For a legitimate low-frequency integration, that can be part of a supported design. It should not be the default answer to every dormant credential.

An unused token is also a standing route into Salesforce if it is stolen. The control exists to shorten that exposure. Before preserving a dormant authorisation, confirm that the application still has a business owner, justified scopes, an appropriate user, secure token storage and a tested operational purpose. Revoke obsolete connections instead of keeping them artificially alive.

The Ostrelis view

The 30-day limit is a security improvement with an unusually concrete operational event: all access tokens are revoked when enforcement lands. The main risk is not that every integration will fail. It is that organisations do not know which applications can recover, which tokens have been idle and who can restore access when reauthorisation is required.

Use the change to establish a repeatable token-lifecycle discipline. Inventory integrations, separate frequent from dormant use, test renewal and recovery, document ownership, and remove authorisations that no longer serve a purpose. That approach supports both resilience and least privilege without treating routine security enforcement as a crisis.

Ostrelis can help organisations review Salesforce OAuth dependencies, coordinate suppliers, test failure and recovery paths, and bring integration ownership into a manageable support model. See our Salesforce data and integration support, managed services and approach and experience. Need help getting prepared? Talk to a Salesforce expert.